What does 'Source verified' mean?
In one sentence
Verification proves that the source code shown on this page compiles, byte-for-byte, into the bytecode that actually runs on the chain. It does not mean the code is safe, audited, or that the issuer is who they claim to be.
What verification DOES prove
- The source you read is the source that was compiled — no hidden fork.
- The ABI is correct, so wallet integrations work safely.
- Independent audits can be reproduced — anyone with the same compiler can verify your claim.
- On a 🥇 Source verified (full) match, the source's metadata-hash matches the fingerprint the compiler embeds at the very end of the on-chain bytecode (the "CBOR metadata tail"): cryptographic 1-to-1 proof, no explorer trust needed.
What verification does NOT prove
- That the code is safe to interact with.
- That the deployer is who they claim to be (copycat-name scams like fake USDC are common; for issuer identity, look for 🛡️ Official).
- That admin keys, oracle feeds, upgrade proxies, or governance multisigs are honest.
- That balances stored in the contract are safe from a rug.
Three real-world examples
- Squid Game (SQUID) — Nov 2021. Verified on BSCScan. The
transfer()function had a sell-block that only whitelisted dev wallets could pass. Anyone who read the source before buying could have seen it. - MUMI (MultiMixer AI). Verified source contained a hidden
swapTokensForEthfunction siphoning to a tax wallet. Verification didn't stop it — but it WAS visible to anyone who clicked the Source tab. - AnubisDAO — Oct 2021, $60M lost. Verified, legitimate-looking OlympusDAO fork. The exit was off-chain: the deployer kept all LP tokens. No amount of source reading would have prevented it; on-chain LP-ownership analysis would have.
5-minute checklist for reading verified source
transfer()/_transfer(): any tax / fee / cap logic?mint(): owner-callable? Can supply grow without limit?owner()/Ownable(the standard access-control pattern marking functions only the deployer can call): who can call privileged functions? Has ownership been renounced?pause()/blacklist()/freeze(): can the owner block your wallet?- Any external
delegatecall(code that runs another contract's logic with this contract's storage and permissions) or proxy pattern? Who controls the implementation?
Match-grade explained
🥇 Source verified (full)The metadata-hash in the on-chain CBOR-tail matches the metadata-hash of your recompiled source. Cryptographic proof — no explorer trust required.
Source verified (partial)The functional code matches but the metadata-tail differs (comments, var names, or paths were changed after deploy). Still accurate for reading the source; just not cryptographically tight.
UnverifiedNo source has been submitted for this contract yet. Anyone can submit it via the "Verify" button on the contract page.
Verified vs Official
Source verified is automated — it says nothing about who issued the contract. 🛡️ Official is curated by Quantascan admins for known issuers (e.g. "Circle: USDC Token" → only the canonical address). Combine the two for trust + transparency.
FAQ about verification
Common questions about this page
- Does 'Source verified' mean a contract is safe?
- No. Verification only proves the source code shown matches the bytecode running on chain. It says nothing about whether that code is safe, audited, or honest — a verified contract can still contain a hidden sell-block, an unlimited mint, or an owner backdoor. Always read the source before trusting it.
- What is the difference between a full and a partial match?
- A full match means the metadata hash embedded in the on-chain bytecode is byte-for-byte identical to your recompiled source — cryptographic 1-to-1 proof. A partial match means the executable code matches but the metadata tail differs (comments, variable names or file paths changed after deploy). Partial is still accurate for reading the logic; it's just not cryptographically tight.
- What does the 'Official' badge add on top of verification?
- Source verification is automated and says nothing about who deployed a contract. The Official badge is curated by Quantascan admins for known issuers (for example, only the canonical USDC address). Verified proves the code; Official vouches for the identity. Look for both.
- How can a verified token still be a scam?
- Verification proves the code is genuine, not that it is honest. A verified contract can still hide a sell-block, an unlimited mint, an owner that can freeze wallets, or a proxy whose logic can be swapped after deploy. Read the source for these red flags before trusting it.
- Can I verify a contract myself?
- Yes. Any unverified contract has a Verify button on its contract page. Submit the source and the exact compiler settings; if the recompiled bytecode matches what's on chain, the contract is marked verified for everyone.