Quantum Audit Logo
Launch App

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

Is STBL_Token - STBL Governance Token Safe?

STBLBNB 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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Medium · 1 Low3
SummaryAI Copilot

The STBL_Token contract is an upgradeable ERC-20 token utilizing OpenZeppelin's battle-tested libraries for access control, pausing, and UUPS upgradeability.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 50%
  • 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 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (79.5% total → 65.4% effective; 56.0% in EOAs, 23.5% in contracts — heavy)
  • 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, pool = 98% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • 1 High finding(s) from audit
  • 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
23.5%Contracts56.0%Wallets20.5%Everyone else
23.5%Contracts56.0%Wallets20.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
79.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking23.5%
  • Walletsanonymous holders, free to sell56.0%
  • Everyone elsethe rest of the supply20.5%
Effective concentrationwhat the score reads65.4%
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$1.78M across 9 pairs
Show 3 more 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$1.74MShare of depth97.8%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xad6d…62710xde51…a29f0x5eea…26530x5b2d…38b9

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

Security Findings

1 High1 Medium1 Low
High

Centralized Control Over Critical Functions

The DEFAULT_ADMIN_ROLE in the STBL_Token contract possesses extensive control over critical functions. This role can grant/revoke all other roles (MINTER_ROLE, BRIDGE_ROLE, PAUSE_ROLE, UPGRADER_ROLE), initiate contract upgrades, and update the trusted forwarder. The MINTER_ROLE and BRIDGE_ROLE can mint and burn tokens up to the MAX_CAP. This high degree of centralization introduces a single point of failure; if the address holding the DEFAULT_ADMIN_ROLE is compromised, an attacker could gain full control over the token's supply, upgrade its logic to malicious code, or pause all operations.H-01

Issue

The DEFAULT_ADMIN_ROLE in the STBL_Token contract possesses extensive control over critical functions. This role can grant/revoke all other roles (MINTER_ROLE, BRIDGE_ROLE, PAUSE_ROLE, UPGRADER_ROLE), initiate contract upgrades, and update the trusted forwarder. The MINTER_ROLE and BRIDGE_ROLE can mint and burn tokens up to the MAX_CAP. This high degree of centralization introduces a single point of failure; if the address holding the DEFAULT_ADMIN_ROLE is compromised, an attacker could gain full control over the token's supply, upgrade its logic to malicious code, or pause all operations.

Fix

Implement a robust multi-signature wallet (e.g., Gnosis Safe) to control the DEFAULT_ADMIN_ROLE and other critical roles. For highly sensitive operations like upgrades or role management, consider adding a time-lock mechanism to allow for community review or emergency response before execution. Clearly document the operational procedures and security measures for managing these privileged roles.

Status

Unresolved

Medium

Redundant Role Grant in Initialization

The initialize() function calls _grantRole(DEFAULT_ADMIN_ROLE, _msgSender()); twice. While this redundancy does not introduce a functional vulnerability or error, it indicates a minor oversight in the code and could potentially lead to confusion or slight gas inefficiency if the _grantRole function had side effects beyond state modification.M-01

Issue

The initialize() function calls _grantRole(DEFAULT_ADMIN_ROLE, _msgSender()); twice. While this redundancy does not introduce a functional vulnerability or error, it indicates a minor oversight in the code and could potentially lead to confusion or slight gas inefficiency if the _grantRole function had side effects beyond state modification.

Fix

Remove the duplicate call to _grantRole(DEFAULT_ADMIN_ROLE, _msgSender()); from the initialize() function. Ensure that each role grant is performed only once to maintain code clarity and efficiency.

Status

Unresolved

Low

Unnecessary SafeERC20 Usage for Self-Transfer

In the burn and bridgeBurn functions, IERC20(address(this)).safeTransferFrom(_from, address(this), _amt); is used. While SafeERC20 is generally good practice for interacting with external ERC-20 tokens, using safeTransferFrom to transfer tokens to address(this) (the token contract itself) is not strictly necessary for security. The contract is interacting with its own token balance, and a direct _transfer or _approve followed by _transferFrom would suffice without the SafeERC20 wrapper, as the contract's own _transfer logic is trusted.L-01

Issue

In the burn and bridgeBurn functions, IERC20(address(this)).safeTransferFrom(_from, address(this), _amt); is used. While SafeERC20 is generally good practice for interacting with external ERC-20 tokens, using safeTransferFrom to transfer tokens to address(this) (the token contract itself) is not strictly necessary for security. The contract is interacting with its own token balance, and a direct _transfer or _approve followed by _transferFrom would suffice without the SafeERC20 wrapper, as the contract's own _transfer logic is trusted.

Fix

Consider simplifying the burn and bridgeBurn functions by directly calling _transfer or _transferFrom if the intent is to move tokens within the contract's own context, rather than using SafeERC20 for self-transfers. This would slightly reduce gas costs and improve readability without compromising security. Alternatively, keep the current implementation as it is harmless.

Status

Unresolved

Analysis

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

The STBL_Token contract is an upgradeable ERC-20 token utilizing OpenZeppelin's battle-tested libraries for access control, pausing, and UUPS upgradeability. The technical implementation is robust, showing no critical code-level vulnerabilities like reentrancy or integer overflows. However, the contract exhibits a high degree of centralization, with the DEFAULT_ADMIN_ROLE holding significant power over critical functions such as role management, contract upgrades, and token supply manipulation (via MINTER_ROLE and BRIDGE_ROLE). This centralization, while common for initial deployments, introduces a single point of failure and elevates the overall risk to Medium.

Technical6/10Medium risk

The STBL_Token contract leverages battle-tested OpenZeppelin libraries for its core ERC-20 functionality, access control (7.3), pausing, and UUPS upgradeability (7.7). The code demonstrates good security practices, including the use of Solidity 0.8.x to prevent integer overflows/underflows and no apparent reentrancy vulnerabilities (7.2). The implementation of ERC2771Context for meta-transactions is correctly handled. A minor redundancy exists where _grantRole(DEFAULT_ADMIN_ROLE, _msgSender()); is called twice in the initialize() function (M-01), and SafeERC20 is used for self-transfers which is technically unnecessary but harmless (L-01).

Governance1/10High risk

The contract implements a MAX_CAP to limit total token supply, and distinct roles (MINTER_ROLE, BRIDGE_ROLE, PAUSE_ROLE) are used for specific actions, providing granular control (7.4). The PAUSE_ROLE offers an emergency stop mechanism for transfers. However, the contract exhibits high centralization (7.5), with the DEFAULT_ADMIN_ROLE possessing extensive power over all other roles, contract upgrades, and the trusted forwarder (H-01). This concentration of power means a compromise of the DEFAULT_ADMIN_ROLE could lead to significant economic or operational risks, including arbitrary minting/burning if the MINTER_ROLE is granted to a malicious actor.

Upgrades1/10High risk

The contract correctly implements the UUPS upgradeability pattern using OpenZeppelin's UUPSUpgradeable module (7.7). The _authorizeUpgrade function is properly overridden and protected by the UPGRADER_ROLE, ensuring only authorized entities can initiate upgrades. An event ContractUpgraded is emitted for transparency. However, the UPGRADER_ROLE itself is controlled by the DEFAULT_ADMIN_ROLE, meaning the security of upgrades ultimately depends on the security of the DEFAULT_ADMIN_ROLE (H-01).

Final RecommendationWhat to do about this score

To mitigate the risks associated with centralized control, it is strongly recommended to secure the DEFAULT_ADMIN_ROLE with a robust multi-signature wallet (e.g., Gnosis Safe) requiring multiple independent approvals for critical operations.

Consider implementing a time-lock mechanism for sensitive administrative actions, such as role changes or upgrades, to provide a window for community review or emergency intervention. Regularly review and audit the addresses holding administrative roles to ensure their security and integrity.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkBNB Chain
Token age11mo
Contract0x8ded…79e3
Deployer0x94be…59a5
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Badge for your website
STBL_Token - STBL Governance 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 17, 202676High

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

Related Audits

6 more on the recordAll audits
Zypher TokenPOP · BNB Chain76HighTartSwapTART · BNB Chain76HighDisney (Ondo Tokenized)DISON · BNB Chain76HighSpaceXSPCXB · BNB Chain77HighLorenzo Governance TokenBANK · BNB Chain77HighVenusCoinBNB Chain77High

Would You Like a More Detailed Audit of STBL_Token - STBL Governance 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