Quantum Audit Logo
Launch App

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

Is STABLE Safe?

BNB 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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades4/10Checks passed2 of 5Findings2 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The audit focused on the StableOFTUpgradeable contract, which serves as an Omnichain Fungible Token (OFT) implementation utilizing LayerZero's upgradeable framework and OpenZeppelin's Ownable pattern.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.4%
  • LP top3 unlocked holders = 100.0%
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (94.5% total → 91.7% effective; 89.8% in EOAs, 4.6% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.4% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 2 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
4.6%89.8%Wallets5.5%
4.6%89.8%Wallets5.5%
ContractsWalletsEveryone elseBubble area = share of supply
94.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking4.6%
  • Walletsanonymous holders, free to sell89.8%
  • Everyone elsethe rest of the supply5.5%
Effective concentrationwhat the score reads91.7%
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$914.1K across 4 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$900.9KShare of depth98.6%
Top-1 Unlocked Holder99.4%
Top-3 Unlocked100.0%
Unlocked LP held by
0x5abf…286c0x7243…f8fe0xdba0…00b70xb2f2…1f420x3ffb…0f230x6458…2df50x23e8…5267

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

Security Findings

2 Medium1 Low1 Info
Medium

Centralized Control by Owner

The owner of the StableOFTUpgradeable contract, set during initialization, holds significant administrative privileges inherited from OFTUpgradeable and OwnableUpgradeable. These privileges include pausing token transfers, setting trusted remote LayerZero endpoints, and transferring ownership. While the prefill data indicates the owner is a 3-of-5 multisig, which mitigates single-point-of-failure risk, the concentration of power remains.M-01

Issue

The owner of the StableOFTUpgradeable contract, set during initialization, holds significant administrative privileges inherited from OFTUpgradeable and OwnableUpgradeable. These privileges include pausing token transfers, setting trusted remote LayerZero endpoints, and transferring ownership. While the prefill data indicates the owner is a 3-of-5 multisig, which mitigates single-point-of-failure risk, the concentration of power remains.

Fix

Ensure robust operational security for the multisig, including secure key management, strict internal procedures for transaction approval, and regular review of multisig signers. Implement a clear emergency response plan for potential misuse of these privileges.

Status

Unresolved

Medium

Dependency on LayerZero Protocol Security

The StableOFTUpgradeable contract is built upon the LayerZero protocol, specifically OFTUpgradeable and ILayerZeroEndpointV2. The security and functionality of this token are directly dependent on the integrity, correctness, and ongoing security of the underlying LayerZero infrastructure and smart contracts. Any vulnerability or misconfiguration within the LayerZero protocol could directly impact the cross-chain functionality and security of this token.M-02

Issue

The StableOFTUpgradeable contract is built upon the LayerZero protocol, specifically OFTUpgradeable and ILayerZeroEndpointV2. The security and functionality of this token are directly dependent on the integrity, correctness, and ongoing security of the underlying LayerZero infrastructure and smart contracts. Any vulnerability or misconfiguration within the LayerZero protocol could directly impact the cross-chain functionality and security of this token.

Fix

Continuously monitor LayerZero's official security announcements, audits, and updates. Ensure that the LayerZero endpoint address configured for this contract is the official and correct one for the target network. Consider implementing circuit breakers or emergency pause mechanisms if LayerZero experiences critical issues.

Status

Unresolved

Low

Potential for Initialization Front-Running (Mitigated)

The initialize function, which sets the token's name, symbol, and crucially, the contract owner (_delegate), is protected by the initializer modifier. Additionally, the constructor calls _disableInitializers(). While these mechanisms prevent re-initialization, a theoretical front-running attack during the brief window between contract deployment and the first initialize call could allow an attacker to become the owner if the deployment process is not atomic or carefully managed. However, in practice, with standard proxy deployment scripts, the initialize call is typically executed immediately by the deployer, making this scenario highly improbable.L-01

Issue

The initialize function, which sets the token's name, symbol, and crucially, the contract owner (_delegate), is protected by the initializer modifier. Additionally, the constructor calls _disableInitializers(). While these mechanisms prevent re-initialization, a theoretical front-running attack during the brief window between contract deployment and the first initialize call could allow an attacker to become the owner if the deployment process is not atomic or carefully managed. However, in practice, with standard proxy deployment scripts, the initialize call is typically executed immediately by the deployer, making this scenario highly improbable.

Fix

Ensure that the initialize function is called immediately and atomically with the proxy deployment, or by a trusted, whitelisted address, to prevent any window for front-running. This is a standard practice for proxy deployments.

Status

Unresolved

Info

Minimal Custom Logic Reduces Attack Surface

The StableOFTUpgradeable contract introduces very minimal custom logic, primarily serving as a thin wrapper around the well-audited OFTUpgradeable and OwnableUpgradeable contracts from LayerZero and OpenZeppelin, respectively. It does not add new state variables or complex business logic beyond initialization. This design choice significantly reduces the potential attack surface for vulnerabilities specific to this contract's implementation.I-01

Issue

The StableOFTUpgradeable contract introduces very minimal custom logic, primarily serving as a thin wrapper around the well-audited OFTUpgradeable and OwnableUpgradeable contracts from LayerZero and OpenZeppelin, respectively. It does not add new state variables or complex business logic beyond initialization. This design choice significantly reduces the potential attack surface for vulnerabilities specific to this contract's implementation.

Fix

N/A (This is a strength of the current implementation and contributes positively to its security posture).

Status

Unresolved

Analysis

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

The audit focused on the StableOFTUpgradeable contract, which serves as an Omnichain Fungible Token (OFT) implementation utilizing LayerZero's upgradeable framework and OpenZeppelin's Ownable pattern. The contract is deployed behind an OptimizedTransparentUpgradeableProxy. The implementation itself is minimal, primarily inheriting functionality from well-audited libraries. Key findings include centralized control by the owner (mitigated by multisig), inherent dependency on LayerZero protocol security, and a theoretical, but mitigated, initialization front-running risk. Overall, the contract exhibits a robust architecture leveraging established patterns and libraries.

Technical8/10Low risk

The technical architecture (7.1) is sound, leveraging LayerZero's OFTUpgradeable and OpenZeppelin's OwnableUpgradeable, which are well-audited components. Code security (7.2) is enhanced by the minimal custom logic, reducing the attack surface. Access control (7.3) is centralized with the contract owner holding significant administrative privileges, such as pausing and setting trusted remotes, though this is mitigated by the owner being a multisig. No reentrancy or integer overflow/underflow vulnerabilities were identified in the custom logic. A theoretical initialization front-running risk (L-01) is present but largely mitigated by standard deployment practices.

Governance1/10High risk

The economic model (7.4) is based on the LayerZero OFT standard, implying cross-chain fungibility. Governance (7.5) is centralized around the contract owner, who can control critical token parameters and LayerZero configurations. This centralization is a medium risk (M-01), though it's mitigated by the owner being a 3-of-5 multisig, as indicated by prefill data. The protocol's reliance on the LayerZero network introduces external risk (7.6) related to the security and operational integrity of the bridging solution (M-02). Operational aspects (7.8) are largely managed by the multisig, requiring robust operational security procedures.

Upgrades4/10Medium risk

The contract utilizes the Transparent Proxy pattern (7.7), a well-understood and secure upgrade mechanism. The StableOFTUpgradeable contract correctly employs _disableInitializers() in its constructor and an initialize function with the initializer modifier, preventing re-initialization issues. The proxy's admin is controlled by a 3-of-5 multisig, providing a strong security posture for upgrades. The implementation adds no new state variables, minimizing storage collision risks during future upgrades.

Final RecommendationWhat to do about this score

It is recommended to maintain robust operational security for the multisig controlling both the proxy administration and the contract owner.

This includes secure key management, strict internal procedures for transaction approval, and regular review of multisig signers. Additionally, continuous monitoring of LayerZero's official security announcements and updates is crucial, given the inherent dependency on the underlying bridging protocol. Ensure that the initialize function is called immediately and atomically with the proxy deployment to prevent any theoretical front-running windows.

Contract & Record

2 audits on record
TypeOptimizedTransparentUpgradeableProxy
NetworkBNB Chain
Token age7mo
Contract0x011e…075f
Deployer0xf2ee…b9c5
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
Badge for your website
STABLE 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. Sep 4, 202656Medium
  2. Jul 27, 202654Medium
  3. Jul 24, 202664Medium

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

Frequently Asked Questions

Is STABLE a scam?

Based on automated analysis, STABLE scores 64/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is STABLE safe to buy?

Our scanner flagged a risk score of 64/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has STABLE been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
OLYBNB Chain56MediumUnibaseUB · BNB Chain57MediumCapBNB Chain57MediumVELOBNB Chain57MediumBicatBNB Chain55Mediumb-moneyBNB Chain55Medium

Would You Like a More Detailed Audit of STABLE?

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