How to verify a token contract

Verification answers a specific question

Source verification lets an explorer match submitted compiler input to deployed contract bytecode and show the source to readers. It does not show that the code is bug-free, that allocations are fair or that liquidity cannot be removed. An independent audit and live permission checks are separate tasks.

Identify the asset first

• Record the network, exact contract address and confirmed creation transaction. Names and symbols are not unique identifiers.
• On Solana, the classic SPL mint uses the existing Token Program rather than a new Solidity contract. Inspect the mint account, authorities and metadata; an Etherscan verification submission is not the right workflow.
• On EVM, check the deployed address and code on that network's explorer before preparing a source submission. A token imported from elsewhere may use a different implementation.

Use the integrated EVM verification route

1. Open the created token's detail page and choose Verify contract when offered.
2. Review the target network and explorer. The app submits the template's exact compiler input and constructor arguments through the configured explorer service.
3. Wait for the explorer's result. A submission id is not yet successful verification; follow the reported outcome and open the explorer's source view.
4. Confirm the displayed contract source, compiler version, optimizer settings and constructor data correspond to the actual deployment.
5. Publish the verified source link with a separate explanation of supply, owner powers and liquidity conditions.

When the verification button is unavailable

The server needs an explorer API key, and its integrated verification flow does not cover Ink, Astar or X Layer. Use the network explorer's own tooling when supported. Do not change contract settings or redeploy simply because a submission service is unavailable.

For a manual EVM submission, retain the exact Solidity sources, compiler version, optimizer settings, constructor arguments and any relevant library addresses from the original build. A superficially identical contract compiled differently can produce different bytecode. The standard CryptoMuz template's compiler input is generated with the contract artifacts.

Troubleshoot a mismatch

• Wrong network or address: compare the source submission to the confirmed creation receipt, not a similar token name.
• Wrong template version: older deployments may use a legacy template. Use the original artifact rather than the latest source merely because it has the same contract name.
• Compiler or optimizer mismatch: use the recorded build configuration and the full source input, not an edited copy.
• Explorer service failure: preserve the successful on-chain deployment and retry verification later. Verification availability does not determine whether the token exists.

Give readers a complete evidence set

Link the address, verified source when available, creation transaction, current permission state and pool/lock information. State plainly whether an independent audit exists and what it covered. Source verification should help readers inspect the asset, not be presented as a safety badge.

Continue with contract management for owner and authority checks, or liquidity and locks for the market conditions code verification does not establish.