Quantum Audit Logo

Is OutBurn a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

OutBurn OUTBURN
0xa5a6…fb07
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 16h old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The ClankerToken contract is an ERC20 token implementation leveraging well-audited OpenZeppelin libraries. It includes standard features like burning, permit, and voting, along with custom administrative functions for metadata management and admin role updates. The primary risks identified relate to the centralized control vested in the `_admin` role and the lack of clarity regarding the `_verified` state's impact on contract functionality.

1 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (16h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$1.9K
Liquidity
$71.1K
Price
$0.0000007104
Token Age
16h
Top 10 Holders
95.2%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control of Admin Role

H-01The `_admin` role has significant power, including the ability to transfer itself via `updateAdmin` and modify token-related metadata (`updateImage`, `updateMetadata`). This creates a single point of failure; if the `_admin` key is compromised or transferred to an untrusted address, it could lead to a complete loss of control over these critical functions, potentially allowing malicious updates to token information or an irreversible transfer of administrative power.
IssueThe `_admin` role has significant power, including the ability to transfer itself via `updateAdmin` and modify token-related metadata (`updateImage`, `updateMetadata`). This creates a single point of failure; if the `_admin` key is compromised or transferred to an untrusted address, it could lead to a complete loss of control over these critical functions, potentially allowing malicious updates to token information or an irreversible transfer of administrative power.
FixConsider implementing a multi-signature wallet for the `_admin` role to require multiple approvals for critical actions. For the `updateAdmin` function specifically, implement a time-lock mechanism (e.g., a timelock controller) to introduce a delay before the new admin address becomes active, allowing for community oversight or emergency intervention.
StatusUnresolved
Medium

Lack of Clarity on `_verified` State Impact

M-01The `verify()` function, callable only once by the `_originalAdmin`, sets the `_verified` boolean flag to `true`. However, the contract logic does not use this `_verified` state to gate or modify any other critical functionality (e.g., transfers, burning, admin actions). Its purpose is unclear from the code, potentially leading to confusion among users or developers regarding its intended role and impact on the token's behavior.
IssueThe `verify()` function, callable only once by the `_originalAdmin`, sets the `_verified` boolean flag to `true`. However, the contract logic does not use this `_verified` state to gate or modify any other critical functionality (e.g., transfers, burning, admin actions). Its purpose is unclear from the code, potentially leading to confusion among users or developers regarding its intended role and impact on the token's behavior.
FixClearly document the intended purpose of the `_verified` state. If it is meant to enable or disable specific features, implement the corresponding conditional logic within the contract. If it is purely an informational flag, explicitly state this in documentation to manage expectations.
StatusUnresolved
Low

Mutable Metadata and Image URLs

L-01The `_admin` role has the ability to update the `_image`, `_metadata`, and `_context` strings via `updateImage` and `updateMetadata` functions. While this provides flexibility for branding and informational updates, it also means that the public-facing information associated with the token can be changed at any time by the `_admin`. This could potentially be used to mislead users if malicious or inaccurate data is set.
IssueThe `_admin` role has the ability to update the `_image`, `_metadata`, and `_context` strings via `updateImage` and `updateMetadata` functions. While this provides flexibility for branding and informational updates, it also means that the public-facing information associated with the token can be changed at any time by the `_admin`. This could potentially be used to mislead users if malicious or inaccurate data is set.
FixEnsure clear communication to token holders and the community that these fields are mutable. For projects aiming for higher decentralization, consider integrating these updates into a governance mechanism or adding a time-lock to provide transparency and community review before changes take effect.
StatusUnresolved
Info

Robust Immutable Admin and Initial Minting Logic

I-01The `_originalAdmin` address is declared as `immutable`, ensuring that the address with the one-time `verify()` capability cannot be changed after deployment. Additionally, the initial token minting in the constructor is conditionally executed based on `block.chainid == initialSupplyChainId_`. These design choices enhance security by preventing critical parameters from being altered and ensuring that the initial supply is minted only on the intended blockchain, reducing deployment-related risks.
IssueThe `_originalAdmin` address is declared as `immutable`, ensuring that the address with the one-time `verify()` capability cannot be changed after deployment. Additionally, the initial token minting in the constructor is conditionally executed based on `block.chainid == initialSupplyChainId_`. These design choices enhance security by preventing critical parameters from being altered and ensuring that the initial supply is minted only on the intended blockchain, reducing deployment-related risks.
FixNo recommendation; this is a positive security feature.
StatusResolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good technical practices by inheriting from battle-tested OpenZeppelin ERC20 extensions (ERC20Burnable, ERC20Permit, ERC20Votes), which significantly reduces the risk of common token vulnerabilities (7.2 Code Security). The `_update` and `nonces` overrides correctly delegate to super functions, maintaining expected behavior. However, the `_admin` role holds significant power, including the ability to transfer itself, which introduces a single point of failure if compromised (7.3 Access Control). The `supportsInterface` implementation is correct for the declared interfaces.

GovernanceHigh3/10

The token's economic model is a standard fixed-supply ERC20, with initial minting occurring only on a specific chain ID, which is a robust design choice (7.4 Economic). The `_originalAdmin` is immutable and responsible for a one-time `verify()` function, which is a secure pattern for initial setup. However, the `_admin` role has centralized control over critical functions like `updateAdmin`, `updateImage`, and `updateMetadata`, posing a governance risk if the admin key is compromised or misused (7.5 Governance). The purpose of the `_verified` state is not explicitly tied to any functional restrictions, which could lead to misunderstandings.

UpgradesLow8/10

The ClankerToken contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates the complexities and potential risks associated with proxy upgrade patterns, such as storage collisions or incorrect initialization. While this means the contract's logic cannot be altered post-deployment, it simplifies the security model by removing upgrade-related attack vectors. There are no upgrade safety issues to consider.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

95.2% in top 10
5.7% in wallets89.5% in contracts
Effective Concentration41.5%

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

$71.1K

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
0x5536…19eb
Unlocked LP Held By
0x00c4…1974

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

What Raised This Score

8 factors
  • Top-10 concentration > 30% (95.2% total → 41.5% effective; 5.7% in EOAs, 89.5% 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)
  • Token age < 24h (brand new — bot activity, unproven)
  • 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

6 more on the record
Artificial Superintelligence Alliance (FET)Medium RiskOndoMedium RiskRequest Token (REQ)Medium RiskIdentity.md (IMD)Medium RiskHighstreet token (HIGH)Medium RiskChainlink (LINK)Medium Risk

Would You Like a More Detailed Audit of OutBurn?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit