Quantum Audit Logo
Launch App

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

Is SAIRI Safe?

Base
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
SummaryAI Copilot

The ClankerToken contract is an ERC20 token with extensions for burning, permits, and voting, leveraging OpenZeppelin's battle-tested libraries.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 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%
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
48.5%Contracts9.8%Wallets41.6%Everyone else
48.5%Contracts9.8%41.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
58.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking48.5%
  • Walletsanonymous holders, free to sell9.8%
  • Everyone elsethe rest of the supply41.6%
Effective concentrationwhat the score reads29.3%
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$103.6K across 2 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$103.6KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
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.

Security Findings

1 Medium1 Low2 Info
Medium

Centralized Control of Admin Role and Metadata

The _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)M-01

Issue

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

Fix

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

Status

Unresolved

Low

Initial Supply Distribution to Deployer

The 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)L-01

Issue

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

Fix

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

Status

Unresolved

Info

maxSupply_ is not a Global Hard Cap

The 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)I-01

Issue

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

Fix

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

Status

Unresolved

Info

Unused _context Variable

The _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)I-02

Issue

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

Fix

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

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

Technical10/10Low risk

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.

Governance7/10Low risk

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

Upgrades9/10Low risk

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.

Final RecommendationWhat to do about this score

To enhance the security posture, consider implementing a multi-signature wallet for the _admin role to manage critical functions like updateAdmin and metadata changes.

This would distribute control and reduce the risk associated with a single point of failure. Additionally, ensure comprehensive documentation clearly outlines the token's economic model, particularly regarding the initial supply distribution and the dynamic nature of the total supply due to cross-chain operations.

Contract & Record

1 audit on record
TypeClankerToken
NetworkBase
Token age4mo
Contract0xde61…eb07
Deployer0x2112…f3f9
Badge for your website
SAIRI 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. Jul 23, 202618Low

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

Frequently Asked Questions

What is the SAIRI contract address?

The SAIRI contract on Base is 0xde61878b0b21ce395266c44d4d548d1c72a3eb07. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is SAIRI a scam?

Quantum Audit's risk score for SAIRI is 18/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. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is SAIRI liquidity locked?

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

Who holds SAIRI?

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

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