dApp/Contract Verifier

This project implements a missing link of trust in the web3 ecosystem: a decentralized mechanism for users to verify that they are interacting with the correct smart contracts and dApp for the protocol they intend. It is implemented in two components: a dApp/contract registry for protocols, and a MetaMask snap that checks potential transactions against the registry.

The registry is a smart contract that allows protocols to announce their web2 dApp domains and confirm ownership while also indicating which smart contract addresses belong to the dApp. This public indication on the blockchain where users can interact with their protocol is intended to be part of a larger entity verification mechanism, where protocols can announce their legitimate points of contact for both web2 and web3 (dApp domains, smart contract addresses for each chain, Twitter, discord, etc) and confirm ownership of each, like a decentralized keybase.io for web3 entities.

The other main component of this project is a Metamask snap that allows users to query the registry for each transaction, verifying that the dApp domain is registered and that the smart contract addresses match the domain. A fully-realized implementation of this scheme would prevent users from interacting with lookalike scam websites (because the registry would confirm ownership of multiple identity references) and could even stop front-end hacks (because the attacker would need to co-opt the domain, demonstrate ownership, and publicly update the trusted contract addresses in the registry). In the future, this mechanism could be implemented as part of every wallet to provide an indication of trust similar to the familiar green checkbox in the URL bar for browsers.

The ultimate vision of this project is a verification mechanism that can work on any blockchain and gives users the confidence that they're interacting with the actual protocol, much the same way that the certificate authorities provide users confidence for web2, but in a decentralized manner.

To get setup, a protocol hosts a signature accessible at https://theirdomain.com/proof.txt and uses our Dapp written in Next.js—which first checks if the proof is present from off-chain—to obtain a management role (which is transferred to the recovered address). This role is then used to submit which contracts are "trusted" by the protocol.

When MetaMask opens to confirm a transaction, our MetaMask cross-references the contract the transaction interacts with the set of trusted contract addresses (which are keyed by the domain name).

Under the hood, the smart contract includes a number of safety features and ensures there is no centralization risk.

• The worst case scenario, if our proof-checking bot (which allows protocols to get setup with us) were to go offline, is that no more protocols can get setup. In the future, we intend to use oracles to eliminate this possibility, but it poses no security or centralization risk.
• We (the owner) cannot revoke or control trusted contract lists after a timelock period.
• However, upon registration of a protocol, we are given a 72-hour “dispute” period to unregister a protocol. This stops a potential attack where an unregistered protocol’s website is compromised to host an attacker’s proof.
• This MetaMask snap applies to all transactions and sources; however, if a protocol is not registered with us, we show no warning (i.e., it can only add safety/benefit).
• Our project allows any project to have a form of pausing (at least, warning users) without having to implement a pausing backdoor in the contract. For example, if a protocol were hacked, the owners could empty the trusted contracts list so that all MetaMask users are prompted with a warning before interacting with the contract.

The contracts are deployed on multiple blockchains, including Polygon's Mumbai testnet, allowing protocols to register their valid dApp/smart contract address mappings for each chain.

The MetaMask snap is pure JavaScript that checks the registry for each transaction and presents information or warnings to the user.