Quantum Audit Logo
Launch App

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

Is elizaOS Safe?

ELIZAOSBNB Chain
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The BurnMintERC20 contract implements a standard ERC20 token with additional minting and burning capabilities, leveraging OpenZeppelin's AccessControl for role-based permissions.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
69.6%Contracts15.2%Wallets15.3%Everyone else
69.6%Contracts15.2%Wallets15.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
84.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking69.6%
  • Walletsanonymous holders, free to sell15.2%
  • Everyone elsethe rest of the supply15.3%
Effective concentrationwhat the score reads43.0%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$168.1K

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$168.1KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x5d92…0205

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

Security Findings

1 High1 Medium1 Low2 Info
High

Centralized Control of Token Supply and Roles

The 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.H-01

Issue

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

Fix

Implement 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.

Status

Unresolved

Medium

Critical External Admin Role (s_ccipAdmin) Controlled by Single Admin

The 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.M-01

Issue

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

Fix

Similar 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.

Status

Unresolved

Low

Lack of Timelock or Multi-sig for Critical Operations

Critical 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.L-01

Issue

Critical 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.

Fix

Introduce 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.

Status

Unresolved

Info

No Emergency Pause Mechanism

The 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.I-01

Issue

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

Fix

Consider 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.

Status

Unresolved

Info

Immutable maxSupply Parameter

The 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.I-02

Issue

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

Fix

This 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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.

Governance1/10High risk

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.

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

To enhance the security posture, consider implementing a multi-signature wallet or a timelock for the DEFAULT_ADMIN_ROLE to manage critical functions such as granting/revoking roles and setting the s_ccipAdmin.

This would introduce a delay or require multiple approvals for sensitive operations, significantly mitigating the risk of a single point of failure. Additionally, evaluate the necessity of an emergency pause mechanism to provide a safety net during unforeseen events or exploits.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age8mo
Contract0xea17…2478
Deployer0xfc2f…2148
Badge for your website
elizaOS security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202673High
  2. Aug 11, 202661Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the ELIZAOS contract address?

The elizaOS contract on BNB Chain is 0xea17df5cf6d172224892b5477a16acb111182478. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is elizaOS a scam?

Quantum Audit's risk score for elizaOS is 73/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ELIZAOS liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $168.1K.

Who holds ELIZAOS?

As of Sep 4, 2026, the 10 largest holders own 84.7% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Zcash TokenZEC · BNB Chain73HighSOLANASOL · BNB Chain74HighPancakeSwap TokenCAKE · BNB Chain72HighSubsquidSQD · BNB Chain72HighBOBBNB Chain72HighNIGHTBNB Chain72High

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 Is this your token? Publish your own audit on this page