Verification

Available since: Acton 1.2

The ticket-based verifier workflow described here is available from Acton 1.2.

Source code verification publishes reproducible local Tolk sources for a compiled code hash. Acton compiles the contract, requests a verification ticket, sends the required TON testnet payment, and uploads the source bundle to the TON verifier.

Available since: Acton 1.2

Validate contract behavior in local tests and a simulator network before testnet deployment and source verification.

Before verification

Prepare these inputs before running acton verify:

a wallet configured in Acton or a TON Connect wallet
a .tolk contract that is defined in Acton.toml
enough testnet GRAM for the verifier payment and network fees

The acton verify command accepts Tolk contracts. The verifier service also accepts FunC and Tact through its own interface and supports mainnet payments; the Acton CLI uses testnet. Arbitrary .boc contracts are not supported by the verifier flow.

For a new verification, --address checks that the local sources compile to the same bytecode as the deployed contract. Already verified code succeeds before this address check. Run verification from the same source revision and compiler configuration used for deployment.

Verify source code

Run acton verify with the contract name from Acton.toml and a configured testnet wallet:

acton verify Counter --wallet deployer

The TON verifier uses TON testnet. If the project defines only one contract, the contract name can be omitted. If multiple contracts are available, Acton prompts for the selection.

On success, Acton prints a verifier link for the contract:

terminal

✓ Contract verification completed!
View at: https://verifier.ton.org/0123abcd...

To compare the compiled code with an active testnet contract before payment, pass its address:

acton verify Counter --address EQDt7LL... --wallet deployer

Acton first checks /api/v1/verification/status for the compiled code hash. If verification is queued or compiling, Acton waits for it. If that code hash is verified, Acton stops successfully and does not request wallet access. Otherwise, Acton requests a payment ticket from /api/v1/take_ticket.

For new code, the backend returns a testnet address, a minimum amount, and a comment. The comment has this form:

acton-verify:v1:<code_hash>

Acton displays the quote and requests payment approval. Then Acton sends the payment and waits for the finalized recipient transaction. The source upload contains that transaction hash.

One transaction can authorize only one verification attempt. The backend also makes sure that the amount, destination, finality, and comment are correct.

If an upload retry needs an existing payment, pass its finalized recipient transaction hash:

acton verify Counter --payment-tx-hash '<transaction-hash>'

Choose the wallet for the verification transaction

When more than one wallet is configured, use --wallet to pick the sender for the verification payment:

acton verify Counter --wallet deployer

If exactly one wallet is configured, Acton selects it automatically. If multiple wallets are available and --wallet is omitted, Acton prompts for the selection.

The verifier uses the amount from the payment ticket.

If a backend reports that the code hash is verified, Acton exits successfully without another transaction.

Use TON Connect for the verification transaction

Pass --tonconnect to approve the verification payment through a TON Connect wallet instead of a wallet from wallets.toml:

acton verify Counter --tonconnect

Acton prints a native TON Connect QR code and a tc:// link.

Check the verifier flow without sending the transaction

Use --dry-run to prepare verification without sending payment or uploading sources:

acton verify Counter --address EQDt7LL... --dry-run

Acton requests a ticket and prepares the source request. It does not send the testnet payment or upload the sources. Therefore, this mode does not confirm that the backend accepts the source package.

Pin the compiler version

If the deployed contract was built with a specific Tolk compiler version, pass that version explicitly:

acton verify Counter --address EQDt7LL... --compiler-version <TOLK_VERSION>

Verification compares the deployed code with the bytecode produced from the submitted sources and compiler settings. A different compiler version can produce a different result even when the source files are unchanged.

Troubleshoot verification failures

A bytecode mismatch usually means that the local sources, imports, or compiler settings differ from the deployment inputs.

Common causes include:

a different Git revision than the one used for deployment
a different Tolk compiler version
changed generated or imported source files
verifying the wrong contract name or address

Backend errors include the HTTP status, request URL, and response body when available.

To test a specific verifier backend, set ACTON_VERIFY_BACKEND:

ACTON_VERIFY_BACKEND=http://127.0.0.1:3000 \
acton verify Counter --dry-run

Reuse the same payment only when the backend explicitly reports a retryable source storage failure. Other results after the payment claim consume the payment.