Sourcify's core verification process involves one main step: submit your compilation output, let it recompile using the same source code and compiler settings, then compare it against the on-chain bytecode. What you submit depends on which build tool you used. If you submit the wrong files, you'll get either a "No Match" or an "already_verified" error. After verification, results fall into two categories: Exact Match and Match (formerly Partial Match). The former proves not a single byte of the source code was changed, while the latter indicates the functionality is identical but comments, variable names, or file paths differ.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
What to Submit: Depends on Your Build Tool
The Sourcify verification interface is at verify.sourcify.dev. After selecting the chain and contract address, you need to provide the source code and compilation metadata. The metadata file is a JSON generated automatically during compilation and records key information like compiler version and optimization settings. Without it, Sourcify cannot recompile with the correct settings.
Submission methods vary significantly by tool. For Hardhat users, the easiest approach is to upload the build-info JSON file from the artifacts/build-info/ directory. This file contains the complete compilation input and output, allowing Sourcify to extract everything it needs. For Foundry users, the equivalent file is in out/build-info/. Remix users need to upload the contract's .sol file along with the metadata JSON from the artifacts/ directory. If you compile using the solc command line, you need to provide both the metadata generated by solc --metadata and the .sol file.
A common pitfall is dependency files. If your contract imports OpenZeppelin or other libraries, manually uploading each dependency file is error-prone. Any mismatched file path will cause verification failure. A more reliable approach is to generate a single metadata file that includes all dependency source code. Hedera's documentation provides a generation script with a useful approach: inline dependencies into the metadata for a single upload, avoiding omissions.
Result Checking: The Difference Between Exact Match and Match
After verification completes, the match field returned by Sourcify is what you need to check. exact_match means the CBOR metadata hash of the on-chain bytecode is completely identical to your submitted compilation output. Every byte of source code, every comment, and every variable name is the same as at deployment time. match means the bytecode logic portion is identical, but the metadata hash differs. Common reasons include changes to comments, variable names, or file paths, or using a flattened file (merging all source code into one file), which breaks the original metadata hash.
If you need to prove that this source code is exactly what was used at deployment, exact_match is the only acceptable result. If you just want block explorers to display the source code and ABI for easier reading and interaction, match is sufficient in practice because the contract's functional logic is identical. Sourcify officials have also mentioned that they renamed partial match to match because the word "partial" made people think the contract had not passed verification.
One special situation to be aware of: contracts with immutable variables. Solidity's immutable variables are written into the runtime bytecode at deployment time, so the bytecode produced by recompilation differs from the actual on-chain bytecode at these positions. Sourcify handles this by zeroing out the immutable positions on both sides before comparison. This does not affect the validity of the verification result, but you should know this mechanism exists, otherwise you may be confused when you see bytecode diffs.
Verification Failed? Check These Four Things First
First, compiler version and optimization settings. This is the most common cause of failure. The settings in your submitted metadata must be exactly the same as those used at deployment. If the metadata file itself is correct, Sourcify will automatically use its settings. If you manually entered the compiler version or optimization runs and made a mistake, it will cause a bytecode mismatch. BlockVision's Monad verification documentation also lists compiler version, optimization settings, and metadata consistency as the top troubleshooting items for verification failure.
Second, the already_verified error. This error does not mean verification failed; it means the contract already has a matching record and your submission did not produce a better match. Some people have encountered this in Sourcify's GitHub issues: the API shows the contract is verified, but the repo page won't open, due to caching or query issues. If you are sure your submitted source code is correct but receive this error, first check repo.sourcify.dev to see if there is already a verification record for that address on the current chain. If there is already a match record and you want to upgrade it to exact_match, you need to ensure the submitted source code and metadata are exactly the same as at deployment time, otherwise it will not overwrite the existing record.
Third, the contract address or chain is wrong. Sourcify supports multiple chains, and the same contract address on different chains may be a different contract. When submitting at verify.sourcify.dev, first confirm that the chain ID you selected matches the deployment chain. Hedera's mainnet is 295 and testnet is 296. Checking specific numbers like these before submission saves time compared to troubleshooting after submission.
Fourth, constructor arguments. If you manually submit source code instead of using a build-info file, constructor arguments need to be included in the submission. Otherwise, the creation bytecode recompiled by Sourcify will lack these parameters, causing a comparison failure. Using Hardhat or Foundry build-info files usually avoids this problem because the arguments are already included in the compilation output.
After Verification: Where to See Results
Sourcify's own repository page at repo.sourcify.dev is where you view verification details. After selecting the chain and address, you can see compilation settings, ABI, metadata, source files, and annotated bytecode, which highlights transformations and function signatures in the bytecode. The Storage Layout view also lets you directly see variable slot distribution, which is useful for auditing and debugging.
If you deploy on a chain like Hedera that has its own block explorer, verification status syncs automatically. HashScan reads verification results from Sourcify, and the contract page displays the source code and verification badge. You don't need to resubmit on HashScan; after verification passes on Sourcify, the explorer updates itself.
My Take: Prefer build-info, Don't Manually Assemble Files
If you use Hardhat or Foundry, uploading the build-info file directly is the method with the lowest probability of error. Manually selecting source files, adding dependencies one by one, and filling in compilation settings each introduces potential for mistakes. The build-info file is generated by the build tool itself and contains all the information Sourcify needs. Only when your tool does not generate build-info (like Remix or pure solc command line) should you consider manual submission, and you must pay extra attention to the completeness of dependency files.
Additionally, if you have strict requirements about whether the source code has been tampered with, confirm after verification that the result is exact_match rather than match. match is functionally trustworthy, but it cannot prove that comments and variable names have not been altered. For scenarios where you need to prove to users that the code is exactly this code, exact_match is what you need.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- Hedera·Verify a Smart Contract on HashScan, page publication or update date: not indicated on page; verification date: 2026-10-20.
- Hedera·Verifying Smart Contracts, page publication or update date: not indicated on page; verification date: 2026-10-20.
- Sourcify Docs·Verify via UI, page publication or update date: not indicated on page; verification date: 2026-10-20.
- Sourcify Docs·Exact Match vs Match, page publication or update date: not indicated on page; verification date: 2026-10-20.
- Sourcify Docs·Verification with Immutable Variables, page publication or update date: not indicated on page; verification date: 2026-10-20.
- BlockVision·Verify Smart Contract on Monad Explorer, page publication or update date: not indicated on page; verification date: 2026-10-20.
- GitHub·Verification of unichain contracts fails constantly (Issue #2429), page publication or update date: not indicated on page; verification date: 2026-10-20.
- GitHub·Verification Failed: already_verified (Issue #2483), page publication or update date: not indicated on page; verification date: 2026-10-20.
- Hedera·Smart Contract Verification API, page publication or update date: not indicated on page; verification date: 2026-10-20.
- Sourcify Docs·Repo UI, page publication or update date: not indicated on page; verification date: 2026-10-20.
- Hedera Blog·Smart Contract Verification: Sourcify.dev Now Supported, page publication or update date: not indicated on page; verification date: 2026-10-20.
