Verifying Contracts

Why verification matters

A deployed contract on chain is bytecode — opaque, unreadable, indistinguishable from any other unreadable byte blob. Verification is the act of publishing the original source code alongside the deployed bytecode and letting the explorer prove that the source compiles to exactly those bytes. Once verified, anyone can read the contract before they trust it with their VLD.

On Valdium the situation is friendlier than on EVM chains — contracts ship as Hardened JavaScript rather than compiled-from-Solidity bytecode — but verification is still required, because the deployed bytes are post-lockdown and post-minification: not the same characters the developer wrote.

What "verified" guarantees

A verification badge in the explorer means three things:

Source is exact. The published source, when run through the canonical Valdium compiler at the published version, produces a bytecode that matches what's on chain byte-for-byte.
Compiler is canonical. The compiler version and flags are public; anyone can reproduce the build.
Imports resolve to known versions. Every import statement points at a package on the approved libraries list at a specific version.

It does not mean the contract is safe, audited, or doing what its name says. Verification proves you're reading the code that ran; it does nothing to tell you the code is correct.

Verifying from the CLI

The fast path: submit verification at deploy time.

valdium deploy ./MyToken.js \
  --constructor-args 'TestToken,TST,18,1000000' \
  --verify

This deploys the contract, waits for inclusion, then uploads the source to the explorer's verification service. The service rebuilds with the same compiler version and flags, compares bytecode, and either confirms the match (badge appears) or reports the mismatch with a diff.

To verify an already-deployed contract:

valdium verify 0x5aC14fD3A2c0e8ee48B07C8A3D1Ebf27b0EeDF0C \
  --source ./MyToken.js \
  --compiler-version 0.5.14 \
  --constructor-args 'TestToken,TST,18,1000000'

Multi-file contracts

For contracts that import from sibling files, pass the project root instead of a single file. The CLI bundles every imported file into the submission:

valdium verify 0x5aC14… \
  --root ./src \
  --entry ./src/Vault.js \
  --compiler-version 0.5.14

Anything imported from node_modules is resolved to the published-version-on-npm and pinned in the submission. The explorer rebuilds against the same npm tarballs.

The verification page

Once verified, the contract's page on explorer.valdium.xyz grows three tabs: Code, Read, and Write.

Code renders the source with syntax highlighting, the compiler version pinned at the top, and a one-click link to download the full source bundle.
Read lists every public method that doesn't mutate state and lets the visitor call it without a wallet.
Write lists every state-changing public method and lets the visitor connect a wallet and call it inline.

Wallets also pull this data — when a signing prompt comes up for a verified contract, the decoded function name and argument labels render straight from the verified source.

Failure modes

Bytecode mismatch. The most common failure. Usually means the submitted source uses a different compiler version, different optimizer flags, or has trailing whitespace differences. The diff in the error tells you which bytes differ; in practice it's almost always the compiler version.

Constructor arguments wrong. The constructor's encoded args become part of the deployed bytecode tail. If you typed different args than the deploy used, the tail won't match. The CLI auto-fetches the deploy tx to extract the actual args; pass --constructor-args only when you have a reason.

Unknown imports. An import from a package that's not on the approved-libraries list will reject at compile time. You cannot deploy a contract that imports an unapproved library, so this should never fire post-deploy; if it does, you're on a custom node that allowed something the public chain wouldn't.

Verification and re-deploys

Verification attaches to a specific deployed address. A re-deploy is a new contract with a new address that has to be verified again. There is no "upgrade verification" — if you use a proxy, only the implementation contract gets a code badge; the proxy gets a special "proxy-pointing-at-X" treatment instead.

Build · Approved Libraries → Use · Interact with a Contract →