A public registry mapping Ethereum contract addresses to their projects and security contacts for transparency and vulnerability disclosure.
Ethereum Contracts List is a public registry that maps deployed smart contract addresses to their originating projects and security contacts. It solves the problem of anonymous contract interactions by providing transparency about which project a contract belongs to and how to contact them for security issues. The project aims to improve ecosystem security by facilitating responsible vulnerability disclosure.
Ethereum project teams who want to register their contracts for transparency and security purposes, and blockchain developers/users who need to identify contract ownership and security contacts.
It provides a standardized, community-maintained alternative to proprietary contract labeling services, with a focus on security contact information that's critical for vulnerability reporting. The project is backed by major ecosystem players like OpenZeppelin and Dune Analytics.
List of contracts from known projects (work in progress)
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Each project entry includes a dedicated `contacts.security` email in the JSON schema, as shown in the Uniswap example, ensuring a clear path for vulnerability disclosure.
Organizes contracts by EIP155 chain IDs, covering Ethereum and other EVM-compatible networks, which allows broad ecosystem coverage as per the data format section.
Supports future automatic addition via Solidity natspec tags (`@custom:security-contact`) and Sourcify verification, though the README notes this is not yet implemented.
Stores comprehensive details like websites, social links, and token information in project JSON files, enhancing transparency beyond just addresses.
The README explicitly states the data schema may still change as it's a work in progress, which can break integrations and require frequent updates for dependent tools.
Projects must actively submit info via GitHub forms or pull requests, and automatic import from natspec tags is not yet live, leading to potential data gaps and maintenance overhead.
The promised automated registration via Sourcify is not implemented, so reliance on manual processes limits real-time data freshness and scalability.