Verifying Contracts

TL;DR

Source is on-chain. To verify a contract, compare BLAKE3 hashes — the hash of the source you were shown vs. the hash of what's actually deployed. One command. No compiler to trust, no flags to match, no Etherscan submission form.

No submission step

On Ethereum, "verifying" a contract means submitting the Solidity source to a third party (Etherscan), which recompiles it with the exact same compiler version and flags you used, and checks if the resulting bytecode matches what's on-chain. The verifier becomes part of the trust boundary.

On Asentum there is no bytecode. The deployed artifact is the source. There is nothing to submit, match, or trust — reading the source on the explorer is the verification.

Verify it yourself

Suppose a project publishes a contract at 0xabc… and claims its source is contract.js in their GitHub repo. To verify:

If the hashes match, the source you're reading is exactly what executes. If not, someone's lying about what got deployed.

The hash match

Asentum hashes contract source with BLAKE3. The hash is:

• Recorded in the contract's state at deploy time.
• Retrievable at any time via asentum_getContractHash.
• Displayed on the contract page in the explorer.

Reproducing it locally takes one command: b3sum contract.js (or the BLAKE3 library of your choice). If the source file you have matches, the hashes match.

Why this matters

• No verifier oracle. You are not trusting Etherscan to be honest, available, or un-compromised. The chain is authoritative.
• No compiler version trap. "It compiles the same source to different bytecode with Solidity 0.8.20 vs 0.8.21" doesn't happen here — there's no compiler.
• No "close enough" matches. Either the hash matches exactly or it doesn't.

Immutability label

Every contract page in the explorer shows an immutability label: immutable, upgradeable proxy, or self-destructing proxy. Reading the label is the first thing you should do before interacting with anyone's contract. For the mental model see Smart Contracts.