Quantum Audit Logo
Launch App

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

Is Bario Entertainment System Safe?

BAESBase
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance6/10Upgrades9/10Checks passed6 of 7Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The ClankerToken contract is an ERC20 token with extensions for burning, permits, and voting, incorporating custom administrative roles and cross-chain mint/burn functionalities.

Read the full analysis
What raised the score
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.1%
  • 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
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.1% (independent LP — depth risk, pool = 93% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 93% of DEX liquidity)
  • 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 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
23.2%Contracts7.7%Wallets69.1%Everyone else
23.2%Contracts7.7%69.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
30.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking23.2%
  • Walletsanonymous holders, free to sell7.7%
  • Everyone elsethe rest of the supply69.1%
Effective concentrationwhat the score reads17.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$86.6K across 5 pairs

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$80.7KShare of depth93.3%
Top-1 Unlocked Holder98.1%
Top-3 Unlocked100.0%
Unlocked LP held by
0x63d2…34960x5b97…35820x7aae…5cc30x8984…202f0x16cd…7c750xb3f8…1a140x2c4e…1f80

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 Admin Control with Self-Transfer Capability

The _admin role in the ClankerToken contract possesses extensive control over critical token parameters, including the ability to update the token's image and metadata. Crucially, the updateAdmin function allows the current _admin to transfer its administrative privileges to any arbitrary address without any delay or additional checks. This creates a significant single point of failure; if the _admin key is compromised, an attacker could not only manipulate the token's public representation but also permanently seize control of the admin role, potentially leading to further malicious actions.H-01

Issue

The _admin role in the ClankerToken contract possesses extensive control over critical token parameters, including the ability to update the token's image and metadata. Crucially, the updateAdmin function allows the current _admin to transfer its administrative privileges to any arbitrary address without any delay or additional checks. This creates a significant single point of failure; if the _admin key is compromised, an attacker could not only manipulate the token's public representation but also permanently seize control of the admin role, potentially leading to further malicious actions.

Fix

Implement a multi-signature wallet for the _admin role to require multiple approvals for sensitive operations, including updateAdmin, updateImage, and updateMetadata. Additionally, consider introducing a time-lock mechanism for the updateAdmin function, allowing a grace period before the new admin address becomes active. This provides a window for detection and potential intervention in case of a compromised key.

Status

Unresolved

Medium

Immutable Original Admin for One-Time Verification

The _originalAdmin address is set as immutable during construction and is the sole entity capable of calling the verify() function, which can only be executed once. While this role has limited direct control over ongoing operations, its immutability means that if the key associated with _originalAdmin is lost or compromised *before* verify() is called, the verification functionality could become permanently inaccessible or be maliciously triggered. This represents a single point of failure for a specific, albeit one-time, contract state change.M-01

Issue

The _originalAdmin address is set as immutable during construction and is the sole entity capable of calling the verify() function, which can only be executed once. While this role has limited direct control over ongoing operations, its immutability means that if the key associated with _originalAdmin is lost or compromised *before* verify() is called, the verification functionality could become permanently inaccessible or be maliciously triggered. This represents a single point of failure for a specific, albeit one-time, contract state change.

Fix

Ensure the _originalAdmin key is managed with the highest level of security, potentially using a hardware security module or a multi-signature wallet if the verify function is deemed critical. Re-evaluate if the verify function's purpose could be achieved through a more decentralized or recoverable mechanism, or if its impact warrants such a strict, immutable single-point-of-failure design.

Status

Unresolved

Low

Reliance on External Superchain Token Bridge Security

The crosschainMint and crosschainBurn functions are exclusively callable by Predeploys.SUPERCHAIN_TOKEN_BRIDGE. This design is standard for tokens intended to operate across different chains within the Superchain ecosystem, ensuring controlled supply management. However, the security and integrity of the ClankerToken's total supply and cross-chain liquidity are entirely dependent on the security and correct functioning of the SUPERCHAIN_TOKEN_BRIDGE. Any vulnerability or exploit within the bridge contract could directly impact the ClankerToken's economic stability and supply.L-01

Issue

The crosschainMint and crosschainBurn functions are exclusively callable by Predeploys.SUPERCHAIN_TOKEN_BRIDGE. This design is standard for tokens intended to operate across different chains within the Superchain ecosystem, ensuring controlled supply management. However, the security and integrity of the ClankerToken's total supply and cross-chain liquidity are entirely dependent on the security and correct functioning of the SUPERCHAIN_TOKEN_BRIDGE. Any vulnerability or exploit within the bridge contract could directly impact the ClankerToken's economic stability and supply.

Fix

Acknowledge and continuously monitor the security posture and operational status of the SUPERCHAIN_TOKEN_BRIDGE. While this is an inherent dependency for cross-chain functionality, understanding and mitigating risks associated with external protocols is crucial for overall project security. Consider subscribing to security alerts for the bridge infrastructure.

Status

Unresolved

Info

Conditional Initial Supply Minting in Constructor

The constructor includes a conditional statement that mints the maxSupply_ to msg.sender only if block.chainid == initialSupplyChainId_. While this logic is likely intended to control initial supply distribution across specific chain deployments, a misconfiguration of the initialSupplyChainId_ parameter during deployment could lead to the token having zero initial supply on the intended chain, or inadvertently minting the entire supply on an incorrect or unintended chain. This is a deployment-specific risk rather than a contract logic flaw.I-01

Issue

The constructor includes a conditional statement that mints the maxSupply_ to msg.sender only if block.chainid == initialSupplyChainId_. While this logic is likely intended to control initial supply distribution across specific chain deployments, a misconfiguration of the initialSupplyChainId_ parameter during deployment could lead to the token having zero initial supply on the intended chain, or inadvertently minting the entire supply on an incorrect or unintended chain. This is a deployment-specific risk rather than a contract logic flaw.

Fix

Exercise extreme caution and thorough verification during the deployment process to ensure that the initialSupplyChainId_ parameter is precisely set to the target chain ID where the initial token supply is intended to be minted. Implement robust deployment scripts and checklists to prevent such misconfigurations.

Status

Unresolved

Info

Non-Upgradeable Contract Design

The ClankerToken contract is deployed as a standard implementation and does not incorporate any proxy pattern (e.g., UUPS, Transparent). This means the contract's logic is immutable once deployed and cannot be upgraded. While this simplifies the contract's security model by removing upgrade-related complexities, it also eliminates the possibility of future bug fixes, feature enhancements, or adjustments to the token's logic without a complete redeployment and a potentially disruptive migration of user assets.I-02

Issue

The ClankerToken contract is deployed as a standard implementation and does not incorporate any proxy pattern (e.g., UUPS, Transparent). This means the contract's logic is immutable once deployed and cannot be upgraded. While this simplifies the contract's security model by removing upgrade-related complexities, it also eliminates the possibility of future bug fixes, feature enhancements, or adjustments to the token's logic without a complete redeployment and a potentially disruptive migration of user assets.

Fix

Understand and accept the implications of a non-upgradeable contract. If future flexibility for bug fixes or feature additions is a critical requirement, consider implementing an upgradeable proxy pattern for any future token deployments. For the current deployment, ensure the contract is thoroughly audited and tested, as any discovered issues will necessitate a redeployment.

Status

Unresolved

Analysis

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

The ClankerToken contract is an ERC20 token with extensions for burning, permits, and voting, incorporating custom administrative roles and cross-chain mint/burn functionalities. The contract leverages well-audited OpenZeppelin libraries and Solidity 0.8+ features, contributing to a solid technical foundation. However, significant centralization around the _admin role, which controls critical token metadata and can transfer its own privileges, introduces a notable governance and economic risk. The contract is not upgradeable, which simplifies its security model but limits future flexibility.

Technical9/10Low risk

The technical architecture (7.1) of ClankerToken is straightforward, implementing standard ERC20 functionalities with additional features like ERC20Permit, ERC20Votes, and ERC20Burnable. Code security (7.2) is robust, benefiting from the use of battle-tested OpenZeppelin contracts and Solidity 0.8+, which mitigates common issues like integer overflows. No reentrancy or other critical technical vulnerabilities were identified. The contract includes clear custom error messages for access control failures.

Governance6/10Medium risk

The contract exhibits high centralization (7.5) around the _admin role, which has the power to update critical token metadata (updateImage, updateMetadata) and, more significantly, to transfer the _admin role itself (updateAdmin). This single point of failure poses a substantial economic risk (7.4) if the _admin key is compromised. The _originalAdmin also holds a one-time verify() function, which, while limited, is another centralized control point. Cross-chain operations (crosschainMint, crosschainBurn) rely entirely on the security of Predeploys.SUPERCHAIN_TOKEN_BRIDGE (7.6 External), which is an inherent dependency for L2 tokens.

Upgrades9/10Low risk

The ClankerToken contract is deployed as a standard implementation and does not utilize a proxy pattern (7.7 Architecture). Consequently, it is not upgradeable. This design choice eliminates upgrade-specific risks such as proxy misconfigurations or logic errors in upgrade mechanisms. However, it also means that any future bug fixes, feature enhancements, or changes to the token's logic would necessitate a complete redeployment and a potentially complex asset migration process.

Final RecommendationWhat to do about this score

To enhance the security posture of the ClankerToken, it is strongly recommended to implement a multi-signature wallet for the _admin role to mitigate the single point of failure risk.

For highly sensitive operations, consider adding a time-lock mechanism to provide a window for community review or emergency intervention. Ensure robust operational security practices (7.8 Operations) for all privileged keys, especially the _admin and _originalAdmin addresses, to prevent unauthorized access or loss.

Contract & Record

1 audit on record
TypeClankerToken
NetworkBase
Token age9mo
Contract0xa9f6…db07
Deployer0x702b…875e
Badge for your website
Bario Entertainment System 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, 202616Low
  2. Aug 30, 202615Low

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

Frequently Asked Questions

What is the BAES contract address?

The Bario Entertainment System (BAES) contract on Base is 0xa9f6d9eca1f803854a13cecad0f21d43e007db07. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Bario Entertainment System a scam?

Quantum Audit's risk score for Bario Entertainment System is 16/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is BAES liquidity locked?

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

Who holds BAES?

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

Related Audits

6 more on the recordAll audits
EdelBase16LowOpenVPPOVPP · Base15LowKeetaKTA · Base17LowApple Inc.AAPLC · Base17LowBase JuiceBASEJUICE · Base15LowvAPI NetworkVAPI · Base17Low

Would You Like a More Detailed Audit of Bario Entertainment System?

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