Quantum Audit Logo

Is SOON Token Safe?

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

Is this your token? Publish your own audit on this page →

SOON Token SOON
0xb9e1…a721
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Informational
Volume 24h
$346.7K
Liquidity
$567.3K
Price
$0.1908
Token Age
1y
Top 10 Holders
92.9%

Security Findings

High

Centralized Blacklist Control

H-01The 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).
IssueThe 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).
FixConsider 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.
StatusUnresolved
Medium

Centralized Control of Inflationary Parameters

M-01The `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).
IssueThe `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).
FixImplement 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.
StatusUnresolved
Info

Use of Non-Upgradeable ECDSA Library

I-01The `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).
IssueThe `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).
FixFor consistency and adherence to upgradeable contract best practices, consider replacing `ECDSA` with `ECDSAUpgradeable` from `@openzeppelin/contracts-upgradeable/utils/cryptography/ECDSAUpgradeable.sol`.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceHigh3/10

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.

UpgradesMedium4/10

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.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source

Holder Composition

3.6% in wallets89.3% in contracts
Effective Concentration39.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

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 Holder99.9%
Top-3 Unlocked100.0%

Key Addresses

Deployer
0x1d4c…70a2
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.

What Raised This Score

  • 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

Related Audits

ZestMedium RiskMetaSoilVerseProtocol (MSVP)Medium RiskBaby Doge Coin (BABYDOGE)Medium RiskMindNetwork FHE Token (FHE)Medium RiskGUAMedium RiskOrochi Network Token (ON)Medium Risk

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