Quantum Audit Logo
Launch App

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

Is SOON Token Safe?

SOONBNB Chain
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance3/10Upgrades4/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Info3
SummaryAI Copilot

The audit of the SoonTokenV2 contract, deployed as an upgradeable proxy, identified a robust architecture leveraging OpenZeppelin and LayerZero standards.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Proxy contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (92.9% total → 39.3% effective; 3.6% in EOAs, 89.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
89.3%Contracts3.6%7.1%
89.3%Contracts3.6%7.1%
ContractsWalletsEveryone elseBubble area = share of supply
92.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking89.3%
  • Walletsanonymous holders, free to sell3.6%
  • Everyone elsethe rest of the supply7.1%
Effective concentrationwhat the score reads39.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$569.5K 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$567.3KShare of depth99.6%
Top-1 Unlocked Holder99.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0xd2b0…0ff80xda71…5f9e0x7884…af810x6458…2df50x6bbc…e9310xce53…ec600xde51…a29f0x4b9e…8fd90x9f51…79790x7926…2d0a

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

Security Findings

1 High1 Medium1 Info
High

Centralized Blacklist Control

The contract includes a blacklist functionality (addToBlacklist, removeFromBlacklist) controlled by the onlyOwner modifier. The _update function, which is called during token transfers, checks if both the sender and receiver are blacklisted. This grants the owner (a multisig) the power to arbitrarily prevent any account from transferring tokens, effectively freezing their assets. While the owner is a multisig, this level of centralized control over user funds is a significant risk (7.3, 7.4).H-01

Issue

The contract includes a blacklist functionality (addToBlacklist, removeFromBlacklist) controlled by the onlyOwner modifier. The _update function, which is called during token transfers, checks if both the sender and receiver are blacklisted. This grants the owner (a multisig) the power to arbitrarily prevent any account from transferring tokens, effectively freezing their assets. While the owner is a multisig, this level of centralized control over user funds is a significant risk (7.3, 7.4).

Fix

Consider implementing a decentralized governance mechanism for managing the blacklist, or at minimum, introduce a timelock for blacklist operations to allow for community oversight and reaction time. Clearly communicate the existence and implications of this centralized control to all token holders.

Status

Unresolved

Medium

Centralized Control of Inflationary Parameters

The inflationaryMinter, inflationaryReceiver, and inflationaryRatio parameters, which dictate the token's inflationary supply mechanism, are all controlled by the onlyOwner address. If the owner's private keys or the multisig itself were compromised, an attacker could manipulate these parameters to mint an excessive amount of tokens to an arbitrary address, leading to severe token dilution and economic instability (7.3, 7.4, 7.8).M-01

Issue

The inflationaryMinter, inflationaryReceiver, and inflationaryRatio parameters, which dictate the token's inflationary supply mechanism, are all controlled by the onlyOwner address. If the owner's private keys or the multisig itself were compromised, an attacker could manipulate these parameters to mint an excessive amount of tokens to an arbitrary address, leading to severe token dilution and economic instability (7.3, 7.4, 7.8).

Fix

Implement a timelock for changes to critical inflationary parameters (inflationaryMinter, inflationaryReceiver, inflationaryRatio) to provide a delay before changes take effect. This allows for detection and potential intervention in case of malicious or erroneous updates. Consider a more decentralized approach for these roles in the future, if applicable.

Status

Unresolved

Info

Use of Non-Upgradeable ECDSA Library

The EIP3009Upgradeable contract imports ECDSA from @openzeppelin/contracts/utils/cryptography/ECDSA.sol instead of the upgradeable version, ECDSAUpgradeable. While ECDSA is a stateless library and its non-upgradeable version does not introduce direct state-related vulnerabilities in an upgradeable context, using the Upgradeable counterpart is generally considered a best practice for consistency and to avoid potential confusion in upgradeable contract development (7.2).I-01

Issue

The EIP3009Upgradeable contract imports ECDSA from @openzeppelin/contracts/utils/cryptography/ECDSA.sol instead of the upgradeable version, ECDSAUpgradeable. While ECDSA is a stateless library and its non-upgradeable version does not introduce direct state-related vulnerabilities in an upgradeable context, using the Upgradeable counterpart is generally considered a best practice for consistency and to avoid potential confusion in upgradeable contract development (7.2).

Fix

For consistency and adherence to upgradeable contract best practices, consider replacing ECDSA with ECDSAUpgradeable from @openzeppelin/contracts-upgradeable/utils/cryptography/ECDSAUpgradeable.sol.

Status

Unresolved

Analysis

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

The audit of the SoonTokenV2 contract, deployed as an upgradeable proxy, identified a robust architecture leveraging OpenZeppelin and LayerZero standards. Key features include inflationary minting and an EIP-3009 authorization mechanism. The primary risks stem from the high degree of centralized control over critical functions, particularly the blacklist and inflationary parameters, which are managed by a multisig owner. While the technical implementation is sound, these centralized powers introduce significant governance and operational risks.

Technical8/10Low risk

The contract exhibits a well-structured architecture (7.1) using established OpenZeppelin and LayerZero upgradeable patterns, including Initializable and OFTUpgradeable. Code security (7.2) is generally strong, with no apparent reentrancy or integer overflow vulnerabilities. The EIP-3009 implementation correctly uses EIP-712 signatures and nonces to prevent replay attacks. However, the _update function incorporates a blacklist modifier, which introduces a centralized point of control over token transfers (7.3).

Governance3/10High risk

The economic model (7.4) includes an inflationary minting mechanism with parameters (inflationaryRatio, inflationaryMinter, inflationaryReceiver) controlled by the owner. While the inflation rate appears reasonable (3-5% annually relative to initial supply), the centralized control over these parameters and the ability to blacklist accounts (7.3) represent significant governance risks (7.5). The owner, a multisig, has the power to freeze funds or alter the token supply dynamics without direct community governance.

Upgrades4/10Medium risk

The contract is designed for upgradeability (7.7) using the Transparent Upgradeable Proxy pattern and OpenZeppelin's Initializable base. The initialize() and initializeV2() functions correctly manage initialization and reinitialization, ensuring proper setup across upgrades. The use of _disableInitializers() in the constructor and reinitializer(2) for initializeV2() demonstrates adherence to upgrade safety best practices.

Final RecommendationWhat to do about this score

Strengthen access control mechanisms by considering a timelock for critical owner-controlled functions, especially those related to the blacklist and inflationary parameters, to provide a delay for review and reaction.

Implement robust monitoring for the owner multisig and associated addresses to detect any suspicious activity. Ensure clear communication to token holders regarding the implications of the centralized blacklist and inflationary model.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBNB Chain
Token age1y
Contract0xb9e1…a721
Deployer0x1d4c…70a2
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
Badge for your website
SOON Token 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. Aug 20, 202642Medium

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

Related Audits

6 more on the recordAll audits
ZestBNB Chain42MediumMetaSoilVerseProtocolMSVP · BNB Chain42MediumBitcatBNB Chain42MediumBinanciansBNB Chain42MediumBaby Doge CoinBABYDOGE · BNB Chain41MediumMindNetwork FHE TokenFHE · BNB Chain41Medium

Would You Like a More Detailed Audit of SOON Token?

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