Quantum Audit Logo

Is elizaOS Safe?

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

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

elizaOS ELIZAOS
0xea17…2478
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The BurnMintERC20 contract implements a standard ERC20 token with additional minting and burning capabilities, leveraging OpenZeppelin's AccessControl for role-based permissions. The contract includes a maximum supply limit and a dedicated CCIP admin role. While the codebase demonstrates good adherence to established patterns and includes basic safety checks, a primary concern is the high degree of centralization inherent in the administrative roles, particularly the DEFAULT_ADMIN_ROLE, which controls critical functions like minting, burning, and the CCIP admin address. This centralization introduces a single point of failure and trust risk.

1 High1 Medium1 Low2 Informational
Volume 24h
$214.4K
Liquidity
$168.1K
Price
$0.0001791
Token Age
8mo
Top 10 Holders
84.7%

Security Findings

High

Centralized Control of Token Supply and Roles

H-01The `DEFAULT_ADMIN_ROLE` has absolute control over the token's supply by being able to grant and revoke `MINTER_ROLE` and `BURNER_ROLE` to any address. This centralization (7.3 Access Control, 7.5 Governance) means a single compromised private key or malicious administrator could manipulate the token supply, leading to severe economic consequences for the protocol and its users. The constructor grants this role to `msg.sender`.
IssueThe `DEFAULT_ADMIN_ROLE` has absolute control over the token's supply by being able to grant and revoke `MINTER_ROLE` and `BURNER_ROLE` to any address. This centralization (7.3 Access Control, 7.5 Governance) means a single compromised private key or malicious administrator could manipulate the token supply, leading to severe economic consequences for the protocol and its users. The constructor grants this role to `msg.sender`.
FixImplement a multi-signature wallet or a timelock contract to control the `DEFAULT_ADMIN_ROLE`. This would require multiple approvals or introduce a delay for critical administrative actions, reducing the risk of a single point of failure and providing a window for intervention.
StatusUnresolved
Medium

Critical External Admin Role (`s_ccipAdmin`) Controlled by Single Admin

M-01The `s_ccipAdmin` address, which is likely crucial for Cross-Chain Interoperability Protocol (CCIP) operations (7.6 External), can be changed by the `DEFAULT_ADMIN_ROLE` via the `setCCIPAdmin` function. A compromise of the `DEFAULT_ADMIN_ROLE` could allow an attacker to redirect or disrupt CCIP-related functionalities, potentially impacting cross-chain asset transfers or data flows.
IssueThe `s_ccipAdmin` address, which is likely crucial for Cross-Chain Interoperability Protocol (CCIP) operations (7.6 External), can be changed by the `DEFAULT_ADMIN_ROLE` via the `setCCIPAdmin` function. A compromise of the `DEFAULT_ADMIN_ROLE` could allow an attacker to redirect or disrupt CCIP-related functionalities, potentially impacting cross-chain asset transfers or data flows.
FixSimilar to other critical roles, consider placing the `setCCIPAdmin` function under the control of a multi-signature wallet or a timelock. This would add an additional layer of security for managing external protocol integrations.
StatusUnresolved
Low

Lack of Timelock or Multi-sig for Critical Operations

L-01Critical administrative functions, such as `grantRole`, `revokeRole`, and `setCCIPAdmin`, are directly executable by the `DEFAULT_ADMIN_ROLE` without any time delay or multi-signature requirement (7.5 Governance, 7.8 Operations). This allows immediate execution of sensitive changes, increasing the risk of human error or rapid exploitation if the admin key is compromised.
IssueCritical administrative functions, such as `grantRole`, `revokeRole`, and `setCCIPAdmin`, are directly executable by the `DEFAULT_ADMIN_ROLE` without any time delay or multi-signature requirement (7.5 Governance, 7.8 Operations). This allows immediate execution of sensitive changes, increasing the risk of human error or rapid exploitation if the admin key is compromised.
FixIntroduce a timelock mechanism for all critical administrative functions. This would enforce a delay between the initiation and execution of sensitive operations, providing a window for detection and potential mitigation of malicious or erroneous actions.
StatusUnresolved
Info

No Emergency Pause Mechanism

I-01The contract lacks a mechanism to pause token transfers, minting, or burning in an emergency (7.2 Code Security, 7.8 Operations). In the event of a critical vulnerability, exploit, or unforeseen market event, the inability to halt operations could lead to significant and irreversible damage.
IssueThe contract lacks a mechanism to pause token transfers, minting, or burning in an emergency (7.2 Code Security, 7.8 Operations). In the event of a critical vulnerability, exploit, or unforeseen market event, the inability to halt operations could lead to significant and irreversible damage.
FixConsider integrating OpenZeppelin's `Pausable` contract or a similar custom pausing mechanism. This would allow authorized roles (e.g., `DEFAULT_ADMIN_ROLE` or a dedicated 'PAUSER_ROLE') to temporarily suspend critical functions during emergencies.
StatusUnresolved
Info

Immutable `maxSupply` Parameter

I-02The `i_maxSupply` is set during construction and is immutable (7.4 Economic). While this provides a clear and predictable supply cap, it means the maximum supply cannot be adjusted in the future without deploying a new contract. This design choice might limit the protocol's flexibility for long-term evolution or unforeseen economic requirements.
IssueThe `i_maxSupply` is set during construction and is immutable (7.4 Economic). While this provides a clear and predictable supply cap, it means the maximum supply cannot be adjusted in the future without deploying a new contract. This design choice might limit the protocol's flexibility for long-term evolution or unforeseen economic requirements.
FixThis is a design decision. If future flexibility is desired, consider making `maxSupply` adjustable by a governance mechanism (e.g., `DEFAULT_ADMIN_ROLE` with a timelock), or acknowledge this immutability as a core feature of the token's economic policy.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract exhibits a robust architecture (7.1 Architecture) by inheriting from well-audited OpenZeppelin libraries (ERC20, AccessControl, ERC20Burnable), which significantly enhances code security (7.2 Code Security). It implements clear role-based access control (7.3 Access Control) for minting and burning functions, using `onlyRole(MINTER_ROLE)` and `onlyRole(BURNER_ROLE)`. However, the centralized nature of the `DEFAULT_ADMIN_ROLE` to manage all other roles, including `MINTER_ROLE` and `BURNER_ROLE`, presents a notable technical risk due to a single point of failure.

GovernanceHigh1/10

The contract's economic model (7.4 Economic) includes a fixed `maxSupply` and controlled minting/burning, which provides predictability. Governance (7.5 Governance) is highly centralized, with the `DEFAULT_ADMIN_ROLE` having the power to grant and revoke all other roles, including `MINTER_ROLE` and `BURNER_ROLE`, and to set the `s_ccipAdmin` address. This centralization means a compromise of the `DEFAULT_ADMIN_ROLE` could lead to complete control over token supply and critical external integrations, posing a significant economic and governance risk. There is no timelock or multi-sig for these critical operations.

UpgradesHigh3/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades) and does not implement any upgrade mechanisms. Therefore, there are no upgrade-related risks. Any changes to the contract's logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

15.2% in wallets69.6% in contracts
Effective Concentration43.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

Deployer
0xfc2f…2148
Unlocked LP Held By
0x5d92…0205

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

What Raised This Score

  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (84.7% total → 43.0% effective; 15.2% in EOAs, 69.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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 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

SOLANA (SOL)Critical RiskPancakeSwap Token (CAKE)Critical RiskSubsquid (SQD)Critical RiskBOBCritical RiskAnoma (XAN)Critical RiskPlasma (XPL)Critical Risk

Would You Like a More Detailed Audit of elizaOS?

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

Get Detailed Audit