Quantum Audit Logo
Launch App

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

Is OutBurn a Scam?

OUTBURNEthereum
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 recordNew Launch · 16h old
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance3/10Upgrades8/10Checks passed6 of 7Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The ClankerToken contract is an ERC20 token implementation leveraging well-audited OpenZeppelin libraries.

Read the full analysis
What raised the score
  • 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%
  • Token age < 24h
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

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.

Security Checklist

as of audit · Sep 46 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
89.5%Contracts5.7%4.8%
89.5%Contracts5.7%4.8%
ContractsWalletsEveryone elseBubble area = share of supply
95.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking89.5%
  • Walletsanonymous holders, free to sell5.7%
  • Everyone elsethe rest of the supply4.8%
Effective concentrationwhat the score reads41.5%
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$71.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$71.1KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x00c4…1974

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control of Admin Role

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

Issue

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

Fix

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

Status

Unresolved

Medium

Lack of Clarity on _verified State Impact

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

Issue

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

Fix

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

Status

Unresolved

Low

Mutable Metadata and Image URLs

The _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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Robust Immutable Admin and Initial Minting Logic

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

Issue

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

Fix

No recommendation; this is a positive security feature.

Status

Resolved

Analysis

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

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.

Technical8/10Low risk

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.

Governance3/10High risk

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.

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

It is recommended to implement robust security measures for the _admin private key, such as a multi-signature wallet, to mitigate the risks associated with centralized control.

For critical administrative actions like updateAdmin, consider adding a time-lock mechanism to provide a window for community review or intervention. Additionally, clarify and document the intended purpose and impact of the _verified state to ensure transparency and prevent future misinterpretations of its role within the contract's functionality.

Contract & Record

1 audit on record
TypeClankerToken
NetworkEthereum
Token age16h
Contract0xa5a6…fb07
Deployer0x5536…19eb
Badge for your website
OutBurn 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 2, 202640Medium

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

Related Audits

6 more on the recordAll audits
Artificial Superintelligence AllianceFET · Ethereum40MediumOndoEthereum40MediumRequest TokenREQ · Ethereum40MediumIdentity.mdIMD · Ethereum40MediumHighstreet tokenHIGH · Ethereum40MediumWrapped GonkaWGNK · Ethereum40Medium

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