Quantum Audit Logo

Is STABLE Safe?

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

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

STABLE STABLE
0x011e…075f
BNB Chain Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → High Risk
Executive 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. 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.

2 Medium1 Low1 Informational
Volume 24h
$1.32M
Liquidity
$900.9K
Price
$0.02872
Token Age
7mo
Top 10 Holders
94.5%

Security Findings

2 Med1 Low1 Info
Medium

Centralized Control by Owner

M-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Medium

Dependency on LayerZero Protocol Security

M-02The `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.
IssueThe `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.
FixContinuously 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.
StatusUnresolved
Low

Potential for Initialization Front-Running (Mitigated)

L-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Info

Minimal Custom Logic Reduces Attack Surface

I-01The `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.
IssueThe `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.
FixN/A (This is a strength of the current implementation and contributes positively to its security posture).
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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.

UpgradesMedium4/10

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.

Security Checklist

2/5 checks passed
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

94.5% in top 10
89.8% in wallets4.6% in contracts
Effective Concentration91.7%

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

$914.1K across 4 pairs
Pancakeswap v3USDTanalysed$900.9K98.6%UniswapUSDT$12.5K1.4%UniswapUSDT$7140.1%Pancakeswap v3USDT$360.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 Holder99.4%
Top-3 Unlocked100.0%

Key Addresses

8 addresses
Deployer
0xf2ee…b9c5
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.

What Raised This Score

8 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

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 record
OLYHigh RiskUnibase (UB)High RiskCapHigh RiskVELOHigh RiskBicatHigh Riskb-moneyHigh Risk

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