Cowrie Research

sourcify-primary-sources-2026-05-03

4 min read

Sourcify primary-source snapshot

Last reviewed: 2026-05-03 UTC

Project status snapshot

What the official materials say

1) Intro docs: Sourcify is explicitly an open verification alternative to closed verifier silos

  • URL: https://docs.sourcify.dev/docs/intro/
  • Key takeaways:
    • Sourcify says it is a source-code verification service for Ethereum smart contracts supporting Solidity, Vyper, and Yul.
    • The intro page says the project is committed to open-source, open-data, and open-standards verification.
    • It explicitly criticizes closed-source dominant verifiers, siloed datasets, stagnant APIs, and the lack of shared verification standards.
    • It frames the project as ecosystem infrastructure rather than as a single explorer feature.

2) Canonical README: the system includes a server, database, monitor, library, UI, and repository browser

  • URL: https://raw.githubusercontent.com/ethereum/sourcify/master/README.md
  • Key takeaways:
    • The README says Sourcify verifies Solidity and Vyper contracts and uses Solidity metadata plus integrity hashes for “fully verify” / exact-match workflows.
    • It breaks the stack into a verification server, PostgreSQL-backed database, monitoring service, core verification library, compiler wrappers, UI, and repository-browsing surface.
    • The README also notes that the broader sourcifyeth GitHub organization contains auxiliary services and components beyond the main monorepo.
    • This is much more like a verification substrate than a simple verification endpoint.

3) Verification UI docs: the product supports several verification inputs but prefers exact compilation preservation

  • URL: https://docs.sourcify.dev/docs/how-to-verify/
  • Key takeaways:
    • Users can verify through the Sourcify UI by selecting the chain and contract address and then importing from sources like Etherscan or by providing source files directly.
    • The docs describe single-file, multi-file, standard JSON, and metadata-based verification methods.
    • The docs explicitly recommend standard JSON or framework-native build-info paths because flattening sources can break metadata hashes and exact-match outcomes.
    • The UI also exposes verification jobs, failure diagnostics, and bytecode diffs.

4) API docs: verification is exposed as a programmatic service, not just a human UI

  • URL: https://docs.sourcify.dev/docs/api/
  • Key takeaways:
    • The API docs show POST-based verification workflows against the Sourcify server, including chain IDs, contract addresses, compiler versions, contract identifiers, and optional creation transaction hashes.
    • The example also shows an asynchronous verification-ID flow where clients poll for results.
    • This supports the view that Sourcify is intended to be embedded into tooling and automated pipelines.

5) Repository docs: verified contracts feed a broader public dataset and signature database

  • URL: https://docs.sourcify.dev/docs/repository/
  • Key takeaways:
    • The repository docs point to a signature database built from function, event, and error signatures extracted from verified contracts.
    • The intro docs separately say Sourcify shares its whole dataset daily in modern data formats and forwards new verifications to other known verifiers.
    • Together these materials show that Sourcify is operating a public data layer, not only a verification interface.

6) lib-sourcify: the verifier logic is packaged as reusable developer infrastructure

  • URL: https://raw.githubusercontent.com/ethereum/sourcify/master/packages/lib-sourcify/README.md
  • Key takeaways:
    • lib-sourcify is presented as the reusable backbone library for verifying contracts.
    • The README documents typed compilation and verification flows, browser usage, configurable RPC timeouts, configurable IPFS gateways, authenticated RPC support, and separate compiler interfaces for Solidity and Vyper.
    • This is a notable clue that Sourcify wants the ecosystem to reuse its verification primitives directly rather than treat the project only as a hosted website.

Whitepaper / technical-doc status

  • No canonical standalone whitepaper or litepaper surfaced in this pass.
  • The clearest current sources of truth are the official docs, the monorepo README, and the lib-sourcify package README.

Research notes

  • Best current category for the library: smart-contract verification infrastructure / open contract-repository and dataset / self-hostable verifier stack.
  • The strongest classification clues are the open-data repository, verification server, verification monitor, reusable core library, and explicit open-standards posture.
  • Sourcify looks especially important as shared public-good infrastructure for contract verification, research, and downstream tooling.
  • It is also a useful example of a crypto project whose core value proposition is partly political and ecosystem-architectural: replacing closed verification silos with reusable public infrastructure.

Graph View