Compile the published source, compare it against the bytecode the chain actually runs, and let the comparison — not us — decide. You can reproduce every verdict yourself in one command.
A contract is “verified” when its published Solidity source, compiled with the exact compiler it was
built with, produces the same bytecode that is deployed on-chain. We don’t assert that a contract is what
it claims; we recompile it and diff it against eth_getCode. The on-chain
bytecode is the ground truth. If the recompiled bytecode matches, the source is genuine; if it doesn’t, no
amount of labelling would make it so.
The Solidity compiler embeds a build-specific metadata hash in the last bytes of every contract, so two identical sources built on different machines differ only in that trailing hash. Where that is the only difference, we mask exactly those bytes (and any per-deployment immutable ranges) before comparing, and we say so — see “Similar Match” below.
| State | What it means |
|---|---|
| ✓ Exact Match | The recompiled deployed bytecode is byte-identical to the on-chain code. Nothing was masked. |
| Similar Match | Identical after masking the compiler’s trailing metadata hash (and any immutable-variable ranges). The running logic is the same; only build-specific bytes differ. The exact normalizations are named on the contract, and re-listed by the reproduction script. |
| registry ✓ | A different, weaker check: the token is listed in Wanchain’s official bridge registry and its live symbol()/decimals() match. This is identity, not source verification — it says nothing about the contract’s code. |
| Proxy | The address is a proxy (e.g. EIP-1967); its logic lives in a separate implementation contract, linked so you can verify that contract’s source instead. |
Exact and Similar are the two source-verification tiers and are never conflated: Exact is a raw byte match; Similar is a match only after named, published normalizations. “registry ✓” is a bridge identity check and lives on the token views, not the contract tab.
Three independent links, none of which you have to take on faith:
eth_getCode, which you can call
against our RPC or any Wanchain node you trust.binaries.soliditylang.org. Same source + same compiler + same masking → same result, on your
machine as on ours.The reproduction script depends only on bash, curl, jq and
python3 — no compiler toolchain to install, nothing of ours to trust beyond the numbers it
prints:
curl -O https://orbitwan.io/verify.sh
bash verify.sh 0x924fd608bf30db9b099927492fda5997d7cfcb02
# or point it at any Wanchain node:
bash verify.sh 0xADDRESS --rpc https://your-wanchain-nodeIt fetches the proof, downloads and checksum-verifies the named solc, compiles the stored standard-JSON input, reads the deployed bytecode from the chain, applies exactly the normalizations the proof lists, and prints EXACT MATCH, SIMILAR MATCH (naming the normalizations) or FAIL (with the first differing byte offset). Change one byte of the source and it fails — as it should. Get it here: /verify.sh.
Every verdict is backed by a public JSON row you can read directly:
GET https://orbitwan.io/idx/contract/0xADDRESSverified — boolean; false carries only proxy when it is one.match_type — "full" (Exact) or "partial" (Similar).contract_name — the compiled contract’s name.abi — the compiler-emitted ABI (used to decode transactions and events).sources — every source file, verbatim, keyed by path.stdjson_input — the exact standard-JSON compiler input; recompiling it is the whole proof.match_details — normalizations applied, plus the metadata_segments and immutable_ranges byte ranges that were masked, and the onchain_bytes/compiled_bytes/masked_bytes lengths.provenance — source_repo, source_commit, source_path, compiler_version, evm_version, optimizer_enabled/optimizer_runs, the onchain_code_hash/compiled_code_hash, and verified_at.proxy — when present: pattern and implementation.