Quantum Audit Logo

Is CEA Industries a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

CEA Industries BNCB
0x4902…ec3f
BNB Chain
Not verifiedThis 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 5d ago 1 audit on record New Launch · 4d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The SecuritiesToken contract, an upgradeable ERC-20 token, demonstrates good technical implementation using OpenZeppelin standards and the ERC8056 scaled UI token pattern. However, the design incorporates a high degree of centralization, with the DEFAULT_ADMIN_ROLE possessing extensive control over critical economic parameters and external dependencies. This centralization, combined with the wide range of the UI multiplier, introduces significant economic and governance risks. Recommendations focus on strengthening governance and access controls for administrative functions.

2 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (4d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$775.5K
Liquidity
$4.67M
Price
$4.9800
Token Age
4d
Top 10 Holders
92.4%

Security Findings

2 High1 Med1 Low1 Info
High

Centralized Control and Economic Manipulation via Admin/Issuer Roles

H-01The `DEFAULT_ADMIN_ROLE` holds extensive power, including the ability to grant/revoke `ISSUER_ROLE` (which can mint/burn tokens), enable/disable minting/burning, and set the `_uiMultiplier`. This high degree of centralization means a single compromised or malicious admin address could arbitrarily inflate or deflate the token supply, manipulate token value, or block operations, posing a significant economic and governance risk (7.3 Access Control, 7.4 Economic, 7.5 Governance).
IssueThe `DEFAULT_ADMIN_ROLE` holds extensive power, including the ability to grant/revoke `ISSUER_ROLE` (which can mint/burn tokens), enable/disable minting/burning, and set the `_uiMultiplier`. This high degree of centralization means a single compromised or malicious admin address could arbitrarily inflate or deflate the token supply, manipulate token value, or block operations, posing a significant economic and governance risk (7.3 Access Control, 7.4 Economic, 7.5 Governance).
FixImplement a multi-signature wallet for the `DEFAULT_ADMIN_ROLE` to distribute control and require multiple approvals for critical actions. For highly sensitive operations like setting the `_uiMultiplier` or changing compliance/pause managers, consider adding a time-lock mechanism to allow for community review or emergency intervention.
StatusUnresolved
High

Extreme Multiplier Range Allows Significant Value Manipulation

H-02The `_validateMultiplier` function in `ERC8056BaseUpgradeable` allows the `_uiMultiplier` to be set within an extremely wide range, from `1e9` (0.000000001x) to `1e27` (1,000,000,000x). A malicious `DEFAULT_ADMIN_ROLE` or `ISSUER_ROLE` (who can authorize multiplier updates) could set an extreme multiplier, effectively destroying or massively inflating the perceived value of token holders' balances, leading to severe economic consequences (7.4 Economic).
IssueThe `_validateMultiplier` function in `ERC8056BaseUpgradeable` allows the `_uiMultiplier` to be set within an extremely wide range, from `1e9` (0.000000001x) to `1e27` (1,000,000,000x). A malicious `DEFAULT_ADMIN_ROLE` or `ISSUER_ROLE` (who can authorize multiplier updates) could set an extreme multiplier, effectively destroying or massively inflating the perceived value of token holders' balances, leading to severe economic consequences (7.4 Economic).
FixReview and narrow the acceptable range for the `_uiMultiplier` to align with the intended economic model and prevent extreme value fluctuations. If such a wide range is intentional, ensure robust governance and multi-sig controls are in place for any multiplier updates.
StatusUnresolved
Medium

External Dependency Risk for Compliance and Pause Managers

M-01The `SecuritiesToken` contract relies on external contracts for compliance (`ComplianceClientUpgradeable`) and pausing functionality (`PauseManagerClientUpgradeable`). The `_update` function, which handles all token transfers, calls `_checkTokenIsPaused()` and `_checkIsCompliant()`. If these external contracts are compromised, maliciously configured, or become inoperable, they could lead to a denial of service by indefinitely pausing transfers or enforcing arbitrary, undesirable compliance rules (7.6 External, 7.8 Operations).
IssueThe `SecuritiesToken` contract relies on external contracts for compliance (`ComplianceClientUpgradeable`) and pausing functionality (`PauseManagerClientUpgradeable`). The `_update` function, which handles all token transfers, calls `_checkTokenIsPaused()` and `_checkIsCompliant()`. If these external contracts are compromised, maliciously configured, or become inoperable, they could lead to a denial of service by indefinitely pausing transfers or enforcing arbitrary, undesirable compliance rules (7.6 External, 7.8 Operations).
FixImplement strict access controls and robust security measures for the `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` contracts. Consider adding circuit breakers or emergency mechanisms in `SecuritiesToken` to bypass or disable these external checks under extreme circumstances, if feasible and aligned with the project's risk model. Ensure the addresses of these external contracts are managed securely, ideally through a multi-sig wallet and time-lock.
StatusUnresolved
Low

Lack of Time Locks for Critical Administrative Operations

L-01While access to critical administrative functions (e.g., setting compliance/pause managers, enabling/disabling mint/burn, changing the multiplier) is restricted to the `DEFAULT_ADMIN_ROLE`, there are no time-lock mechanisms in place. This means that once an admin initiates a critical change, it takes effect immediately. In the event of a compromised admin key, this could allow an attacker to make immediate, irreversible malicious changes without any window for detection or intervention (7.3 Access Control, 7.5 Governance).
IssueWhile access to critical administrative functions (e.g., setting compliance/pause managers, enabling/disabling mint/burn, changing the multiplier) is restricted to the `DEFAULT_ADMIN_ROLE`, there are no time-lock mechanisms in place. This means that once an admin initiates a critical change, it takes effect immediately. In the event of a compromised admin key, this could allow an attacker to make immediate, irreversible malicious changes without any window for detection or intervention (7.3 Access Control, 7.5 Governance).
FixConsider implementing a time-lock mechanism for highly sensitive administrative functions. This would introduce a delay between the initiation and execution of a critical change, providing a window for monitoring, detection, and potential mitigation if an unauthorized action is identified.
StatusUnresolved
Info

Potential High Gas Cost for Initializing Issuers

I-01The `initialize` function iterates through the `issuers_` array to grant the `ISSUER_ROLE`. If the `issuers_` array contains a very large number of addresses, the transaction to initialize the contract could exceed the block gas limit on deployment. While this is a deployment-time concern and not a runtime vulnerability, it could complicate initial setup (7.2 Code Security, 7.8 Operations).
IssueThe `initialize` function iterates through the `issuers_` array to grant the `ISSUER_ROLE`. If the `issuers_` array contains a very large number of addresses, the transaction to initialize the contract could exceed the block gas limit on deployment. While this is a deployment-time concern and not a runtime vulnerability, it could complicate initial setup (7.2 Code Security, 7.8 Operations).
FixFor very large lists of initial issuers, consider a phased approach or a separate function to add issuers post-initialization, allowing for multiple transactions if needed. Ensure the initial `issuers_` array size is within practical gas limits for deployment.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract `SecuritiesToken` demonstrates good technical practices, inheriting from OpenZeppelin's upgradeable contracts and implementing the ERC8056 standard for scaled UI amounts. It includes robust input validation for string lengths and zero addresses during initialization (7.2 Code Security). The upgradeability pattern via BeaconProxy and OpenZeppelin's `initializer` and `__gap` storage is correctly implemented, ensuring safe future upgrades (7.7 Upgrades). However, the contract relies on external `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` contracts, introducing a dependency risk where a compromise or malicious configuration of these external contracts could halt or restrict token transfers (7.6 External).

GovernanceHigh1/10

The `SecuritiesToken` contract exhibits a high degree of centralization, with the `DEFAULT_ADMIN_ROLE` possessing extensive control over critical functions (7.3 Access Control, 7.5 Governance). The admin can grant/revoke `ISSUER_ROLE`, enable/disable mint/burn, and crucially, set the `_uiMultiplier` which directly impacts token value. The allowed range for `_uiMultiplier` is extremely wide (1e-9x to 1e9x), presenting a significant economic manipulation risk if controlled by a malicious or compromised entity (7.4 Economic). While this design might be intentional for a 'securities token,' it concentrates power and potential for economic impact.

UpgradesHigh1/10

The contract is designed with a robust upgradeability mechanism, utilizing OpenZeppelin's `initializer` pattern and `__gap` storage to prevent storage collisions during upgrades (7.7 Upgrades). It is deployed as an implementation behind a BeaconProxy, which allows for efficient and standardized upgrades across multiple instances of the same logic contract. This setup ensures that the contract can be safely updated in the future without re-deploying individual proxy instances, provided the Beacon controller is secure.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

92.4% in top 10
64.0% in wallets28.4% in contracts
Effective Concentration75.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

$6.23M across 8 pairs
Pancakeswap v3BNC4analysed$4.67M75.0%Pancakeswap v3USDT$1.07M17.2%Pancakeswap v3USDT$385.3K6.2%Pancakeswap v3WBNB$56.0K0.9%Pancakeswap v3WBNB$16.4K0.3%Pancakeswap v3USDT$14.2K0.2%
Show 2 more pairsShow less
UniswapUSDT$12.8K0.2%Pancakeswap v2WBNB$390.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 Holder57.4%
Top-3 Unlocked69.6%

Key Addresses

11 addresses
Deployer
0x64fd…8d53
Unlocked LP Held By
0xc71d…6cd90x93af…631b0x13a8…3f160xf694…d66c0x58dd…ded50x4dee…786b0x8b2c…b44e0x17f6…03f60x859b…e96d0x98b8…e099

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

What Raised This Score

11 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 70% (92.4% total → 75.3% effective; 64.0% in EOAs, 28.4% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 57.4% (independent LP — depth risk, pool = 75% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 2 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

Related Audits

6 more on the record
WebKey DAO 2.0 (WKEYDAO2)Critical RiskPieverse Token (PIEVERSE)Critical RiskSnapCoinCritical RiskSK Hynix (SKHYB)Critical RiskGameStop (GMEB)Critical RiskApple (AAPLB)Critical Risk

Would You Like a More Detailed Audit of CEA Industries?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit