Pending
The explorer has the request but has not finished checking it — often because the new contract has not been indexed yet. This is the normal state in the first minutes after deployment.
Transparency
Contract Verification Explained
After your token deploys, EasyTokenCreator submits its source code to the block explorer so anyone can inspect what is actually on-chain.
Are EasyTokenCreator contracts verified? Yes — after each deployment, the exact contract source is submitted to the relevant block explorer (Etherscan, BscScan, PolygonScan, BaseScan, Arbiscan, Optimistic Etherscan, or Snowtrace) for source-code verification. Verification confirms the published source matches the deployed bytecode; it does not certify that a token is safe or valuable.
What source-code verification is
Block explorers let anyone read a contract's verified source code next to its on-chain address. When an explorer shows an exact match, it means the submitted Solidity source, compiler settings, and constructor arguments reproduce the bytecode that was actually deployed. Anyone can then read the token logic instead of trusting a description of it.
How EasyTokenCreator submits verification
Immediately after the deployment transaction confirms, the app sends the contract's standard JSON source input to the explorer's verification API — the unified Etherscan V2 API with the deployment's chain ID (with the legacy BscScan endpoint as a fallback for BNB Chain). The submission includes the exact compiler version (Solidity 0.8.20), optimizer settings (enabled, 200 runs), EVM target, and the ABI-encoded constructor arguments from the deployment, so the explorer can reproduce the bytecode precisely.
Verified
The explorer matched the submitted source to the deployed bytecode. The contract tab shows the source code publicly, sometimes labeled as an exact match.
Failed
The explorer rejected the request, for example when its API is unavailable, rate-limited, or misconfigured. The on-chain token itself is unaffected — verification can be retried.
Indexing delays are normal
Explorers need a short time to index a freshly deployed contract. A submission made seconds after deployment can be answered with "unable to locate contract code" simply because indexing has not caught up. That is why a verification status can read pending right after launch and turn verified a little later without any further action.
What verification does not prove
A verified contract only means the explorer matched source code to bytecode. It does not mean the token is safe, valuable, audited, endorsed, or compliant — and it is not a substitute for a security audit. EasyTokenCreator templates have not undergone an independent third-party security audit. Read the security model for the full picture of what you sign and which risks remain yours.
Inspect a contract yourself
Open the contract address on its network explorer, check that the Contract tab shows verified source rather than an unverified notice, and compare the token name, supply, and owner functions with what the project claims. Share the explorer contract link — not screenshots — as proof of the official deployment. Common questions are answered in the FAQ.
Deploy a Verifiable Token
Every deployment submits its source for explorer verification automatically — no extra steps, no coding.