Verifiable Web

I am not looking for the any prices. I need the validation of my idea to make crypto space secure and reliable, if you like the concept please reach out to me. Now about the project:

We all remember Bybit hack 2025, compromised interfaces were used to channel the money to wrong accounts.

This protocol is a step toward a safer Web3 ecosystem. It is designed to protect decentralized applications from malicious attacks targeting the web interface layer.

Blockchains can be viewed as a foundational layer of trust, secured by consensus. Today, we are able to build highly complex dApps composed of multiple smart contracts, all protected by the underlying blockchain. However, while on-chain logic is trust-minimized, the user interfaces that expose this logic remain a weak point. Web interfaces are still vulnerable to tampering, forgery, and malicious modification, undermining the security guarantees of the underlying contracts.

This protocol addresses that gap. It provides a mechanism for verifying that a dApp is accessed through an authentic, unmodified web interface. The verification is performed on-chain, allowing users and smart contracts to cryptographically attest that the interface they interact with is exactly the one intended by the application.

The protocol is currently in an early stage and is composed of multiple components that are being developed and tested independently. Its implementation relies on the fundamental properties of content-addressable networks such as IPFS (though any network with similar properties could be used).

At the core of this design are two key ideas. First, data is addressed by a CID that is uniquely derived from its content. Second, IPFS supports multiple data formats, including IPLD, which allows us to encode not only raw data but also structured metadata. This metadata can be treated as executable instructions—a set of rules describing how the data referenced by a CID should be verified.

Using this approach, we extend the role of IPFS beyond hosting web pages. In addition to storing application assets, IPFS can also store instructions describing how and where verification should occur. While the instruction set is flexible, the core idea is simple: the same CID represents both the data and the mechanism required to verify it.

The next component is an execution engine capable of interpreting these instructions and performing the verification. The current proof-of-concept is implemented as a patch to the Chromium browser. This patched browser understands IPFS schemas and does more than simply fetch HTML markup. It also tracks and verifies all referenced sub-resources—JavaScript files, images, stylesheets, and other assets—each addressed by its own CID.

Because every component of the page is content-addressable, the entire dependency tree becomes verifiable. Any modification to a resource changes its CID, immediately breaking verification. This provides an end-to-end chain of integrity guarantees for the full web interface.

Stepping back, adaptability is also a key concern. To support existing development workflows, a prototype web application bundler/extension was created (supporting Vite, Webpack, and Next.js). This tool converts a complete web application into an IPFS-compatible format. The long-term goal is a hybrid approach where HTTP and IPFS can coexist within the same application, easing adoption without forcing a hard migration.

The final—and most complex—challenge is verifying that a web application truly corresponds to the version deployed by the dApp maintainer.

This is where the zkProxy protocol comes into play (currently ~70% implemented). zkProxy nodes act as trusted relays that query the blockchain on behalf of the browser. While zero-knowledge techniques are powerful, fully zk-based solutions are often too slow or resource-intensive for this use case. Instead, the goal is fast, cheap, and practical verifiability.

The simplest solution is to rely on RPC providers, but this introduces a problem: if an IPFS page encodes instructions pointing to a paid RPC endpoint, the secret key for that endpoint would be publicly extractable from IPFS. This must be prevented.

To solve this, zkProxy nodes function as relay providers (similar to RPC providers) that securely store RPC secrets within their infrastructure. The challenge then becomes: how can the browser make a verifiable request through a relay without trusting the relay blindly or revealing secrets?

The answer is a modified zkTLS-style approach built on garbled circuits and secure multi-party computation (MPC). The browser requests data from a smart contract (e.g., calling getCID()), but the RPC secret is known only to the relay. Using garbled circuits, the browser and relay jointly construct the JSON-RPC request such that neither party has access to the full request details. On top of this interaction, a verifiable proof—similar in spirit to zkTLS—is produced.

In summary, the full flow works as follows:

A developer or maintainer builds a web interface for their dApp and uses the bundler to convert it into an IPFS-compatible format. The application is uploaded to IPFS along with verification instructions specifying which blockchain, smart contract, and method should be used to validate the page’s CID.

When a user opens the application, the browser retrieves the page and all sub-resources from IPFS, verifies their hashes, reconstructs the CID, and loads the verification instructions. The browser then selects a relay, jointly constructs a JSON-RPC call using MPC, and the relay injects the secret and forwards the request to the intended RPC endpoint. The relay returns both the response and a proof of correct interaction.

Finally, the browser extracts the CID from the blockchain response and compares it with the locally reconstructed CID. If they do not match, the browser clearly warns the user that the interface is not genuine.