Is Limitless Official Token (LMTS) Safe? Smart Contract Security Analysis

Security Findings

1 Low2 Info

Low

Potential Constructor Gas Limit Exceedance for Large Initial Distributions

L-01The `LMTS` contract's constructor iterates through `wallets` and `amounts` arrays to perform initial token minting. If the number of initial recipients (i.e., `wallets.length`) is excessively large, the constructor's execution could consume more gas than the block gas limit, preventing the contract from being deployed successfully. While this is a deployment-time concern, it could lead to deployment failures if not carefully managed.

IssueThe `LMTS` contract's constructor iterates through `wallets` and `amounts` arrays to perform initial token minting. If the number of initial recipients (i.e., `wallets.length`) is excessively large, the constructor's execution could consume more gas than the block gas limit, preventing the contract from being deployed successfully. While this is a deployment-time concern, it could lead to deployment failures if not carefully managed.

FixFor very large initial distributions, consider alternative deployment strategies such as a phased distribution after deployment, or using a separate distribution contract that can handle a large number of recipients over multiple transactions. Ensure thorough testing of deployment with realistic array sizes on the target network.

StatusUnresolved

Info

Contract is Not Upgradeable

I-01The `LMTS` contract is implemented as a standard, non-proxy contract. This means its logic is immutable once deployed to the blockchain. Any future requirements for bug fixes, feature enhancements, or protocol adjustments would necessitate deploying an entirely new contract and migrating all token holders, which can be a complex and disruptive process.

IssueThe `LMTS` contract is implemented as a standard, non-proxy contract. This means its logic is immutable once deployed to the blockchain. Any future requirements for bug fixes, feature enhancements, or protocol adjustments would necessitate deploying an entirely new contract and migrating all token holders, which can be a complex and disruptive process.

FixProjects should carefully consider their long-term needs. If future modifications are anticipated, implementing an upgradeable proxy pattern (e.g., UUPS or Transparent Proxy) from the outset is recommended. If immutability is a core design principle, ensure all current logic is thoroughly audited and tested.

StatusUnresolved

Info

Absence of Administrative Control Mechanisms

I-02The `LMTS` token contract is designed without any administrative roles or functions (e.g., `pause`, `blacklist`, `mint`, `burn` by an owner/admin). While this design choice promotes decentralization and reduces central points of failure, it also means there is no mechanism to respond to unforeseen emergencies such as critical vulnerabilities, exploits, or regulatory requirements that might necessitate freezing transfers, blacklisting malicious addresses, or adjusting token supply.

IssueThe `LMTS` token contract is designed without any administrative roles or functions (e.g., `pause`, `blacklist`, `mint`, `burn` by an owner/admin). While this design choice promotes decentralization and reduces central points of failure, it also means there is no mechanism to respond to unforeseen emergencies such as critical vulnerabilities, exploits, or regulatory requirements that might necessitate freezing transfers, blacklisting malicious addresses, or adjusting token supply.

FixEvaluate the project's philosophy regarding decentralization versus operational flexibility. If the intent is full decentralization, this is acceptable. If some level of emergency response capability is desired, consider adding carefully designed and permissioned administrative functions, potentially governed by a multi-signature wallet or a DAO.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The LMTS contract (7.1 Architecture) is a straightforward ERC20 token with the ERC20Permit extension, leveraging OpenZeppelin's robust and audited libraries (7.2 Code Security). This foundation significantly reduces the likelihood of common vulnerabilities like reentrancy or integer overflows. The contract's constructor handles initial token distribution, which could face gas limit issues if the number of recipients is excessively large, requiring careful deployment planning. Access control (7.3 Access Control) is minimal, adhering to standard ERC20 permissions without additional administrative roles.

GovernanceHigh2/10

The token's economic model (7.4 Economic) is simple, featuring a fixed total supply minted entirely at deployment, with no further minting or burning mechanisms. This design promotes scarcity and predictability. There are no governance mechanisms (7.5 Governance) or administrative roles, making the token highly decentralized post-deployment. While this minimizes centralization risks, it also means there are no emergency controls to address unforeseen issues, which is a deliberate design choice for immutability and decentralization.

UpgradesMedium6/10

The LMTS contract (7.7 Upgrades) is deployed as a standard implementation contract and is not designed to be upgradeable. This means its logic is immutable once deployed. Any future modifications or bug fixes would necessitate deploying a new contract and migrating all token holders, which can be a complex and disruptive process. This design choice prioritizes immutability over flexibility.

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

93.8% in top 10

5.2% in wallets88.6% in contracts

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

$554.3K across 7 pairs

AerodromeUSDCanalysed$383.2K AerodromeUSDC$170.3K Uniswap v4ETH$736 Uniswap v3WETH$56 Uniswap v4ETH$18 Uniswap v4USDC$3

Show 1 more pairShow less

Uniswap v4USDC$1

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

0xb995…f3b2

Unlocked LP Held By

0xa7c2…0e7d

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% (93.8% total → 40.6% effective; 5.2% in EOAs, 88.6% 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, pool = 69% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 69% 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

Not Signed In

Is Limitless Official Token Safe?

Security Findings

Potential Constructor Gas Limit Exceedance for Large Initial Distributions

Contract is Not Upgradeable

Absence of Administrative Control Mechanisms

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 Limitless Official Token?