# Sourcify: Contract Verification Beyond Etherscan

Author: Markus Waas

Published: 2020-11-21T22:38:54.000Z

Updated: 2026-09-13T14:25:30.000Z

Source: [https://soliditydeveloper.com/sourcify](<https://soliditydeveloper.com/sourcify>)

## Compatibility and review

Before you start

This article began in 2020. Verification instructions now link to the current Sourcify UI, Remix plugin and Hardhat integration. Old screenshots and the Rinkeby example are historical. The metadata-extraction snippet was checked locally; no live verification submission was made.

[Official reference](<https://docs.sourcify.dev/docs/how-to-verify/>)

We all love [Etherscan](<https://etherscan.io/>). It’s a great tool for reading contracts, interacting with them and checking transactions. But it is a hosted service. Having another way to retrieve and verify a contract’s source is useful when one provider is unavailable.

This article explores that part of the problem: open verification tooling, reproducible compilation and access to contract metadata. Sourcify is not a replacement for every feature of an explorer. Let’s take a look.

![Decentralization Meme](<https://cdn0.scrvt.com/b095ee27d37b3d7b6b150adba9ac6ec8/0082dc5ca74735d5/dd68bf029fa7/v/b071f12ae887/decentralization-meme.jpg>)

## The problems solved by Etherscan

Obviously Etherscan has evolved to something with many different functions by now. But we only want to focus on the main ones here which is also why I believe that a decentralized Etherscan by no means would imply the end of Etherscan itself. Let's get the core functions done in a decentralized way, because those are the security-critical ones. So what is critical here in my opinion?

1. Source Code Availability
2. Interaction via ABI
3. Transaction Status

### Problem 1: Source Code Availability

Without source files, you’re left with bytecode and whatever a decompiler can recover. Verification lets someone recompile submitted sources and compare the result with the deployed code.

If your only copy of those sources lives behind one explorer, an outage makes them harder to retrieve. That does not mean every copy disappears: a project may also publish its repository and artifacts elsewhere. Independent copies and reproducible verification are the useful goal here.

A verification badge is not a security audit. You still need to review what the contract does.

### Problem 2: Interaction via ABI

The ABI describes how to encode calls and decode results and events. Without it, interaction becomes much less convenient, although known signatures can still be encoded manually.

A function selector is the **first four bytes** of the Keccak-256 hash of its canonical signature, such as `transfer(address,uint256)`. It is not the last four bytes of the name and arguments. A selector alone also cannot recover a complete ABI: different signatures can share a selector, and output types are not part of it.

### Problem 3: Transaction Status

People also use explorers to check transaction status. A wallet may link to one, but that does not make the explorer the source of chain consensus. You can query a node for the transaction and its receipt; your choice of RPC provider still matters.

The November 2020 infrastructure outage discussed in the original post was a reminder about relying on one hosted endpoint. Sourcify solves a different problem: contract source verification and availability.

## Solving Problem 1 and 2: Sourcify - A Decentralized Alternative

[Sourcify](<https://sourcify.dev/>) provides open source verification tooling and a shared contract dataset. You can browse verified artifacts at [repo.sourcify.dev](<https://repo.sourcify.dev/>).

There are still hosted servers and a database behind the service. The useful difference is that the tooling and artifacts can be reused, and metadata can be retrieved by its content hash. Calling the entire service “decentralized” skips that distinction.

### A. What is the Metadata?

Solidity produces a JSON metadata file with the compiler version and settings, ABI, NatSpec documentation and information identifying the source files. Source contents may be embedded, or referenced by URLs with hashes.

The metadata helps reproduce the compilation and build interfaces. It does not, by itself, tell you whether using the contract is safe. The [Solidity metadata documentation](<https://docs.soliditylang.org/en/latest/metadata.html>) describes the format.

By default, Solidity appends a CBOR-encoded metadata **hash** and compiler information to the runtime bytecode. The entire JSON file is not stored there. Compiler settings can change or disable this trailer.

Because metadata includes source hashes, changing comments or even whitespace can change that fingerprint. [Sourcify distinguishes an Exact Match from a Match](<https://docs.sourcify.dev/docs/exact-match-vs-match/>); check the actual result instead of assuming every verification badge makes the same claim.

### B. Let's use IPFS to store the Metadata

Once we have a content hash, we still need someone to keep the file available. IPFS addresses content by its identifier; it does not promise permanent storage just because a file was added once.

Sourcify serves source artifacts and metadata and can pin them to IPFS. Keep your own compilation inputs and source files too.

The original example used chain ID `4`, Rinkeby, and is retained here only as a historical reference. For a current contract, open [the repository](<https://repo.sourcify.dev/>), choose the correct chain and address, and inspect its sources, metadata and match result.

### C. How to publish your contracts via Sourcify

You can submit an existing deployment for verification through the UI, framework integration or API. Keep the compiler settings and complete source input from the actual deployment.

Sourcify also runs a [monitor](<https://docs.sourcify.dev/docs/monitoring/>) on selected chains. When it can retrieve a new contract’s metadata and sources, it can try verification automatically. Check the supported-chain list and the result; publishing a file to IPFS is not a universal guarantee of automatic verification.

#### (I) Manually

Open [verify.sourcify.dev](<https://verify.sourcify.dev/>), choose the chain and enter the deployed address. Supply the original Standard JSON input or supported build-info file. The metadata route also needs all the source files.

Select the contract, submit the verification, then read the job result. Don’t flatten or silently reformat the sources if you want their metadata hashes to match. The [current UI guide](<https://docs.sourcify.dev/docs/how-to-verify/>) covers the available inputs.

![Sourcify UI](<https://cdn0.scrvt.com/b095ee27d37b3d7b6b150adba9ac6ec8/473d9f0154a81bf2/602256e73a43/v/2ce99dc73464/Sourcify-UI.png>)

#### (II) Remix

In Remix, compile the contract with its original settings. Then enable **Contract Verification** in the plugin manager, open the plugin, choose the chain and deployed address, and select the compiled contract.

The plugin supports several verification services. Check the result in its receipts view. See the [current Sourcify/Remix instructions](<https://docs.sourcify.dev/docs/verify-via-remix/>); the screenshots beside this section show the older interface.

![Remix Publish Compile](<https://cdn0.scrvt.com/b095ee27d37b3d7b6b150adba9ac6ec8/d7c45e90965031ce/5b304024c07d/v/c67bb9fbb552/Remix-Publish-Compile.png>)

This is the old Remix publishing interface. Publishing metadata and source files is useful, but the verifier still needs the right chain, deployed address and compilation inputs. Check its result after deployment.

![Remix Publish Deploy](<https://cdn0.scrvt.com/b095ee27d37b3d7b6b150adba9ac6ec8/2a6954d7ff2ac686/3834d126a84b/v/33e897e2a586/Remix-Publish-Deploy.png>)

![Sourcify Remix](<https://cdn0.scrvt.com/b095ee27d37b3d7b6b150adba9ac6ec8/bb5cc7743936f7ab/82aa08101ebb/v/40137ce906a6/Sourcify-Remix.png>)

#### (III) Existing Truffle projects

[Truffle and Ganache were sunset](<https://consensys.io/blog/consensys-announces-the-sunset-of-truffle-and-ganache-and-new-hardhat>). This section is useful if you still have an old project’s artifacts, not as a setup recommendation for a new one.

A Truffle artifact may contain the metadata JSON as a string in `.metadata`. The local script below extracts it without reformatting it. It does not upload files or verify a contract. Collect every original source file referenced by that metadata and use the [current verification UI](<https://docs.sourcify.dev/docs/how-to-verify/>).

```javascript
// Usage: node extract-metadata.cjs build/contracts/MyContract.json
const fs = require('node:fs');
const artifactPath = process.argv[2];
if (!artifactPath) throw new Error('Pass a Truffle artifact file.');
const artifact = JSON.parse(fs.readFileSync(artifactPath, 'utf8'));
if (typeof artifact.metadata !== 'string' || !artifact.metadata.trim()) {
  throw new Error('This artifact does not contain a metadata JSON string.');
}
JSON.parse(artifact.metadata); // Check that the metadata is valid JSON.
fs.writeFileSync('metadata.json', artifact.metadata, { flag: 'wx' });
console.log('Saved metadata.json. Keep all original source files as well.');
```

#### (IV) Hardhat (ex Buidler)

Hardhat now has Sourcify support through `@nomicfoundation/hardhat-verify`. For Hardhat 3, install/register that plugin if your template did not already include it, then run its verification task against your configured network and deployed address.

Use the [Hardhat 3 instructions](<https://docs.sourcify.dev/docs/verify-via-hardhat/>) or the linked Hardhat 2 documentation for your project’s version. There’s no need to wait for a 2020 TODO item. ;)

## Going beyond Etherscan

What we've discussed so far is the most pressing issue and likely the first becoming used more.

But we can even go one or actually two steps further.

### Integration into wallets

The metadata adds further support for Natspec as explained [here](<https://docs.soliditylang.org/en/latest/metadata.html#usage-for-automatic-interface-generation-and-natspec>). This is good news as Natspec is already widely used for Solidity contracts. Usually as pure developer documentation, the Natspec could now also be used as user documentation.

Remember the last time you confirmed a transaction?

Did it look anything like shown on the right?

Yeah, we all know exactly what this transaction will be doing. This is where the Natspec can come in. Instead of this dialogue, a user might get a description such as

*'Swap 100 ETH for at least 45,000 DAI if the trade is executed within the next 100 seconds.'*

Now this is quite a bit more readable than the hex data, isn't it?

![MetaMask Confirm](<https://cdn0.scrvt.com/b095ee27d37b3d7b6b150adba9ac6ec8/bdec7fccfbfa5cdd/9423bec5bcf5/v/d05aebc320d1/MetaMask-Confirm.png>)

The old MetaMask integration mentioned here was an experiment at the time of writing. Treat the transaction-description example as a design idea, not a claim that every wallet displays or validates NatSpec today.

Readable descriptions still need to agree with the transaction being signed. Source verification cannot make a misleading description trustworthy.

### Transaction Status and Mempools

Transaction inclusion, finality and the public mempool are separate concerns from source verification. You can query an execution client for a transaction and its receipt; a source-code verification result does not establish its transaction status or prevent front-running.

This was the longer-term infrastructure question in the original 2020 post. It remains useful to separate the pieces: retrieve the code, check what it does, understand the transaction, and check its onchain result. Sourcify covers the verification part of that workflow.

## Decentralization: One step at a time

![Yoda meme: “Small steps, younglings.”](<https://cdn0.scrvt.com/b095ee27d37b3d7b6b150adba9ac6ec8/ef1c82017b6db280/4fe14e305552/v/121d0ffab646/small-steps-meme.jpg>)

Independent access to source files and reproducible compilation are useful foundations. Sourcify’s [repository UI](<https://repo.sourcify.dev/>) now lets you inspect contracts, their sources and verification details.

There is still room for interfaces that make those details easier to understand. If you need a hackathon idea, a useful contract interface with clear verification information is a pretty good place to start. ;)

If you have not seen the original posts about Sourcify by the main guy behind Solidity, Christian Reitwiessner aka chriseth, check them out here:

- [https://chriseth.github.io/notes/articles/closing\_the\_trust\_gap/part1](<https://chriseth.github.io/notes/articles/closing_the_trust_gap/part1>)
- [https://chriseth.github.io/notes/articles/closing\_the\_trust\_gap/part2](<https://chriseth.github.io/notes/articles/closing_the_trust_gap/part2>)
- [https://chriseth.github.io/notes/articles/closing\_the\_trust\_gap/part3](<https://chriseth.github.io/notes/articles/closing_the_trust_gap/part3>)