Skip to main content

Sourcify in 2025: Mission, Goals, and Roadmap

· 10 min read
Kaan Uzdogan
Kaan Uzdogan

Sourcify is a project that has been around for technically more than 5 years. Now as part of the Argot Collective, we will be sharing our detailed roadmaps frequently. While we are on it, we thought it's a good chance to look back into why we exist, what problems we are trying to solve, what we've done so far and lay out our roadmap.

Problem Statement​

Ethereum has an established open-source culture and is built on open-source tooling. The Ethereum community also demands the smart contracts to be open-sourced (i.e. source-code verified). After all, Ethereum's core principles such as trustlessness, transparency, verifiability etc. do rely on the contract code being verified and open-sourced.

However, we believe the source-code verification ecosystem plateaued at a suboptimal point:

  • Lack of open-source: The most used verification service itself is not open source and the whole verification process is a black-box, while the majority of people (wrongfully) assume that it is open-source.

  • Centralization: There is centralization on who verifies contracts. Contracts should be verified in multiple places and when needed cross-checked across verifiers. Because all verifiers will make mistakes and have bugs

  • Closed datasets: Right now smart contract data is siloed in proprietary services. Yes, one can "see and read" individual contracts but the dataset is closed and almost impossible to assemble through APIs, or scraping (usually against the terms of the service). The reliance on closed and proprietary datasets poses a long-term existential risk to Ethereum if those services were to vanish. In a way this already happened with older testnets and part of the Ethereum's history is lost alongside the verified contracts there.

    The absence of accessible and open datasets is holding the innovation on many fronts:

    • Bulk testing EVM tooling with smart contracts
    • Finding vulnerability patterns
    • Training AI models
    • Any kind of data analysis over source code

  • Tooling stagnation: The APIs and tooling around verification are old and not improving. For example, there are so many verification artifacts that can be useful for tooling (storageLayout, sourceMaps, cborAuxdata, transformations) but they are not available in current APIs.

  • No integrity hash support: Existing verifiers don't leverage "exact matches" i.e. the integrity hashes provided by the Solidity and Vyper compilers. This gives a cryptographic guarantee that the whole compilation, including the source code, is exactly the same as the original (even whitespaces etc.)

  • Lack of standards and public knowledge: There are no standards around source-code verification and no knowledge exchange across verifiers. But also no public resources to learn about the verification process. For instance, we weren't able to figure out how to verify contracts with multiple metadata hashes (e.g. nested contracts with factories) until we started discussing it with Blockscout. This led us to use another workaround as detailed in this blog post. Another example is that there is no place to look for the edge cases and tests for verification.

By observing the current direction and the incentives of ecosystem players we believe the ecosystem will not be able to break out of this "plateau", unless there is intentional intervention to drive it forward.

Our mission at Sourcify is to play the coordinator and the builder role to create an open, decentralized, and dynamic smart contract verification ecosystem, powered by open-source tools, accessible datasets, and shared standards, to empower the EVM tooling and uphold Ethereum’s core values.

Goals​

How do we plan to achieve these?

To create decentralization in the space, it's important to tackle the issue (i.e. contracts only verified at one place) at the beginning (funnel) of the verification pipeline. The contracts should be verified everywhere and it shouldn't be a burden for the user. For this, an important goal is to:

  • Convince frameworks to verify everywhere in parallel by default. We already shipped the Remix plugin that does this. Next step is to do the same in Foundry and Hardhat.
  • Secondly, maintain and promote the Verifier Alliance as a shared database of verified contracts.

In addition, to empower the EVM tooling and developers we want to:

  • Provide as much information from verified contracts as possible: raw bytecodes, abi, storageLayout, sourcemaps, transformations, cborAuxdata. Anything that can be useful for tooling.
  • Build a 4-bytes DB based on the verified contracts
  • Export and publish the DB and make it publicly queryable.

Finally, to improve the verification experience we want to:

  • Provide as much context and information to the user if a verification fails. Give detailed error messages, show differences between onchain vs recompiled bytecodes. Visualize this data on the UI.
  • Make it very easy for users to report issues if they really think a verification unexpectedly fails. Close the loop between the user and the verifier.

Achievements​

What we did so far since about 12 months ago:

Roadmap​

We work in 2-week sprints (sprint board) and every quarter we have a retrospective and a planning session (quarterly board). Our concrete quarterly goals as of today:

2025 Q3:

2025 Q4:

Non-milestone goals:

  • Now that the product is technically sound and ready to scale, boost visibility.
  • Get back to giving talks at conferences. Talk about problems, Sourcify's role, and the Verifier Alliance

Costs​

We are running on a fully scalable containerized GCP setup. Currently it costs us around $4.5k-5.5k a month to run Sourcify + Verifier Alliance.

  • 50% Cloud Run
  • 25% Cloud Filestore (NFS) (Used for RepositoryV2. Will be phased out in favor of just DB)
  • 10% Logging
  • 15% Networking, SQL, Monitoring, Misc

Still, financial sustainability is one big question we need to solve long term. Sourcify has been an EF funded project and now as part of the Argot Collective, we are still funded for the foreseeable future.

Being non-profit and funded gives us more credibility and a neutral position, and allows us to act more as a coordinator between the ecosystem players. For the project to be sustainable and to succeed long term, we need to find a way to make it self-sustaining, while avoiding capture.

History and background​

Sourcify started within the Ethereum Foundation as a Solidity side project around 2019 and an MVP was developed by Shard Labs until Kaan was hired in Sep 2021 and the project was brought back in.

Sourcify's UI in 2021

Sourcify's UI in 2021

At the time, the project's main focus was fostering the use of the Solidity metadata and the IPFS/Swarm hashes that act as an integrity hash here for the compilation and verification, and also allowed the decentralized storage of these files. The whole repository at the time was a file system and pinned on IPFS (nodes that we run ourselves, not fun). In fact the whole setup was being run in an old bare-metal server in the EF Berlin office and manually managed. That didn't last long as it was very cumbersome and time consuming and we moved to a VPS. Both running a bare-metal and a VPS are almost part-time jobs. Now we are on a fully scalable containerized GCP setup.

Another focus we had was to promote the NatSpec comments which are found in the metadata.json file and use them to enable human-readable transactions. We hacked some helper libraries, talked about it in the conferences, and created a working group but after a while we realized this is not something we can tackle with 2 people and we have to prioritize source-code verification and having a well-functioning platform. This was around mid-2023 and Marco joined around 6 months ago. Finally, Manuel joined the team mid-2024 making us a team of 3.

Looking back, we've made some good and bad decisions:

  • Running bare metal was never a good idea. It consumed so much time for us and we were firefighting all the time.

  • Natspec and human-readability focus also distracted us a lot and it took a while to find our real value proposition.

  • In the meantime we had a lot of technical debt we had to solve as the project has grown. Running everything on a filesystem on scale is impossible. At the time this might have been a natural choice for an MVP since also everything was hosted on IPFS (which is a filesystem). We should've moved away from this much earlier.

  • We attended a lot of conferences and it helped a lot with the visibility and meeting people who both help us and care about our mission.

  • We decided to accept all EVM chains for verification and not only those "close" to Ethereum e.g. L2s. This exposed us to a long tail of EVM developers and they all learned about Sourcify. Thanks to that, we also have a good number of self-hosted instances running.

  • It's very difficult to run such a project as a one-man show. Minimum two brains and two pairs of eyes are required to make technical progress and three to thrive.

  • It's all about attention. Technical problems are easier to solve but the difficult part is to change the user behavior. As long as people don't have Sourcify in mind when verifying their contract, having the most elegant technical solution is useless.