Is XEN Crypto (XEN) Safe? Smart Contract Security Analysis

Security Findings

1 Low2 Info

Low

Extensive Use of `require` for Fixed-Point Range Checks

L-01The `ABDKMath64x64` library extensively uses `require` statements within `unchecked` blocks to enforce range limits (`MIN_64x64`, `MAX_64x64`) for 64.64-bit fixed-point numbers after intermediate `int256` calculations. While these checks are crucial for preventing overflows/underflows and ensuring mathematical correctness, they can lead to higher gas costs for transactions that provide inputs resulting in out-of-range fixed-point values, as such transactions will revert. This is an expected trade-off for safety in fixed-point arithmetic.

IssueThe `ABDKMath64x64` library extensively uses `require` statements within `unchecked` blocks to enforce range limits (`MIN_64x64`, `MAX_64x64`) for 64.64-bit fixed-point numbers after intermediate `int256` calculations. While these checks are crucial for preventing overflows/underflows and ensuring mathematical correctness, they can lead to higher gas costs for transactions that provide inputs resulting in out-of-range fixed-point values, as such transactions will revert. This is an expected trade-off for safety in fixed-point arithmetic.

FixThis is a design choice for safety and is generally acceptable for fixed-point libraries. Users of the `Math` library should be aware that inputs leading to results outside the 64.64-bit range will cause transactions to revert. No direct action is required unless gas optimization for invalid inputs is a critical concern, which would typically involve a different fixed-point implementation strategy.

StatusUnresolved

Info

Reliance on Third-Party Library

I-01The `Math` contract's core functionality for fixed-point arithmetic is entirely dependent on the `ABDKMath64x64` library. While `ABDKMath64x64` is a well-known and generally robust library, any undiscovered vulnerability or subtle bug within its extensive codebase would directly impact the `Math` contract and any protocol relying on it. This introduces an inherent dependency risk.

IssueThe `Math` contract's core functionality for fixed-point arithmetic is entirely dependent on the `ABDKMath64x64` library. While `ABDKMath64x64` is a well-known and generally robust library, any undiscovered vulnerability or subtle bug within its extensive codebase would directly impact the `Math` contract and any protocol relying on it. This introduces an inherent dependency risk.

FixEnsure that the `ABDKMath64x64` library has been thoroughly audited independently and that its specific version used in this project is free from known vulnerabilities. Consider maintaining a local copy of the audited version to prevent unexpected changes from external dependencies.

StatusUnresolved

Info

Truncated `log_2` Function in `ABDKMath64x64`

I-02The provided source code for the `ABDKMath64x64.log_2` function is incomplete, indicated by `... (truncated)`. Without the full implementation, a comprehensive security assessment of this specific function's logic, including potential edge cases, gas consumption, and correctness, cannot be performed.

IssueThe provided source code for the `ABDKMath64x64.log_2` function is incomplete, indicated by `... (truncated)`. Without the full implementation, a comprehensive security assessment of this specific function's logic, including potential edge cases, gas consumption, and correctness, cannot be performed.

FixProvide the complete source code for the `ABDKMath64x64.log_2` function to allow for a full and thorough audit of its implementation. Verify that the deployed bytecode matches the complete source code.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The `Math` contract (7.1 Architecture) is a simple, stateless library providing `min`, `max`, and `logX64` functions. Its core functionality for fixed-point arithmetic is delegated to the `ABDKMath64x64` library, which is a widely used and generally robust solution for 64.64-bit fixed-point math in Solidity. The `ABDKMath64x64` library (7.2 Code Security) incorporates `unchecked` blocks with explicit `require` statements to prevent integer overflows/underflows and ensure results remain within the valid fixed-point range. No reentrancy or other common code security vulnerabilities were identified due to the contract's pure nature.

GovernanceHigh3/10

The `Math` contract is a pure utility library (7.4 Economic). It does not manage any assets, tokens, or user funds, nor does it implement any economic models or fee structures. Consequently, there are no direct economic risks such as flash loan attacks or oracle manipulation. Similarly, the contract lacks any governance mechanisms (7.5 Governance) or access control (7.3 Access Control), as all its functions are `external pure` and stateless, meaning no privileged operations exist.

UpgradesMedium6/10

The `Math` contract serves as an implementation behind a proxy (7.7 Upgrades). As a stateless and pure library, it is an ideal candidate for an upgradeable implementation, minimizing upgrade-related risks. Future upgrades to this specific implementation would primarily involve replacing the mathematical logic, which is a low-risk operation given its lack of state. The proxy's upgrade mechanism itself (7.8 Operations) would be the primary point of concern for upgrade safety, but this implementation does not introduce specific upgrade vulnerabilities.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

18.9% in top 10

13.4% in wallets5.5% in contracts

Effective Concentration15.6%

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

$89.5K across 9 pairs

Uniswap v3WETHanalysed$57.7K Uniswap v2WETH$22.8K Uniswap v4ETH$7.9K Uniswap v3USDC$968 Uniswap v4TrumpBucks$55 Uniswap v3WETH$29

Show 3 more pairsShow less

Uniswap v3DAI$25 Uniswap v2USDC$8 PancakeswapWETH$7

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 Holder73.9%

Top-3 Unlocked92.8%

Key Addresses

11 addresses

Deployer

0xa82c…591a

Unlocked LP Held By

0xd3b9…08360x945d…04af0x2ffa…354f0x758c…33940xb251…27af0xa443…df850x03e5…5db50x78e3…9e4a0x4d0b…5d5f0x3fc8…5c3c

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

What Raised This Score

5 factors

Ownership status UNKNOWN (owner could not be resolved)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 73.9% (independent LP — depth risk, pool = 64% of DEX liquidity)
LP top3 unlocked holders = 92.8% (independent LP — depth risk, pool = 64% of DEX liquidity)
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 XEN Crypto Safe?

Security Findings

Extensive Use of `require` for Fixed-Point Range Checks

Reliance on Third-Party Library

Truncated `log_2` Function in `ABDKMath64x64`

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 XEN Crypto?