Does the compiler version and optimizer setting have to match exactly?

Yes. The compiler recompiles your source with the exact settings you choose, then compares the result byte-for-byte against what's on chain. A different optimizer run-count, optimizer on/off, or compiler version produces different bytecode even from identical source — so it won't match. If you don't know the original settings, check the 'we noticed embedded metadata' hint above the form; it pre-fills the compiler version when it can detect one.

My contract has a constructor with arguments — what do I put in 'Constructor arguments'?

The ABI-encoded hex of the exact arguments passed at deployment, in order — the same bytes that were appended after the contract's bytecode in the deployment transaction. Each argument is a 32-byte word; multiple arguments are concatenated back-to-back. If the constructor takes no arguments, leave the field blank.

My contract imports another file — can I verify it?

Not yet through this form — it only accepts a single source file today, even though the backend format supports up to 25. If your contract has local imports, you'll need to inline everything into one file before submitting, or wait for multi-file support.

My contract links an external library — can I verify it?

Not yet — there's no field for library addresses on this form yet, even though the underlying system supports it. Contracts with linked libraries can't be verified here for now.

I submitted and got 'no match' with a byte diff — what went wrong?

Almost always one of: wrong compiler version, wrong optimizer enabled/runs setting, source that isn't exactly what was deployed (even a single changed character changes the bytecode), or missing/wrong constructor arguments. The diff shows the first byte offset where your recompiled code and the on-chain code diverge — an early divergence usually means compiler/optimizer settings are off; a late one often points to constructor arguments.

Is my source code private once I submit it?

No — a successful verification publishes your source and ABI on the public contract page immediately, for everyone. Don't submit source you don't want public.

Does the source have to come from the original deployer?

No. Anyone can submit source for any unverified contract — verification only checks that the bytecode matches, not who's submitting it. That's also why it proves nothing about the deployer's identity (see the Official badge for curated issuer identity).

I got 'too many failed attempts, wait' — what happened?

After 3 failed verify attempts on the same contract within 10 minutes, submissions are temporarily blocked to prevent brute-forcing compiler settings. Wait 10 minutes, double-check your settings, and try again.

Verify contract source

Q94cd8e406d2bb4ea251dce3f0558941f2ac056ee

Verified source ≠ safe or trusted. Verification only means the published source compiles exactly to the bytecode running at this address. It says NOTHING about whether the contract is safe, whether the owner is trustworthy, or whether your funds are safe — it just lets you read what the code does. Read the full explanation.

Paste your Hyperion source below. We re-compile it with the same settings, then compare the resulting bytecode byte-for-byte against what runs on-chain at Q94cd8e406d2bb4ea251dce3f0558941f2ac056ee.

A successful verification publishes your source + ABI on this contract page, for everyone. It does not imply Quantascan has audited the logic — see what "Source verified" does and doesn't mean.

How verification works & what each field does

How verification works

You submit the exact source, compiler version, and settings used at deployment.
We recompile it with the pinned Hyperion compiler in an isolated, network-cut-off service — it can only reach the job queue, nothing else.
We fetch the real bytecode running at Q94cd8e406d2… from the chain and compare it byte-for-byte against what we just compiled.
Match → the contract is marked verified and the Source/ABI/Read tabs unlock. No match → you get a byte-level diff showing where the two versions first diverge, so you can see what to fix.

What each field does

File name: The filename the compiler sees. Doesn't need to match anything on-chain — it just has to match what you type in "Main contract" below (filename:ContractName).
Main contract: The exact, case-sensitive name of the contract declaration in your source that was deployed here — if your file declares several contracts, this picks which one.
Source code: The full Hyperion source, unmodified from what was compiled at deploy time. A single changed character produces different bytecode and won't match.
Compiler: The exact hypc version used at deploy. Wrong version almost always means no match, even with otherwise-correct source.
Optimization: Whether the optimizer was enabled and how many runs it was tuned for. This must match the deployment exactly — the optimizer changes the emitted bytecode.
License: Cosmetic only — an SPDX identifier (e.g. MIT) shown on the contract page. Doesn't affect matching.
Constructor arguments: ABI-encoded hex of the arguments passed at deployment, in order (each argument is a 32-byte word). Leave blank if the constructor takes no arguments.

Current limitations

This form accepts a single source file and no linked-library addresses. Contracts split across multiple files (local imports) or that link external libraries can't be verified here yet.

FAQ about contract verification

Common questions about this page

Does the compiler version and optimizer setting have to match exactly?: Yes. The compiler recompiles your source with the exact settings you choose, then compares the result byte-for-byte against what's on chain. A different optimizer run-count, optimizer on/off, or compiler version produces different bytecode even from identical source — so it won't match. If you don't know the original settings, check the 'we noticed embedded metadata' hint above the form; it pre-fills the compiler version when it can detect one.
My contract has a constructor with arguments — what do I put in 'Constructor arguments'?: The ABI-encoded hex of the exact arguments passed at deployment, in order — the same bytes that were appended after the contract's bytecode in the deployment transaction. Each argument is a 32-byte word; multiple arguments are concatenated back-to-back. If the constructor takes no arguments, leave the field blank.
My contract imports another file — can I verify it?: Not yet through this form — it only accepts a single source file today, even though the backend format supports up to 25. If your contract has local imports, you'll need to inline everything into one file before submitting, or wait for multi-file support.
My contract links an external library — can I verify it?: Not yet — there's no field for library addresses on this form yet, even though the underlying system supports it. Contracts with linked libraries can't be verified here for now.
I submitted and got 'no match' with a byte diff — what went wrong?: Almost always one of: wrong compiler version, wrong optimizer enabled/runs setting, source that isn't exactly what was deployed (even a single changed character changes the bytecode), or missing/wrong constructor arguments. The diff shows the first byte offset where your recompiled code and the on-chain code diverge — an early divergence usually means compiler/optimizer settings are off; a late one often points to constructor arguments.
Is my source code private once I submit it?: No — a successful verification publishes your source and ABI on the public contract page immediately, for everyone. Don't submit source you don't want public.
Does the source have to come from the original deployer?: No. Anyone can submit source for any unverified contract — verification only checks that the bytecode matches, not who's submitting it. That's also why it proves nothing about the deployer's identity (see the Official badge for curated issuer identity).
I got 'too many failed attempts, wait' — what happened?: After 3 failed verify attempts on the same contract within 10 minutes, submissions are temporarily blocked to prevent brute-forcing compiler settings. Wait 10 minutes, double-check your settings, and try again.

How verification works

You submit the exact source, compiler version, and settings used at deployment.

We recompile it with the pinned Hyperion compiler in an isolated, network-cut-off service — it can only reach the job queue, nothing else.

We fetch the real bytecode running at Q94cd8e406d2… from the chain and compare it byte-for-byte against what we just compiled.

Match → the contract is marked verified and the Source/ABI/Read tabs unlock. No match → you get a byte-level diff showing where the two versions first diverge, so you can see what to fix.

What each field does

File name

The filename the compiler sees. Doesn't need to match anything on-chain — it just has to match what you type in "Main contract" below (filename:ContractName).

Main contract

The exact, case-sensitive name of the contract declaration in your source that was deployed here — if your file declares several contracts, this picks which one.

Source code

The full Hyperion source, unmodified from what was compiled at deploy time. A single changed character produces different bytecode and won't match.

Compiler

The exact hypc version used at deploy. Wrong version almost always means no match, even with otherwise-correct source.

Optimization

Whether the optimizer was enabled and how many runs it was tuned for. This must match the deployment exactly — the optimizer changes the emitted bytecode.

License

Cosmetic only — an SPDX identifier (e.g. MIT) shown on the contract page. Doesn't affect matching.

Constructor arguments

ABI-encoded hex of the arguments passed at deployment, in order (each argument is a 32-byte word). Leave blank if the constructor takes no arguments.