Is STBL_Token - STBL Governance Token (STBL) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low

High

Centralized Control Over Critical Functions

H-01The `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.

IssueThe `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.

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

StatusUnresolved

Medium

Redundant Role Grant in Initialization

M-01The `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.

IssueThe `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.

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

StatusUnresolved

Low

Unnecessary SafeERC20 Usage for Self-Transfer

L-01In 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.

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh1/10

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.

UpgradesHigh1/10

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

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Holder Composition

79.5% in top 10

56.0% in wallets23.5% in contracts

Effective Concentration65.4%

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

$1.78M across 9 pairs

Pancakeswap v3USDCanalysed$1.74M Pancakeswap v3USDT$27.3K Pancakeswap v3WBNB$5.8K Pancakeswap v3USDC$2.1K Pancakeswap v3USDT$2.0K UniswapUSDT$851

Show 3 more pairsShow less

Pancakeswap v2WBNB$573 Pancakeswap v3WBNB$426 Pancakeswap v2USDT$3

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

5 addresses

Deployer

0x94be…59a5

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.

What Raised This Score

10 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

Is STBL_Token - STBL Governance Token Safe?

Security Findings

Centralized Control Over Critical Functions

Redundant Role Grant in Initialization

Unnecessary SafeERC20 Usage for Self-Transfer

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of STBL_Token - STBL Governance Token?