Researcher
Related Projects
HTTPS

Source: EMARKETER
Today, the global e-commerce market is worth roughly $6T-$7T, accounting for around 20% of total retail sales worldwide. So what made e-commerce scale this far?
There are many reasons. Smartphones became ubiquitous. Logistics and distribution improved. Consumer behavior also became more digital, especially after COVID.
But one question had to be answered before any of that could really work:
“Is it safe to type my password and credit card number into the internet?”
Early HTTP traffic was not encrypted. Then in 1994, Netscape introduced SSL as an encryption layer. Over time, HTTPS, using SSL/TLS, made it possible for browsers and servers to exchange data securely.
What matters is that HTTPS was never built as a narrow “payments technology.”
HTTP evolved as a general-purpose protocol, not something tied to a single service. It was flexible enough to support new data formats, features, and use cases over time.
HTTPS added a security layer on top of that flexible foundation.
That meant the same web architecture could securely support product pages, logins, shopping carts, orders, payments, shipment tracking, and API calls. And as the web expanded beyond browsers into mobile apps and countless APIs, the same HTTP-based communication model continued to work.
In other words, HTTPS did more than encrypt a credit card number. It became a security foundation that could scale as the internet itself became more complex.
Today, most of us barely notice the https:// in the address bar. But that small layer became one of the most fundamental pieces of infrastructure behind today’s multi-trillion-dollar online economy.
Blockchains Need Their Own HTTPS

Today’s blockchain ecosystem looks a lot like the early HTTP internet. Users may be pseudonymous, but addresses, amounts, transaction types, counterparties, and other onchain activity are transparently visible.
It is hard to imagine the blockchain economy reaching the scale of today’s internet while remaining this transparent by default.
Of course, there are already many confidentiality protocols in crypto. Each approaches the problem from a different angle.
But unlike HTTPS, which became broadly applicable across the internet, most existing approaches are difficult to apply universally across the blockchain ecosystem.
What blockchains need is scalable confidentiality.
To get there, I think a confidentiality layer needs to scale across three dimensions:
- Chain generality: It should be able to provide confidentiality across different blockchain networks.
- Activity generality: It should go beyond transfers and support DeFi activities like swaps and deposits, and eventually arbitrary computation.
- Asset generality: It should not be limited to one asset. It should be able to bring confidentiality to many existing tokens.
Zcash and Monero, for example, struggle with chain and asset generality because their chains and native assets were designed around confidentiality from the start.
Tornado Cash, on the other hand, is limited in activity generality because it is primarily focused on transfers.
This is why Zama’s recent direction is worth paying attention to.
Zama
Zama is a confidentiality protocol built around FHE. FHE makes it possible to compute over encrypted data without first decrypting it.
The important part is that Zama is not trying to build a separate blockchain. Instead, it adds a confidentiality layer on top of existing public blockchains.
The goal is to make it possible to handle not only issuance and transfers, but also DeFi and broader onchain computation while keeping sensitive data encrypted.
What makes this architecture interesting is that, at least in principle, it can satisfy all three forms of generality above.

First, activity generality. Confidentiality on Zama is not limited to transfers. A recent example is the Steakhouse Confidential Prime USDC Vault. Individual deposit sizes and positions are kept confidential onchain.
The key point is that Zama did not build an entirely separate protocol for this. It added confidentiality on top of DeFi infrastructure that already exists.
Second, asset generality. On Ethereum, Zama currently provides confidential wrappers for a range of assets, including USDC, USDT, WETH, ZAMA, tGBP, and XAUt. This means existing market assets can be wrapped into confidential assets rather than requiring users to migrate into an entirely new asset system.
Finally, chain generality. Zama Protocol is currently centered around Ethereum, but there has been some interesting activity in its public GitHub around a potential Polygon deployment.
If this develops as the public registry suggests, it could become the first case of Zama’s confidentiality protocol expanding to a general-purpose chain beyond Ethereum.

Source: GitHub (zama-ai)
Polygon, chain ID 137, now appears in Zama’s official mainnet onchain contract registry. More importantly, this is not just a token bridge entry. Core host-side components such as FHEVM Executor, ACL, Input Verifier, KMS Verifier, and Protocol Config are registered for Polygon.
That is a much stronger signal than simply seeing $ZAMA bridged to another network.
At the same time, Polygon is still listed as a testnet deployment in Zama’s existing address documentation, so I would not treat this as an official mainnet launch yet.
But the public GitHub activity does suggest that the architecture for extending Zama’s confidentiality protocol beyond Ethereum is becoming much more concrete.
The Polygon angle is especially interesting because Polygon has recently been reinforcing its identity as a payments network.
Through its Open Money Stack, Polygon is bringing together stablecoin settlement, cross-border payments, on/off-ramps, and compliance into a broader payments infrastructure.
But the more payments move onchain, the more public blockchain transparency becomes a constraint. Every counterparty and transaction amount being publicly visible is not always compatible with how real financial activity works.
Polygon itself has highlighted confidentiality as an important operational requirement for bringing institutional payment flows onchain.
So if Zama’s confidentiality layer does expand to Polygon, it could become one of the missing pieces needed for public blockchains to evolve into more complete financial infrastructure.
Zama’s Bet on Blockchain HTTPS
HTTPS did not create a new internet.
It added an encryption layer to the internet that already existed.
Zama is pursuing a similar idea for blockchains.
The direction is to add confidentiality to existing chains, existing assets, and existing applications and financial activity.
If Zama can continue proving that model across chains, activities, and assets, its role could become much broader than that of a single confidentiality protocol.
It could become something closer to HTTPS for the onchain economy.
The report is based on the independent research of the author sponsored/funded by Zama. The author of this report may have personal holdings or financial interests in assets or tokens discussed herein. However, the author affirms that no transactions have conducted using material non-public information obtained in the course of research or drafting. This report is intended solely for general information purposes and does not constitute legal, business, investment, or tax advice. It should not be used as a basis for making any investment decisions or as guidance for accounting, legal, or tax matters. Any references to specific assets or securities are made for informational purposes only and should not be construed as an offer, solicitation, or recommendation to invest. The opinions expressed herein are those of the author and may not reflect the views of any affiliated institutions, organizations, or individuals. The opinions and analyses expressed herein are subject to change without prior notice. In addition, beyond the individual disclosures included in each report, Four Pillars, may hold existing or prospective investments in some of the assets or protocols discussed herein. Furthermore, FP Validated, a division of Four Pillars, may already be operating as a node in certain networks or protocols discussed herein or may do so in the future. Please see below links in the footer for FP Validated's participating network disclosures and for broader disclosure details.



