Quantum Audit Logo

Is SAIRI Safe?

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

SAIRI SAIRI
0xde61…eb07
Base Not verifiedLast checked 3d 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, leveraging OpenZeppelin's battle-tested libraries. It includes custom functionality for cross-chain minting/burning, restricted to a Superchain Token Bridge, and administrative control over metadata and the admin role itself. While the core ERC20 implementation is robust, the centralized control held by the `_admin` role for critical parameters and the admin transfer mechanism introduces a medium-level risk. The token's initial supply distribution and the nature of its `maxSupply_` parameter also warrant clear understanding.

1 Medium1 Low2 Informational
Volume 24h
$4.3K
Liquidity
$103.6K
Price
$0.000001668
Token Age
4mo
Top 10 Holders
58.4%

Security Findings

1 Med1 Low2 Info
Medium

Centralized Control of Admin Role and Metadata

M-01The `_admin` role has the sole authority to transfer the admin role (`updateAdmin`) and modify token metadata (`updateImage`, `updateMetadata`). A compromise of the `_admin` key could lead to unauthorized changes to the token's administrative control and public-facing information. This centralizes significant power in a single address, increasing the impact of a private key compromise. (7.3 Access Control, 7.8 Operations)
IssueThe `_admin` role has the sole authority to transfer the admin role (`updateAdmin`) and modify token metadata (`updateImage`, `updateMetadata`). A compromise of the `_admin` key could lead to unauthorized changes to the token's administrative control and public-facing information. This centralizes significant power in a single address, increasing the impact of a private key compromise. (7.3 Access Control, 7.8 Operations)
FixConsider implementing a multi-signature wallet for the `_admin` role or introducing a time-lock for critical administrative actions like `updateAdmin` to provide a window for community review or emergency intervention. This would distribute control and enhance security.
StatusUnresolved
Low

Initial Supply Distribution to Deployer

L-01The constructor mints the entire `maxSupply_` to `msg.sender` (the deployer) if `block.chainid` matches `initialSupplyChainId_`. This design centralizes the initial token supply entirely with the deployer, which might not align with desired distribution strategies for a public token. While not a direct vulnerability, it's a significant design choice for token distribution. (7.4 Economic)
IssueThe constructor mints the entire `maxSupply_` to `msg.sender` (the deployer) if `block.chainid` matches `initialSupplyChainId_`. This design centralizes the initial token supply entirely with the deployer, which might not align with desired distribution strategies for a public token. While not a direct vulnerability, it's a significant design choice for token distribution. (7.4 Economic)
FixEnsure that this distribution model is intentional and clearly communicated to stakeholders. For future deployments, consider alternative initial distribution mechanisms, such as vesting contracts or a controlled release, if a broader initial distribution is desired.
StatusUnresolved
Info

`maxSupply_` is not a Global Hard Cap

I-01The `maxSupply_` parameter in the constructor only dictates the initial supply minted on a specific chain. The `crosschainMint` function, callable by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`, allows for additional tokens to be minted, meaning the total supply across all chains can exceed the initial `maxSupply_`. This is a standard pattern for cross-chain tokens but should be explicitly understood by users and stakeholders. (7.4 Economic, 7.1 Architecture)
IssueThe `maxSupply_` parameter in the constructor only dictates the initial supply minted on a specific chain. The `crosschainMint` function, callable by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`, allows for additional tokens to be minted, meaning the total supply across all chains can exceed the initial `maxSupply_`. This is a standard pattern for cross-chain tokens but should be explicitly understood by users and stakeholders. (7.4 Economic, 7.1 Architecture)
FixClearly document that `maxSupply_` refers to the initial supply on a specific chain and that the total supply can increase through legitimate cross-chain bridging operations. This helps manage expectations regarding tokenomics and supply dynamics.
StatusUnresolved
Info

Unused `_context` Variable

I-02The `_context` state variable is set in the constructor and exposed via the `context()` and `allData()` view functions, but there is no function to update its value after deployment. This makes it a static piece of metadata. If it's intended to be dynamic, its current implementation limits flexibility. (7.2 Code Security)
IssueThe `_context` state variable is set in the constructor and exposed via the `context()` and `allData()` view functions, but there is no function to update its value after deployment. This makes it a static piece of metadata. If it's intended to be dynamic, its current implementation limits flexibility. (7.2 Code Security)
FixIf `_context` is intended to be dynamic, add an `updateContext` function with appropriate access control. If it's meant to be static, ensure this is clearly documented. If it serves no purpose, consider removing it to reduce contract size and complexity.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) of ClankerToken is sound, building upon well-audited OpenZeppelin ERC20 standards, including ERC20Burnable, ERC20Permit, and ERC20Votes. Code security (7.2) is enhanced by the use of these robust libraries, minimizing common vulnerabilities like reentrancy and integer overflows. Access control (7.3) for cross-chain minting and burning is appropriately restricted to the `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. However, the `_admin` role has significant control over token metadata and the ability to transfer the admin role, presenting a centralized point of failure.

GovernanceLow7/10

Economically (7.4), the token's initial supply is minted entirely to the deployer on a specific chain, which is a design choice that centralizes initial distribution. The `maxSupply_` parameter is not a global hard cap, as `crosschainMint` allows for additional supply by the `SUPERCHAIN_TOKEN_BRIDGE`, which is typical for cross-chain tokens but requires clear communication. Governance (7.5) is not directly implemented in this contract, though the inclusion of `ERC20Votes` suggests future integration. The `_admin` role's ability to update metadata and transfer admin control represents a centralized operational risk (7.8).

UpgradesLow9/10

The ClankerToken contract is not designed as an upgradeable proxy (7.7). This means that its logic cannot be modified post-deployment. While this eliminates upgrade-related risks, any future feature enhancements or bug fixes would necessitate a new contract deployment and a migration of token holders, which can be a complex and costly process.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

58.4% in top 10
9.8% in wallets48.5% in contracts
Effective Concentration29.3%

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

$103.6K across 2 pairs
Uniswap v4WETHanalysed$103.6K100.0%Uniswap v4ETH$120.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x2112…f3f9
Unlocked LP Held By
0x63d2…34960x2db2…7f57

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

What Raised This Score

6 factors
  • Top-10 concentration > 20% (58.4% total → 29.3% effective; 9.8% in EOAs, 48.5% in contracts — mild)
  • 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)
  • 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
Coinbase Wrapped Hyperliquid (CBHYPE)Low RiskplumberLow RiskFAILow RiskKeeta (KTA)Low RiskApple Inc. (AAPLC)Low RiskvAPI Network (VAPI)Low Risk

Would You Like a More Detailed Audit of SAIRI?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit