Is XPIN Token (XPIN) Safe? Smart Contract Security Analysis

Security Findings

2 Low1 Info

Low

Centralized Initial Supply Distribution

L-01The `XPINToken` constructor mints the entire `initialSupply` to `msg.sender`. This design choice centralizes the initial distribution of tokens, giving the deployer significant control over the token's early supply and potential market impact. While common for new tokens, it's a point of centralization.

IssueThe `XPINToken` constructor mints the entire `initialSupply` to `msg.sender`. This design choice centralizes the initial distribution of tokens, giving the deployer significant control over the token's early supply and potential market impact. While common for new tokens, it's a point of centralization.

FixEnsure that the deployer's private keys are secured with best practices (e.g., hardware wallet, multi-signature setup). Consider a transparent and decentralized distribution strategy for the initial supply if the project aims for broader community ownership.

StatusUnresolved

Low

Reliance on `ecrecover` for `permit` Functionality

L-02The `permit` function relies on the `ecrecover` precompile for signature verification. While Solmate's implementation correctly uses EIP-712 domain separators and nonces to mitigate common issues like replay attacks and signature malleability, `ecrecover` itself is a complex cryptographic primitive. Incorrect usage or subtle flaws in the signing process could lead to vulnerabilities.

IssueThe `permit` function relies on the `ecrecover` precompile for signature verification. While Solmate's implementation correctly uses EIP-712 domain separators and nonces to mitigate common issues like replay attacks and signature malleability, `ecrecover` itself is a complex cryptographic primitive. Incorrect usage or subtle flaws in the signing process could lead to vulnerabilities.

FixMaintain vigilance regarding best practices for off-chain signature generation and verification. Educate users about the implications of signing `permit` messages and the importance of verifying the message content and deadline. Ensure any off-chain services interacting with `permit` are robustly implemented.

StatusUnresolved

Info

Justified Use of `unchecked` Blocks

I-01The `ERC20` contract utilizes `unchecked` blocks for arithmetic operations within `transfer`, `transferFrom`, `_mint`, and `_burn` functions. Specifically, `balanceOf[to] += amount` and `totalSupply -= amount` are placed in `unchecked` blocks. The accompanying comments justify this by stating that ERC20 invariants (e.g., sum of balances cannot exceed `totalSupply`, user balance cannot exceed `totalSupply`) prevent overflows/underflows. This design choice optimizes gas costs by skipping Solidity's default overflow/underflow checks.

IssueThe `ERC20` contract utilizes `unchecked` blocks for arithmetic operations within `transfer`, `transferFrom`, `_mint`, and `_burn` functions. Specifically, `balanceOf[to] += amount` and `totalSupply -= amount` are placed in `unchecked` blocks. The accompanying comments justify this by stating that ERC20 invariants (e.g., sum of balances cannot exceed `totalSupply`, user balance cannot exceed `totalSupply`) prevent overflows/underflows. This design choice optimizes gas costs by skipping Solidity's default overflow/underflow checks.

FixNo direct action is required as the usage is justified by the contract's invariants and is a common pattern in gas-optimized libraries like Solmate. However, it is crucial for any future modifications or inherited contracts to strictly maintain these invariants to prevent potential arithmetic vulnerabilities.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is robust, leveraging Solmate's battle-tested ERC20 implementation, which is known for its gas efficiency and security. Code security (7.2) is high, with careful use of `unchecked` blocks justified by ERC20 invariants, and correct implementation of EIP-2612 `permit` functionality. Access control (7.3) is standard for an ERC20, with no additional privileged roles beyond the initial deployer for minting. External dependencies (7.6) are minimal, primarily `ecrecover` for signature verification, which is a standard precompile. Operational aspects (7.8) are straightforward, involving basic token transfers and approvals.

GovernanceHigh2/10

The economic model (7.4) is that of a simple ERC20 token, with no complex internal economic mechanisms like staking, lending, or rebase. The initial supply is minted entirely to the deployer, granting them full control over the initial distribution. There are no explicit governance mechanisms (7.5) implemented within the contract, meaning control over the token's future evolution (e.g., upgrades, parameter changes) is not decentralized.

UpgradesMedium6/10

The contract is not designed as an upgradeable proxy (7.7). It is a standard, non-upgradeable implementation, which eliminates risks associated with upgrade mechanisms such as proxy initialization, storage collisions, or faulty upgrade logic. Any future changes would require deploying a new contract and migrating liquidity.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

81.6% in top 10

10.1% in wallets71.4% in contracts

Effective Concentration38.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

$719.4K across 4 pairs

Pancakeswap v3USDTanalysed$719.1K UniswapUSDT$243 Pancakeswap v2WBNB$2 Pancakeswap v2USDT$0

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0x008a…5ff7

Unlocked LP Held By

0xad7d…72d1

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

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (81.6% total → 38.7% effective; 10.1% in EOAs, 71.4% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
2 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

Not Signed In

Is XPIN Token Safe?

Security Findings

Centralized Initial Supply Distribution

Reliance on `ecrecover` for `permit` Functionality

Justified Use of `unchecked` Blocks

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 XPIN Token?