Research indicates the overall Web3 market was valued at USD 2.25 billion in 2023, growing to an estimated USD 5.01 billion by 2025, reflecting a compound annual growth rate of 49.3%. In parallel to web3 expansion, the consumer base is mostly reflected as an increasing trend, with 616 million users in 2024 compared to 516 million in 2023.

This growth has also been accompanied by technological advancements making web3 more accessible to average users. The improved UX brought by Account abstraction is gaining significant traction, with over half a million ERC-4337 accounts deployed across major networks already at its early stage of introduction3. As we have learned in the Observatory workshops over the past year, account abstraction allows for lower transaction fees, gasless swaps, and simplified login processes that eliminate constant approval requests.

In the B2B space, a 2024 survey by Adan and KPMG on French web3 companies revealed that 73% planned to raise funds in 2024, signalling strong investment interest. Additionally, 86% of these companies anticipated resuming hiring, suggesting a positive outlook for job creation.

Given these premises, in this article we will cover the demo presented at our annual convention back in January. We saw this as an opportunity to showcase that web3 ecosystems should not be seen in isolation, and that using complementary technologies can create an even more familiar experience without sacrificing the benefits of a trustless web.

The web as we know it began with a simple premise: clients request, servers respond. This Client-Server model formed the backbone of Web2, creating the digital world we navigate every day. In the early days, HTTP handled this communication in plain text, leaving data to travel across networks unprotected and visible to any interested observer.

Then came Secure Sockets Layer in 1995, later evolving into Transport Layer Security (TLS). These protocols wrapped our communications in encryption, adding that crucial 's' to HTTPS. Despite its revolutionary impact, this transition happened almost invisibly to users. One day you visited http://bestsite.com, the next day https://bestsite. com- same site, one extra letter. Yet beneath this subtle change lay a complete transformation of internet security, although mainstream adoption came surprisingly late. Only when Google announced in 2014 that HTTPS would influence search rankings, did businesses finally rush to secure their sites.

While Web2 secured communications, it failed to reinvent value exchange. Data flowed seemingly freely, but its extracted value met the same fate as money and assets for centuries—it remained confined in centralised systems. Bitcoin changed this in 2009, introducing and validating the concept of Internet of Value: a parallel internet where assets, possibly including user data, move as freely as information. But integrating this new paradigm with Web2 architecture revealed three fundamental tensions:

First, the legacy economic model of Web2 thrives on ads and data extraction, turning users into products. It's fundamentally at odds with Web3's model, which prioritises user ownership and decentralised value exchange.

Second, digital identity remains fragmented across countless platforms. We maintain dozens of accounts, each with different credentials and trust levels, creating friction and security vulnerabilities.

Third, data provenance and trust. How do we verify data origin? How can we trust information without relying on centralised authorities?

Web3 emerges as a paradigm that reconciles these tensions thanks to blockchain's decentralised consensus. This transition, however, cannot succeed by discarding Web2's foundational architecture. Instead, it must thoughtfully integrate with existing connectivity patterns and leverage the battle-tested UX knowledge accumulated over decades.

Of the three tension points mentioned above, our demo focused on the last:

how to overcome Web2's challenges by enabling trustless data verification.

Before even unpacking what trustless data verification means, why should this matter? In a "purist" Web3 vision, blockchain already provides that layer of consensus and shared truth upon which to integrate infrastructure components (decentralised storage, DAOs, DePIN, native oracles, etc.) to completely rethink applications and services without requiring trust.

However, we cannot ignore Web2's existence or replace it overnight without considering the combined resistance to change from established business models, user habits, technical infrastructure investments, and regulatory frameworks—all aligned with the current paradigm.

This reality creates demand for transitional technologies.

History offers instructive examples of such transitions. Notoriously, paper communication didn't immediately yield to email—fax machines bridged the gap, combining physical documents with electronic transmission. Internal combustion engines aren't instantly giving way to electric vehicles—hybrids serve as the steppingstone.

Perhaps the closest example, though less widely known, is the transition from the Internet pre- to post-TCP/IP. Initially, many independent networks existed, each isolated with proprietary protocols. Gateways emerged as critical transitional technologies, allowing these disparate networks to communicate with each other while a new protocol gradually achieved widespread adoption. Once TCP/IP became universal, these gateways largely faded, though their functions were integrated into modern networking infrastructure.

The transitional technologies we presented at this year's convention enable reliable verification of data from traditional websites without requiring server-side modifications. These "web proofs" bridge the trust gap between centralised Web2 services and the verification-centric Web3 ecosystem.

To comprehend how these proofs work, we must first revisit TLS—the cryptographic protocol securing most web communications today. When you connect to a website using HTTPS, your browser and the server perform a "handshake" to establish secure communication. This process creates a shared secret key known only to these two parties. All subsequent data exchanges are encrypted using this key, protecting your information from eavesdroppers.

However, TLS has a limitation:

While it proves to you that you're talking to a legitimate website, it doesn't help you prove to others what the website told you.

The website doesn't cryptographically sign its responses, so users cannot verifiably demonstrate to a third party what data they received. In fact, message authentication codes cannot serve as public proof. In the wide panorama of zero-knowledge decentralised application developments, two prominent technologies have stood out to address this limitation:

TLSNotary uses a multi-party computation approach where a trusted "notary" participates in the TLS session. The notary doesn't see the user’s plaintext data but can cryptographically attest that the website sent specific encrypted data. This technique leverages secure multi-party computation to split the TLS session keys between the user and the notary.

Reclaim Protocol takes a different approach by introducing “attestors” who act as proxies for your TLS connection. These attestors can only see encrypted traffic but can verify your TLS session was authentic. Reclaim then allows the user to create zero-knowledge proofs about specific pieces of data within the response, revealing only what they choose while maintaining cryptographic verification of its source.

Both approaches are nascent technologies that share a common challenge: trust in the intermediary. There's always a risk that the notary or attestor could collude with the user to falsify the attestation, except when the attestor is also the verifier. However, this isn't an intractable problem. Both technologies can implement decentralised verification mechanisms where multiple independent parties must attest to the same data. TLSNotary is exploring a multi-notary approach, while Reclaim Protocol has designed an economic mechanism that incentivizes honest behavior from multiple attestors through stake-based penalties for dishonesty.

We used the live developer portal of Reclaim to build our decentralised application. To understand the underlying protocol, we invite the reader to follow the next example. Valery wants to prove to Jack that she has over $5,000 in her online bank account without revealing her exact balance or account details. These are the steps:

1. Valery initiates a request to her bank's website and routes all traffic through a Reclaim Protocol’s attestor proxy.

2. Valery's browser uses the TLS 1.3 KeyUpdate feature to create separate encryption contexts for different parts of her request. She creates one key (Ksending1) for public parts of her request (like the URL and non-sensitive headers), another key (Ksending2) for private sections (like authentication tokens), and a third key (Ksending3) for the remainder. She only shares Ksending1 and Ksending3 with the attestor, keeping Ksending2 private.

   The attestor monitors the encrypted TLS traffic between Valery and her bank but cannot see the plaintext content due to TLS encryption. For the bank's response, the server uses a single receiving key (Kreceiving), which Valery keeps private.

3. Valery logs into her account normally, and the bank returns her account information within the encrypted response.

4. The attestor digitally signs the encrypted response, certifying that it genuinely came from the bank's servers.

5. Valery uses zero-knowledge proofs to selectively reveal only that her account balance exceeds $5,000. She does this by keeping the relevant parts of the encrypted response that show her balance, replacing everything else with placeholder symbols, and proving she can decrypt these specific portions using the correct Kreceiving key.

6. Valery sends this zero-knowledge proof along with the attestor's signature to Jack.

7. Jack verifies both the attestor's signature (confirming the data came from the bank) and the zero-knowledge proof (confirming Valery’s balance exceeds $5,000).

Throughout this process, the attestor never sees Valery’s account details, and Jack only learns what Valery explicitly chooses to reveal. Yet Jack can be mathematically certain that Valery’s bank confirmed her balance exceeds $5,000 and nothing else.

What if verification needed to be public, auditable, and transparent? In which scenarios might this be necessary? For example, in a Web3 application that regulates token issuance or manages digital rights, public verifiability becomes crucial. We can achieve this by transforming verification logic into smart contract code. This is mainly possible because proofs are "succinct" and efficient to verify on-chain. To showcase a practical application of these concepts, we set to demonstrate how web proofs can work with heterogeneous data sources from different Web2 sites.

We focused on three distinct categories of data:

• Institutional Credentials: To pull driving license points from Italy's government portal "Portale dell'Automobilista." This showed how citizens could prove their good driving record.

• Philanthropic Activities: To verify donations made through GoFundMe. The application let users to cryptographically prove their charitable contributions without exposing their personal information or exact donation amounts.

• Environmental Impact: Carbon footprint scores obtained from the WRen Agency platform, enabling users to verify their environmental consciousness through their carbon offset activities.

But one may ask how hard is it to bridge multiple traditional Web2 services into a cohesive Web3 experience? Nowadays it’s possible with a simple flow like that of our application:

1. Users began by logging in either through a traditional EOA wallet like MetaMask or with Coinbase's Smart Wallet using passkeys—showcasing both Web3 native and Web2-familiar authentication methods.

2. The application generated a QR code for each proof request from the Reclaim provider.

3. Users scanned these codes or clicked on the corresponding URLs, which initiated the attested TLS session and eventually enabled zk proof generation process entirely client-side.

4. Upon successful verification, users received tokens that unlocked special privileges in an interactive game.

Throughout the demo, we emphasized the advantage of using transaction fee sponsorship, which removes the financial barrier to Web3 interaction. Also, users didn't need to install any proprietary apps, as the experience with the original Web2 sites worked through instant app clips on mobile devices.

Naturally, our game-based demo is just a toy example where privileges directly reflected the web proofs obtained: with each proof unlocking cumulative advantages, where the more proofs a user collected, the more powerful their character became in the game. Countless other use cases could be developed, from DeFi credit scoring based on verified bank history to permissionless governance participation weighted by real-world credentials.

Web3 is no longer a distant vision—it’s ready to use, and already compatible with familiar Web2 experiences.Web proofs offer a transitional layer that could remain relevant much longer than expected, helping integrate trustless verification into mainstream services.The tools are here, the UX is improving, and transitional solutions are viable: there are no more excuses to delay building meaningful applications.It’s time to fully embrace the internet of value—where users own their identity, assets, and data.

Research indicates the overall Web3 market was valued at USD 2.25 billion in 2023, growing to an estimated USD 5.01 billion by 2025, reflecting a compound annual growth rate of 49.3%. In parallel to web3 expansion, the consumer base is mostly reflected as an increasing trend, with 616 million users in 2024 compared to 516 million in 2023.

This growth has also been accompanied by technological advancements making web3 more accessible to average users. The improved UX brought by Account abstraction is gaining significant traction, with over half a million ERC-4337 accounts deployed across major networks already at its early stage of introduction3. As we have learned in the Observatory workshops over the past year, account abstraction allows for lower transaction fees, gasless swaps, and simplified login processes that eliminate constant approval requests.

In the B2B space, a 2024 survey by Adan and KPMG on French web3 companies revealed that 73% planned to raise funds in 2024, signalling strong investment interest. Additionally, 86% of these companies anticipated resuming hiring, suggesting a positive outlook for job creation.

Given these premises, in this article we will cover the demo presented at our annual convention back in January. We saw this as an opportunity to showcase that web3 ecosystems should not be seen in isolation, and that using complementary technologies can create an even more familiar experience without sacrificing the benefits of a trustless web.

The web as we know it began with a simple premise: clients request, servers respond. This Client-Server model formed the backbone of Web2, creating the digital world we navigate every day. In the early days, HTTP handled this communication in plain text, leaving data to travel across networks unprotected and visible to any interested observer.

Then came Secure Sockets Layer in 1995, later evolving into Transport Layer Security (TLS). These protocols wrapped our communications in encryption, adding that crucial 's' to HTTPS. Despite its revolutionary impact, this transition happened almost invisibly to users. One day you visited http://bestsite.com, the next day https://bestsite. com- same site, one extra letter. Yet beneath this subtle change lay a complete transformation of internet security, although mainstream adoption came surprisingly late. Only when Google announced in 2014 that HTTPS would influence search rankings, did businesses finally rush to secure their sites.

While Web2 secured communications, it failed to reinvent value exchange. Data flowed seemingly freely, but its extracted value met the same fate as money and assets for centuries—it remained confined in centralised systems. Bitcoin changed this in 2009, introducing and validating the concept of Internet of Value: a parallel internet where assets, possibly including user data, move as freely as information. But integrating this new paradigm with Web2 architecture revealed three fundamental tensions:

First, the legacy economic model of Web2 thrives on ads and data extraction, turning users into products. It's fundamentally at odds with Web3's model, which prioritises user ownership and decentralised value exchange.

Second, digital identity remains fragmented across countless platforms. We maintain dozens of accounts, each with different credentials and trust levels, creating friction and security vulnerabilities.

Third, data provenance and trust. How do we verify data origin? How can we trust information without relying on centralised authorities?

Web3 emerges as a paradigm that reconciles these tensions thanks to blockchain's decentralised consensus. This transition, however, cannot succeed by discarding Web2's foundational architecture. Instead, it must thoughtfully integrate with existing connectivity patterns and leverage the battle-tested UX knowledge accumulated over decades.

Of the three tension points mentioned above, our demo focused on the last:

how to overcome Web2's challenges by enabling trustless data verification.

Before even unpacking what trustless data verification means, why should this matter? In a "purist" Web3 vision, blockchain already provides that layer of consensus and shared truth upon which to integrate infrastructure components (decentralised storage, DAOs, DePIN, native oracles, etc.) to completely rethink applications and services without requiring trust.

However, we cannot ignore Web2's existence or replace it overnight without considering the combined resistance to change from established business models, user habits, technical infrastructure investments, and regulatory frameworks—all aligned with the current paradigm.

This reality creates demand for transitional technologies.

History offers instructive examples of such transitions. Notoriously, paper communication didn't immediately yield to email—fax machines bridged the gap, combining physical documents with electronic transmission. Internal combustion engines aren't instantly giving way to electric vehicles—hybrids serve as the steppingstone.

Perhaps the closest example, though less widely known, is the transition from the Internet pre- to post-TCP/IP. Initially, many independent networks existed, each isolated with proprietary protocols. Gateways emerged as critical transitional technologies, allowing these disparate networks to communicate with each other while a new protocol gradually achieved widespread adoption. Once TCP/IP became universal, these gateways largely faded, though their functions were integrated into modern networking infrastructure.

The transitional technologies we presented at this year's convention enable reliable verification of data from traditional websites without requiring server-side modifications. These "web proofs" bridge the trust gap between centralised Web2 services and the verification-centric Web3 ecosystem.

To comprehend how these proofs work, we must first revisit TLS—the cryptographic protocol securing most web communications today. When you connect to a website using HTTPS, your browser and the server perform a "handshake" to establish secure communication. This process creates a shared secret key known only to these two parties. All subsequent data exchanges are encrypted using this key, protecting your information from eavesdroppers.

However, TLS has a limitation:

While it proves to you that you're talking to a legitimate website, it doesn't help you prove to others what the website told you.

The website doesn't cryptographically sign its responses, so users cannot verifiably demonstrate to a third party what data they received. In fact, message authentication codes cannot serve as public proof. In the wide panorama of zero-knowledge decentralised application developments, two prominent technologies have stood out to address this limitation:

TLSNotary uses a multi-party computation approach where a trusted "notary" participates in the TLS session. The notary doesn't see the user’s plaintext data but can cryptographically attest that the website sent specific encrypted data. This technique leverages secure multi-party computation to split the TLS session keys between the user and the notary.

Reclaim Protocol takes a different approach by introducing “attestors” who act as proxies for your TLS connection. These attestors can only see encrypted traffic but can verify your TLS session was authentic. Reclaim then allows the user to create zero-knowledge proofs about specific pieces of data within the response, revealing only what they choose while maintaining cryptographic verification of its source.

Both approaches are nascent technologies that share a common challenge: trust in the intermediary. There's always a risk that the notary or attestor could collude with the user to falsify the attestation, except when the attestor is also the verifier. However, this isn't an intractable problem. Both technologies can implement decentralised verification mechanisms where multiple independent parties must attest to the same data. TLSNotary is exploring a multi-notary approach, while Reclaim Protocol has designed an economic mechanism that incentivizes honest behavior from multiple attestors through stake-based penalties for dishonesty.

We used the live developer portal of Reclaim to build our decentralised application. To understand the underlying protocol, we invite the reader to follow the next example. Valery wants to prove to Jack that she has over $5,000 in her online bank account without revealing her exact balance or account details. These are the steps:

1. Valery initiates a request to her bank's website and routes all traffic through a Reclaim Protocol’s attestor proxy.

2. Valery's browser uses the TLS 1.3 KeyUpdate feature to create separate encryption contexts for different parts of her request. She creates one key (Ksending1) for public parts of her request (like the URL and non-sensitive headers), another key (Ksending2) for private sections (like authentication tokens), and a third key (Ksending3) for the remainder. She only shares Ksending1 and Ksending3 with the attestor, keeping Ksending2 private.

   The attestor monitors the encrypted TLS traffic between Valery and her bank but cannot see the plaintext content due to TLS encryption. For the bank's response, the server uses a single receiving key (Kreceiving), which Valery keeps private.

3. Valery logs into her account normally, and the bank returns her account information within the encrypted response.

4. The attestor digitally signs the encrypted response, certifying that it genuinely came from the bank's servers.

5. Valery uses zero-knowledge proofs to selectively reveal only that her account balance exceeds $5,000. She does this by keeping the relevant parts of the encrypted response that show her balance, replacing everything else with placeholder symbols, and proving she can decrypt these specific portions using the correct Kreceiving key.

6. Valery sends this zero-knowledge proof along with the attestor's signature to Jack.

7. Jack verifies both the attestor's signature (confirming the data came from the bank) and the zero-knowledge proof (confirming Valery’s balance exceeds $5,000).

Throughout this process, the attestor never sees Valery’s account details, and Jack only learns what Valery explicitly chooses to reveal. Yet Jack can be mathematically certain that Valery’s bank confirmed her balance exceeds $5,000 and nothing else.

What if verification needed to be public, auditable, and transparent? In which scenarios might this be necessary? For example, in a Web3 application that regulates token issuance or manages digital rights, public verifiability becomes crucial. We can achieve this by transforming verification logic into smart contract code. This is mainly possible because proofs are "succinct" and efficient to verify on-chain. To showcase a practical application of these concepts, we set to demonstrate how web proofs can work with heterogeneous data sources from different Web2 sites.

We focused on three distinct categories of data:

• Institutional Credentials: To pull driving license points from Italy's government portal "Portale dell'Automobilista." This showed how citizens could prove their good driving record.

• Philanthropic Activities: To verify donations made through GoFundMe. The application let users to cryptographically prove their charitable contributions without exposing their personal information or exact donation amounts.

• Environmental Impact: Carbon footprint scores obtained from the WRen Agency platform, enabling users to verify their environmental consciousness through their carbon offset activities.

But one may ask how hard is it to bridge multiple traditional Web2 services into a cohesive Web3 experience? Nowadays it’s possible with a simple flow like that of our application:

1. Users began by logging in either through a traditional EOA wallet like MetaMask or with Coinbase's Smart Wallet using passkeys—showcasing both Web3 native and Web2-familiar authentication methods.

2. The application generated a QR code for each proof request from the Reclaim provider.

3. Users scanned these codes or clicked on the corresponding URLs, which initiated the attested TLS session and eventually enabled zk proof generation process entirely client-side.

4. Upon successful verification, users received tokens that unlocked special privileges in an interactive game.

Throughout the demo, we emphasized the advantage of using transaction fee sponsorship, which removes the financial barrier to Web3 interaction. Also, users didn't need to install any proprietary apps, as the experience with the original Web2 sites worked through instant app clips on mobile devices.

Naturally, our game-based demo is just a toy example where privileges directly reflected the web proofs obtained: with each proof unlocking cumulative advantages, where the more proofs a user collected, the more powerful their character became in the game. Countless other use cases could be developed, from DeFi credit scoring based on verified bank history to permissionless governance participation weighted by real-world credentials.

Web3 is no longer a distant vision—it’s ready to use, and already compatible with familiar Web2 experiences.Web proofs offer a transitional layer that could remain relevant much longer than expected, helping integrate trustless verification into mainstream services.The tools are here, the UX is improving, and transitional solutions are viable: there are no more excuses to delay building meaningful applications.It’s time to fully embrace the internet of value—where users own their identity, assets, and data.