Quantum Audit Logo

Is Aleo Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Aleo ALEO
0x6cff…4dd2
BNB Chain
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked today 1 audit on record
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The WrappedTokens contract implements an upgradeable ERC-20 token with burnable, pausable, and permit functionalities, leveraging OpenZeppelin's battle-tested libraries. The contract utilizes AccessControl for managing DEFAULT_ADMIN_ROLE, PAUSER_ROLE, and MINTER_ROLE. While the architecture is sound and follows best practices for upgradeable tokens, significant centralization risks exist due to the powers granted to the MINTER_ROLE and PAUSER_ROLE, which can impact token supply and transferability. The DEFAULT_ADMIN_ROLE also represents a single point of failure for overall role management.

2 High1 Medium1 Low1 Informational
Volume 24h
$556.5K
Liquidity
$194.7K
Price
$0.02768
Token Age
1y
Top 10 Holders
70.0%

Security Findings

High

Centralized Minting Authority

H-01The `MINTER_ROLE` possesses the unrestricted ability to mint new tokens. This centralization introduces a significant economic risk (7.4), as a compromised or malicious minter could inflate the token supply, devaluing existing holdings and impacting the token's stability. This is an access control flaw (7.3) with direct economic consequences.
IssueThe `MINTER_ROLE` possesses the unrestricted ability to mint new tokens. This centralization introduces a significant economic risk (7.4), as a compromised or malicious minter could inflate the token supply, devaluing existing holdings and impacting the token's stability. This is an access control flaw (7.3) with direct economic consequences.
FixImplement multi-signature control for the `MINTER_ROLE` to require multiple approvals for minting operations. Consider introducing a minting cap or a rate limit to control inflation. If possible, explore mechanisms to decentralize or remove the minting capability entirely once the desired supply is reached.
StatusUnresolved
High

Centralized Pausing Authority

H-02The `PAUSER_ROLE` can unilaterally pause and unpause all token transfers. While useful for emergency situations, this power can disrupt liquidity, prevent users from moving funds, and potentially be abused if the role is compromised (7.3). This poses a significant operational and economic risk (7.4, 7.8).
IssueThe `PAUSER_ROLE` can unilaterally pause and unpause all token transfers. While useful for emergency situations, this power can disrupt liquidity, prevent users from moving funds, and potentially be abused if the role is compromised (7.3). This poses a significant operational and economic risk (7.4, 7.8).
FixImplement multi-signature control for the `PAUSER_ROLE`. Consider adding a time-lock for unpausing functionality to allow for community review or emergency response. Clearly define the conditions under which pausing is permissible in project documentation.
StatusUnresolved
Medium

Critical Role Management by Default Admin

M-01The `DEFAULT_ADMIN_ROLE` has the power to grant and revoke all other roles, including `MINTER_ROLE` and `PAUSER_ROLE`. This makes the `DEFAULT_ADMIN_ROLE` a single point of failure (7.3, 7.8); its compromise would grant an attacker full control over the token's critical functions, including minting and pausing.
IssueThe `DEFAULT_ADMIN_ROLE` has the power to grant and revoke all other roles, including `MINTER_ROLE` and `PAUSER_ROLE`. This makes the `DEFAULT_ADMIN_ROLE` a single point of failure (7.3, 7.8); its compromise would grant an attacker full control over the token's critical functions, including minting and pausing.
FixImplement multi-signature control for the `DEFAULT_ADMIN_ROLE` to ensure that no single entity can unilaterally manage critical roles. Consider transferring the `DEFAULT_ADMIN_ROLE` to a robust governance mechanism or a DAO if applicable.
StatusUnresolved
Low

Dependency on OpenZeppelin Libraries

L-01The contract extensively uses OpenZeppelin's upgradeable contracts. While these libraries are widely audited and considered secure, any future vulnerabilities discovered within them could indirectly impact the `WrappedTokens` contract (7.2, 7.6). This is a general risk inherent in using external dependencies.
IssueThe contract extensively uses OpenZeppelin's upgradeable contracts. While these libraries are widely audited and considered secure, any future vulnerabilities discovered within them could indirectly impact the `WrappedTokens` contract (7.2, 7.6). This is a general risk inherent in using external dependencies.
FixStay informed about security updates and advisories from OpenZeppelin. Regularly review the project's dependencies and consider upgrading to newer versions if security patches are released. This is a continuous operational security practice.
StatusUnresolved
Info

Hardcoded Decimals

I-01The `decimals()` function is explicitly set to return `6`. This is a design decision and not a vulnerability (7.1), but it's a critical parameter for all integrations (e.g., exchanges, wallets, dApps) and should be clearly communicated to users and developers to prevent misinterpretation of token values.
IssueThe `decimals()` function is explicitly set to return `6`. This is a design decision and not a vulnerability (7.1), but it's a critical parameter for all integrations (e.g., exchanges, wallets, dApps) and should be clearly communicated to users and developers to prevent misinterpretation of token values.
FixEnsure that the fixed decimal value of 6 is prominently documented in all relevant project materials, including whitepapers, developer guides, and API specifications, to avoid integration errors.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract is built upon well-audited OpenZeppelin upgradeable libraries, ensuring a solid foundation for code security (7.2) and architectural patterns (7.1). Standard ERC-20, burnable, pausable, and permit functionalities are correctly integrated. However, the reliance on centralized roles for critical operations like minting and pausing introduces technical access control risks (7.3), as a compromise of these roles could lead to severe technical and economic consequences.

GovernanceHigh1/10

The economic model (7.4) of the WrappedTokens contract presents a high degree of centralization. The MINTER_ROLE has unlimited minting capability, posing a significant inflation risk if compromised. Similarly, the PAUSER_ROLE can halt all token transfers, impacting liquidity and user access. The DEFAULT_ADMIN_ROLE, which manages all other roles, represents a single point of failure for governance (7.5) and operational control (7.8), making robust key management and multi-signature controls crucial.

UpgradesHigh1/10

The contract correctly implements the UUPS proxy pattern (7.7) using OpenZeppelin's `Initializable` and upgradeable base contracts. The `_disableInitializers()` in the constructor and the `initializer` modifier on the `initialize` function are correctly used, preventing re-initialization of the implementation contract. No custom storage variables are introduced, minimizing the risk of storage collisions in future upgrades. This adherence to best practices ensures a secure and robust upgrade mechanism.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source

Holder Composition

11.7% in wallets58.3% in contracts
Effective Concentration35.0%

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

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 Holder99.9%
Top-3 Unlocked100.0%

Key Addresses

Deployer
0x4c35…3042
Unlocked LP Held By
0x08c8…66290xbdae…28d50x909d…89cc0x39c2…b181

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (70.0% total → 35.0% effective; 11.7% in EOAs, 58.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • 2 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

Related Audits

Based Token (BASED)Critical RiskGRVTCritical RiskFalcon Finance (FF)Critical RiskKGENCritical RiskBinance Brokers (BBROKERS)Critical RiskBitcoin Cash Token (BCH)Critical Risk

Would You Like a More Detailed Audit of Aleo?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit