Is Chain (XCN) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low2 Info

High

Unrestricted Minting Function

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).

IssueThe `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).

FixClarify 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.

StatusUnresolved

Medium

Initial Supply Held by Contract Address

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).

IssueThe `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).

FixImplement 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.

StatusUnresolved

Low

Outdated Solidity Compiler Version

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).

IssueThe 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).

FixConsider 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.

StatusUnresolved

Info

Hardcoded External Token Address

I-01The `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.

IssueThe `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.

FixWhile 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.

StatusUnresolved

Info

ERC20 Allowance Race Condition

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.

IssueThe 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.

FixEducate 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.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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).

GovernanceHigh1/10

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).

UpgradesHigh3/10

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).

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

74.2% in top 10

45.0% in wallets29.2% in contracts

Effective Concentration56.7%

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.

Liquidity Depth

$773.0K across 6 pairs

Uniswap v2WETHanalysed$734.1K Uniswap v4JASMY$13.9K Uniswap v4rust$10.4K Uniswap v4LINK$9.1K Uniswap v3WETH$5.5K Uniswap v4ETH$91

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder93.3%

Top-3 Unlocked94.6%

Key Addresses

11 addresses

Deployer

0xe864…6d73

Unlocked LP Held By

0x3fa6…92160xf9d0…795d0x103c…fc0f0xbfa9…c03a0x0000…8a900xcdd8…1c000x128a…ca410xbc25…43850xe242…d7690x6c4e…a326

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

9 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 50% (74.2% total → 56.7% effective; 45.0% in EOAs, 29.2% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 93.3% (independent LP — depth risk, pool = 95% of DEX liquidity)
LP top3 unlocked holders = 94.6% (independent LP — depth risk, pool = 95% of DEX liquidity)
1 High finding(s) from audit
1 Medium finding(s) from audit
1 Low finding(s) from audit

Each 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

Is Chain Safe?

Security Findings

Unrestricted Minting Function

Initial Supply Held by Contract Address

Outdated Solidity Compiler Version

Hardcoded External Token Address

ERC20 Allowance Race Condition

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Chain?