Quantum Audit Logo

Is boar a Scam?

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

boar BOAR
0x0cbf…bb07
Base
Not verifiedThis 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.
Last checked today 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The ClankerToken contract implements an ERC20 token with burnable, permit, and voting functionalities, leveraging OpenZeppelin standards. It includes custom roles for an `_admin` and an `_originalAdmin`, and integrates cross-chain minting/burning via a predefined bridge. While the core ERC20 implementation is robust, the contract exhibits significant centralization risks due to the `_admin` role's extensive control and a critical external dependency on the `SUPERCHAIN_TOKEN_BRIDGE` for supply management. These factors contribute to a High overall risk level.

2 High1 Medium1 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$1.98M
Liquidity
$347.5K
Price
$0.00001342
Token Age
2d
Top 10 Holders
30.8%

Security Findings

2 High1 Med1 Info
High

Centralized Control by `_admin` Role

H-01The `_admin` role has exclusive control over critical functions such as `updateAdmin`, `updateImage`, and `updateMetadata`. This allows the `_admin` to transfer the administrative role to any address and modify token-related metadata. A compromise of the `_admin` key could lead to unauthorized changes to the token's perceived identity and potential loss of control. (7.3 Access Control, 7.5 Governance)
IssueThe `_admin` role has exclusive control over critical functions such as `updateAdmin`, `updateImage`, and `updateMetadata`. This allows the `_admin` to transfer the administrative role to any address and modify token-related metadata. A compromise of the `_admin` key could lead to unauthorized changes to the token's perceived identity and potential loss of control. (7.3 Access Control, 7.5 Governance)
FixConsider implementing a multi-signature wallet for the `_admin` role or a time-locked mechanism for sensitive administrative changes to reduce the risk of a single point of failure. This would require multiple approvals or a delay period before critical changes can be enacted.
StatusUnresolved
High

Critical External Dependency on `SUPERCHAIN_TOKEN_BRIDGE`

H-02The `crosschainMint` and `crosschainBurn` functions, which directly affect the token's total supply, are exclusively callable by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. This introduces a critical external dependency. Any vulnerability or compromise within the `SUPERCHAIN_TOKEN_BRIDGE` contract could lead to unauthorized minting, burning, or manipulation of the token's supply, severely impacting its economic integrity. (7.4 Economic, 7.6 External)
IssueThe `crosschainMint` and `crosschainBurn` functions, which directly affect the token's total supply, are exclusively callable by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. This introduces a critical external dependency. Any vulnerability or compromise within the `SUPERCHAIN_TOKEN_BRIDGE` contract could lead to unauthorized minting, burning, or manipulation of the token's supply, severely impacting its economic integrity. (7.4 Economic, 7.6 External)
FixEnsure the `SUPERCHAIN_TOKEN_BRIDGE` contract is thoroughly audited, robust, and secured with strong access controls and operational safeguards. Implement continuous monitoring for unusual activity originating from the bridge address to detect and respond to potential compromises promptly.
StatusUnresolved
Medium

Limited Utility of `_originalAdmin` Role

M-01The `_originalAdmin` role is immutable and only has the permission to call the `verify()` function once. After this single invocation, the `_originalAdmin` address retains no further special privileges within the contract. If the `verify()` function is never called, the token remains in an unverified state, potentially impacting its perceived legitimacy or integration with other systems. (7.3 Access Control, 7.8 Operations)
IssueThe `_originalAdmin` role is immutable and only has the permission to call the `verify()` function once. After this single invocation, the `_originalAdmin` address retains no further special privileges within the contract. If the `verify()` function is never called, the token remains in an unverified state, potentially impacting its perceived legitimacy or integration with other systems. (7.3 Access Control, 7.8 Operations)
FixDocument the intended lifecycle and importance of the `verify()` function, clarifying its purpose and the implications if it remains uncalled. Consider if the `_originalAdmin` role could be removed after `verify()` is called, or if its single-use nature is intentional and well-understood within the protocol's design.
StatusUnresolved
Info

Misleading `maxSupply_` Parameter in Constructor

I-01The constructor takes a `maxSupply_` parameter, which is minted to `msg.sender` if `block.chainid == initialSupplyChainId_`. However, the `crosschainMint` function, controlled by `SUPERCHAIN_TOKEN_BRIDGE`, allows for arbitrary minting of new tokens. This means the `maxSupply_` parameter does not represent a hard cap on the total token supply, as the actual supply is ultimately governed by the logic of the external bridge contract. This could be misleading for users expecting a fixed maximum supply. (7.4 Economic)
IssueThe constructor takes a `maxSupply_` parameter, which is minted to `msg.sender` if `block.chainid == initialSupplyChainId_`. However, the `crosschainMint` function, controlled by `SUPERCHAIN_TOKEN_BRIDGE`, allows for arbitrary minting of new tokens. This means the `maxSupply_` parameter does not represent a hard cap on the total token supply, as the actual supply is ultimately governed by the logic of the external bridge contract. This could be misleading for users expecting a fixed maximum supply. (7.4 Economic)
FixClarify in documentation that `maxSupply_` refers to the initial supply on the designated chain and that the overall token supply is dynamically managed by the cross-chain bridge. Consider renaming the parameter to `initialChainSupply` or similar for better clarity to avoid confusion.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract is built upon well-audited OpenZeppelin ERC20 standards, including extensions for `ERC20Permit`, `ERC20Votes`, and `ERC20Burnable`, which enhances code security (7.2 Code Security). It correctly overrides the `_update` function for voting capabilities and implements `supportsInterface` for various ERC standards. However, the reliance on a single `_admin` address for critical functions like `updateAdmin` and metadata changes introduces a significant access control risk (7.3 Access Control). Additionally, the hardcoded dependency on `Predeploys.SUPERCHAIN_TOKEN_BRIDGE` for cross-chain minting/burning represents a critical external dependency (7.6 External) that could impact the token's integrity if the bridge is compromised.

GovernanceMedium4/10

The contract's economic model (7.4 Economic) is heavily influenced by its cross-chain capabilities, with `crosschainMint` and `crosschainBurn` functions allowing the `SUPERCHAIN_TOKEN_BRIDGE` to control the token's total supply. This makes the token's economic stability directly dependent on the security and integrity of the bridge. Governance (7.5 Governance) is highly centralized, with a single `_admin` address possessing the power to update the admin role itself and modify token metadata (`_image`, `_metadata`). This concentration of power poses a substantial risk, as a compromise of this single key could lead to unauthorized control over the token's identity and administrative functions. The `_originalAdmin` role has limited, one-time utility for the `verify()` function, which, if not called, leaves the token unverified.

UpgradesLow9/10

The ClankerToken contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates the complexities and potential vulnerabilities associated with proxy patterns and upgrade mechanisms. Consequently, there are no direct upgrade safety issues within this contract. Any future changes to the token's logic would require a new deployment and migration, which is a known and accepted limitation for non-upgradeable contracts.

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.8% in top 10
1.1% in wallets29.8% in contracts
Effective Concentration13.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

$391.7K across 24 pairs
Uniswap v4WETHanalysed$347.5K88.7%Uniswap v4USDC$16.0K4.1%Uniswap v4USDC$4.9K1.2%Uniswap v4USDC$3.9K1.0%Uniswap v4USDC$3.1K0.8%Uniswap v4USDC$3.0K0.8%
Show 4 more pairsShow less
Uniswap v4USDC$3.0K0.8%Uniswap v4USDC$2.8K0.7%Uniswap v4ETH$2.1K0.5%Uniswap v4USDC$1.1K0.3%

The 14 remaining pairs hold $4.3K between them and are not listed.

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
0xd9ac…6e58
Unlocked LP Held By
0x9fe9…c63b

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 = 100.0% (independent LP — depth risk, pool = 89% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 89% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 2 High finding(s) from audit
  • 1 Medium 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
PORTALMedium RiskBaselineMedium RiskCoinbase Man (BRIAN)Medium RisktobyMedium RiskMeta Platforms Inc. (METAC)Medium RiskOlivia AI 2.0 ($OLIVIA2.0)Medium Risk

Would You Like a More Detailed Audit of boar?

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

Get Detailed Audit