Quantum Audit Logo

Is Bario Entertainment System Safe?

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

Bario Entertainment System BAES
0xa9f6…db07
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive 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. 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.

1 High1 Medium1 Low2 Informational
Volume 24h
$141.3K
Liquidity
$80.7K
Price
$0.000006117
Token Age
9mo
Top 10 Holders
30.9%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Admin Control with Self-Transfer Capability

H-01The `_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.
IssueThe `_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.
FixImplement 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.
StatusUnresolved
Medium

Immutable Original Admin for One-Time Verification

M-01The `_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.
IssueThe `_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.
FixEnsure 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.
StatusUnresolved
Low

Reliance on External Superchain Token Bridge Security

L-01The `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.
IssueThe `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.
FixAcknowledge 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.
StatusUnresolved
Info

Conditional Initial Supply Minting in Constructor

I-01The 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.
IssueThe 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.
FixExercise 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.
StatusUnresolved
Info

Non-Upgradeable Contract Design

I-02The `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.
IssueThe `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.
FixUnderstand 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.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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.

GovernanceMedium6/10

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.

UpgradesLow9/10

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.

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

30.9% in top 10
7.7% in wallets23.2% in contracts
Effective Concentration17.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

$86.6K across 5 pairs
Uniswap v4WETHanalysed$80.7K93.3%Uniswap v4WETH$4.8K5.5%Uniswap v4ETH$7040.8%Hydrex CLAMMWETH$3730.4%Uniswap v3WETH$00.0%

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 Holder98.1%
Top-3 Unlocked100.0%

Key Addresses

8 addresses
Deployer
0x702b…875e
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.

What Raised This Score

6 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

Related Audits

6 more on the record
EdelLow RiskOpenVPP (OVPP)Low RiskKeeta (KTA)Low RiskApple Inc. (AAPLC)Low RiskBase Juice (BASEJUICE)Low RiskvAPI Network (VAPI)Low Risk

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