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

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2249Jul 2334

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The XPINToken contract is a standard ERC20 token implementation, inheriting from the well-regarded Solmate library. The contract includes EIP-2612 permit functionality. The audit found the codebase to be simple, well-structured, and generally secure, with no critical or high-severity vulnerabilities identified. Minor considerations include the initial token distribution and the use of `unchecked` arithmetic blocks.

Final Recommendation: The XPINToken contract is a solid implementation of the ERC20 standard using the Solmate library. Projects should ensure robust key management practices for the deployer address, especially given its control over the initial token supply. While the `permit` function is well-implemented, users should be educated on the risks associated with signing off-chain messages. For future iterations, consider implementing a multi-signature wallet for critical administrative actions if any privileged roles are introduced.

Category Ratings

TechnicalLow

10/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 `per

GovernanceHigh

2/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)

UpgradesMedium

6/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

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (80.6% total → 37.8% effective; 9.3% in EOAs, 71.3% 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

Security Findings

3 total

2 Low 1 Info

L-01LowUnresolved

Centralized Initial Supply Distribution

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

Recommendation: Ensure 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.

L-02LowUnresolved

Reliance on `ecrecover` for `permit` Functionality

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

Recommendation: Maintain 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.

I-01InformationalUnresolved

Justified Use of `unchecked` Blocks

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

Recommendation: No 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.

Is XPIN Token Safe? XPIN