On-chain security analysis — is it a scam or legit?
EthereumThe audit of the Chain token contract identified a Medium overall risk level.
Read the full analysisEach factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed
Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x3fa6…92160xf9d0…795d0x103c…fc0f0xbfa9…c03a0x0000…8a900xcdd8…1c000x128a…ca410xbc25…43850xe242…d7690x6c4e…a326No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
mint function in ERC20Mintable (and thus Chain) is declared as public but lacks the onlyMinter modifier. This allows any user to call the mint function and create new Chain tokens by burning the specified MINT_BASE_TOKEN. While this might be an intended design for a public burn-to-mint mechanism, it deviates from the typical use of an inherited MinterRole and could lead to uncontrolled supply inflation if the MINT_BASE_TOKEN is easily acquired or if the intention was for minting to be restricted to specific roles. This is an access control flaw (7.3 Access Control).H-01The mint function in ERC20Mintable (and thus Chain) is declared as public but lacks the onlyMinter modifier. This allows any user to call the mint function and create new Chain tokens by burning the specified MINT_BASE_TOKEN. While this might be an intended design for a public burn-to-mint mechanism, it deviates from the typical use of an inherited MinterRole and could lead to uncontrolled supply inflation if the MINT_BASE_TOKEN is easily acquired or if the intention was for minting to be restricted to specific roles. This is an access control flaw (7.3 Access Control).
Clarify the intended access control for the mint function. If minting should be restricted to designated minters, apply the onlyMinter modifier to the mint function. If it is intended to be publicly accessible, document this design choice clearly and ensure the economic implications of an open minting mechanism are fully understood.
Unresolved
Chain contract's constructor mints the INITIAL_SUPPLY (21.5 billion tokens) directly to address(this). This means the contract itself holds a substantial amount of its own token. The provided code does not include any explicit mechanism or function for managing, distributing, or transferring this initial supply from the contract address. This poses an operational risk (7.8 Operations) as the tokens could become locked, inaccessible, or their distribution could be unclear, potentially leading to governance or economic issues (7.4 Economic).M-01The Chain contract's constructor mints the INITIAL_SUPPLY (21.5 billion tokens) directly to address(this). This means the contract itself holds a substantial amount of its own token. The provided code does not include any explicit mechanism or function for managing, distributing, or transferring this initial supply from the contract address. This poses an operational risk (7.8 Operations) as the tokens could become locked, inaccessible, or their distribution could be unclear, potentially leading to governance or economic issues (7.4 Economic).
Implement a clear and secure mechanism for the management and distribution of the INITIAL_SUPPLY. This could involve transferring the tokens to a designated treasury, a multi-signature wallet, or a vesting contract during deployment, or providing a controlled function for an authorized entity to withdraw and distribute them.
Unresolved
SafeMath libraries are used to mitigate integer overflow/underflow issues, this version is significantly older than current stable releases (e.g., 0.8.x). Newer compiler versions offer built-in overflow/underflow checks, gas optimizations, improved security features, and better tooling support (7.2 Code Security).L-01The contract is compiled with Solidity version 0.5.16. While SafeMath libraries are used to mitigate integer overflow/underflow issues, this version is significantly older than current stable releases (e.g., 0.8.x). Newer compiler versions offer built-in overflow/underflow checks, gas optimizations, improved security features, and better tooling support (7.2 Code Security).
Consider upgrading the Solidity compiler to a more recent version (e.g., 0.8.x). This would allow for the removal of explicit SafeMath calls (as arithmetic operations would revert on overflow/underflow by default), potentially reducing gas costs and improving code readability. Thorough testing would be required after any compiler upgrade.
Unresolved
MINT_BASE token address (0x41C3…3Ca9) is hardcoded as a public constant in the Chain contract. This creates a strong, immutable dependency on a specific external contract (7.6 External). Any future issues with the MINT_BASE token (e.g., rug pull, pause functionality, upgrade issues, or deprecation) could directly impact the Chain token's minting mechanism and overall functionality, without any possibility for the Chain contract to adapt.I-01The MINT_BASE token address () is hardcoded as a public constant in the Chain contract. This creates a strong, immutable dependency on a specific external contract (7.6 External). Any future issues with the MINT_BASE token (e.g., rug pull, pause functionality, upgrade issues, or deprecation) could directly impact the Chain token's minting mechanism and overall functionality, without any possibility for the Chain contract to adapt.
While hardcoding constants can simplify deployment, consider making critical external dependencies, like the MINT_BASE token address, configurable via a constructor argument or an owner-controlled setter function. This would provide flexibility to update the dependency if the MINT_BASE token's address changes or if a different base token needs to be used in the future.
Unresolved
approve function is susceptible to a known front-running vulnerability. If a user calls approve(spender, newAmount) while a spender is simultaneously trying to spend the oldAmount, a malicious actor could front-run the approve transaction to spend the oldAmount before newAmount is set, and then spend newAmount after it's set, effectively spending more than intended (7.2 Code Security). While increaseAllowance and decreaseAllowance functions are provided, the core approve function still exists.I-02The standard ERC20 approve function is susceptible to a known front-running vulnerability. If a user calls approve(spender, newAmount) while a spender is simultaneously trying to spend the oldAmount, a malicious actor could front-run the approve transaction to spend the oldAmount before newAmount is set, and then spend newAmount after it's set, effectively spending more than intended (7.2 Code Security). While increaseAllowance and decreaseAllowance functions are provided, the core approve function still exists.
Educate users to use increaseAllowance and decreaseAllowance instead of directly calling approve when modifying an existing allowance. For new allowances, approve is generally safe. While this is a known ERC20 limitation, ensuring users are aware of the safer alternatives is important.
Unresolved
The audit of the Chain token contract identified a Medium overall risk level. The contract implements a standard ERC20 token with a unique minting mechanism tied to burning a base token. Key findings include an unrestricted minting function, which allows any user to mint new tokens, and the initial supply being held by the contract itself without a clear distribution mechanism.
The contract leverages standard ERC20 patterns and SafeMath libraries for robust arithmetic operations, mitigating common integer vulnerabilities (7.2 Code Security). Role-based access control is implemented for minter management, enhancing security for administrative functions (7.3 Access Control). However, the mint function lacks access control, allowing any user to mint tokens by burning the base token, which could lead to unintended supply inflation (7.3 Access Control). The use of Solidity 0.5.16 is an older compiler version (7.2 Code Security).
The economic model features a fixed MAX_SUPPLY and a burn-to-mint mechanism with a 1:1000 ratio, creating a clear supply cap and a deflationary pressure on the base token (7.4 Economic). The MinterRole provides a decentralized way for existing minters to add or remove other minters (7.5 Governance). A significant operational concern is that the INITIAL_SUPPLY is minted directly to the contract address, with no explicit mechanism for its distribution or management (7.8 Operations). Additionally, the MINT_BASE token address is hardcoded, creating a strong external dependency (7.6 External).
The contract is not designed with an upgrade mechanism, such as a proxy pattern. This simplifies the architecture by removing upgrade-related complexities and risks (7.7 Upgrades). However, it means that any discovered vulnerabilities or desired feature changes would require a new deployment and migration, which can be a complex and costly process (7.7 Upgrades).
Review the intended access control for the mint function; if it should be restricted, apply the onlyMinter modifier.
Implement a clear strategy for the distribution and management of the INITIAL_SUPPLY held by the contract. Consider upgrading the Solidity compiler to a more recent version (e.g., 0.8.x) to benefit from built-in safety features and gas optimizations. Evaluate the implications of the hardcoded MINT_BASE token address and consider making it configurable if future flexibility is desired.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Chain (XCN) contract on Ethereum is 0xa2cd3d43c775978a96bdbf12d733d5a1ed94fb18. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Chain is 68/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $773.0K.
As of Sep 4, 2026, the 10 largest holders own 74.2% of the supply. The Holders section on this page shows who they are by holder type.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
