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 BNC4
0x7c8d…545c
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 10d ago 1 audit on record New Launch · 4d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The Stock4Token contract, deployed as an upgradeable BeaconProxy, implements an ERC20 token with custom scaling logic and administrative controls. The audit identified significant centralization risks associated with the 'admin' and 'issuer' roles, which possess extensive power over token supply, metadata, and the unique UI multiplier mechanism. While the contract utilizes OpenZeppelin's upgradeable standards, the core economic logic for the UI multiplier is not fully visible in the provided snippet, posing a challenge for complete assessment. Dependencies on an immutable factory address also introduce long-term operational risks.

2 High3 Medium1 Low
! 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
$5.78M
Liquidity
$1.82M
Price
$5.2300
Token Age
4d
Top 10 Holders
51.2%

Security Findings

2 High3 Med1 Low
High

Centralized Control by Admin and Issuer Roles

H-01The `_admin` and `_issuerOverride` roles possess extensive control over the contract. The `_admin` can transfer admin rights, change token metadata (name, symbol, identifier, URI), pause/unpause the contract, and set the `_issuerOverride`. The `_issuer` (either `_issuerOverride` or `_factory.issuer()`) can mint new tokens, burn existing tokens, and set the UI multiplier. This high degree of centralization (7.3 Access Control, 7.5 Governance) means that a compromise of these keys could lead to significant damage, including arbitrary token minting/burning, contract pausing, or malicious metadata changes.
IssueThe `_admin` and `_issuerOverride` roles possess extensive control over the contract. The `_admin` can transfer admin rights, change token metadata (name, symbol, identifier, URI), pause/unpause the contract, and set the `_issuerOverride`. The `_issuer` (either `_issuerOverride` or `_factory.issuer()`) can mint new tokens, burn existing tokens, and set the UI multiplier. This high degree of centralization (7.3 Access Control, 7.5 Governance) means that a compromise of these keys could lead to significant damage, including arbitrary token minting/burning, contract pausing, or malicious metadata changes.
FixImplement multi-signature wallets for both the 'admin' and 'issuer' roles to distribute control and reduce the risk of a single point of failure. Consider adding a timelock for critical administrative actions, such as transferring admin rights or setting the issuer, to provide a delay for review and potential intervention.
StatusUnresolved
High

High Economic Power of Issuer Role

H-02The `issuer` role has direct control over the token's supply through the `mint` and `burn` functions, and can significantly influence the token's perceived value by setting the `_uiMultiplier` (7.4 Economic). While the `setUIMultiplier` function includes range and time checks, the ability to arbitrarily increase supply or manipulate the multiplier can have profound economic consequences for token holders. This concentration of economic power represents a substantial risk if the `issuer` account is compromised or acts maliciously.
IssueThe `issuer` role has direct control over the token's supply through the `mint` and `burn` functions, and can significantly influence the token's perceived value by setting the `_uiMultiplier` (7.4 Economic). While the `setUIMultiplier` function includes range and time checks, the ability to arbitrarily increase supply or manipulate the multiplier can have profound economic consequences for token holders. This concentration of economic power represents a substantial risk if the `issuer` account is compromised or acts maliciously.
FixEvaluate if the `mint` and `burn` functionalities are strictly necessary post-initialization, or if their scope can be limited (e.g., only for specific events or with community governance). For the `setUIMultiplier` function, consider implementing a governance mechanism or a timelock for changes, allowing token holders or a decentralized body to review and approve significant multiplier adjustments.
StatusUnresolved
Medium

Incomplete `uiMultiplier()` Logic for Audit

M-01The contract implements the `IScaledUIAmount` interface, which implies a `uiMultiplier()` function and the application of this multiplier to token balances. However, the provided code snippet does not include the implementation of `uiMultiplier()` or any functions that demonstrate how `_uiMultiplier` and `_newUIMultiplier` are actually applied to scale token balances (e.2 Code Security). Without this critical logic, it is impossible to fully assess the correctness, security, and economic impact of the token's unique scaling mechanism.
IssueThe contract implements the `IScaledUIAmount` interface, which implies a `uiMultiplier()` function and the application of this multiplier to token balances. However, the provided code snippet does not include the implementation of `uiMultiplier()` or any functions that demonstrate how `_uiMultiplier` and `_newUIMultiplier` are actually applied to scale token balances (e.2 Code Security). Without this critical logic, it is impossible to fully assess the correctness, security, and economic impact of the token's unique scaling mechanism.
FixProvide the complete source code for all implemented interfaces, especially the `uiMultiplier()` function and any related balance scaling logic. A full audit of this core functionality is essential to ensure its integrity and prevent potential miscalculations or exploits.
StatusUnresolved
Medium

Immutability of `_factory` Address and External Dependency

M-02The `_factory` address is set during initialization and cannot be changed thereafter (7.8 Operations). The `issuer()` function relies on `_factory.issuer()` if `_issuerOverride` is `address(0)`. This creates a permanent, unchangeable dependency on the `IStock4Factory` contract. If the factory contract were to be compromised, upgraded maliciously, or become defunct, it could directly impact the `Stock4Token`'s `issuer` role and overall functionality, with no recourse to update the factory address.
IssueThe `_factory` address is set during initialization and cannot be changed thereafter (7.8 Operations). The `issuer()` function relies on `_factory.issuer()` if `_issuerOverride` is `address(0)`. This creates a permanent, unchangeable dependency on the `IStock4Factory` contract. If the factory contract were to be compromised, upgraded maliciously, or become defunct, it could directly impact the `Stock4Token`'s `issuer` role and overall functionality, with no recourse to update the factory address.
FixConsider if the `_factory` address needs to be immutable. If not, implement a controlled mechanism (e.g., `onlyAdmin` with a timelock) to update the `_factory` address in case of emergencies or upgrades to the factory contract. If immutability is intended, ensure the `IStock4Factory` contract is extremely robust and its long-term availability and security are guaranteed.
StatusUnresolved
Medium

Centralized Upgradeability

M-03The contract is deployed as a BeaconProxy, allowing for future upgrades of its logic. However, the control over these upgrades is centralized under the `_admin` role (7.7 Upgrades, 7.5 Governance). This means that a single entity has the power to change the contract's entire logic, which could introduce new vulnerabilities or malicious functionality without broader consensus. While common for proxy patterns, it represents a significant trust assumption.
IssueThe contract is deployed as a BeaconProxy, allowing for future upgrades of its logic. However, the control over these upgrades is centralized under the `_admin` role (7.7 Upgrades, 7.5 Governance). This means that a single entity has the power to change the contract's entire logic, which could introduce new vulnerabilities or malicious functionality without broader consensus. While common for proxy patterns, it represents a significant trust assumption.
FixImplement a timelock for upgrade operations to provide a delay between the proposal and execution of an upgrade. This allows time for community review and potential objection. For enhanced decentralization, consider integrating a governance mechanism (e.g., DAO voting) to approve upgrade proposals.
StatusUnresolved
Low

Potential Redundancy in `setUIMultiplier`

L-01In the `setUIMultiplier` function, the line `_uiMultiplier = oldMultiplier;` appears before `_newUIMultiplier` and `_effectiveAt` are updated. Given that `oldMultiplier` is derived from `uiMultiplier()` (which would return the currently effective multiplier), this assignment might be redundant or a no-op if `oldMultiplier` is already equal to `_uiMultiplier`. Without the full `uiMultiplier()` implementation, its exact effect is unclear, but it could potentially be simplified or clarified (7.2 Code Security).
IssueIn the `setUIMultiplier` function, the line `_uiMultiplier = oldMultiplier;` appears before `_newUIMultiplier` and `_effectiveAt` are updated. Given that `oldMultiplier` is derived from `uiMultiplier()` (which would return the currently effective multiplier), this assignment might be redundant or a no-op if `oldMultiplier` is already equal to `_uiMultiplier`. Without the full `uiMultiplier()` implementation, its exact effect is unclear, but it could potentially be simplified or clarified (7.2 Code Security).
FixReview the logic of `setUIMultiplier` in conjunction with the full `uiMultiplier()` implementation. If `_uiMultiplier = oldMultiplier;` is indeed redundant, it should be removed for clarity. If it serves a specific purpose (e.g., finalizing a previous pending update), add a comment to explain its intent.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract demonstrates good adherence to OpenZeppelin's upgradeable patterns (7.1 Architecture) and includes robust input validation for addresses and strings (7.2 Code Security). Standard security practices like `_msgSender()` for access control checks are correctly implemented. However, a key technical concern is the incomplete visibility of the `uiMultiplier()` function and its application, which is central to the contract's unique scaling mechanism, making a full assessment of its correctness challenging (7.2 Code Security). Additionally, a line in `setUIMultiplier` appears redundant, potentially affecting code clarity (7.2 Code Security).

GovernanceHigh2/10

The contract exhibits a high degree of centralized control, with the 'admin' and 'issuer' roles holding significant power (7.3 Access Control, 7.5 Governance). The 'admin' can transfer administrative control, modify token metadata, pause/unpause the contract, and set the 'issuer'. The 'issuer' has extensive economic control, including the ability to mint and burn tokens, and critically, to set the UI multiplier (7.4 Economic). This concentration of power introduces substantial trust assumptions and a high economic risk if these privileged accounts are compromised or act maliciously (7.4 Economic).

UpgradesHigh1/10

The contract correctly implements the `Initializable` pattern and `_disableInitializers()` for upgradeability via a BeaconProxy (7.7 Upgrades). This design allows for future logic updates, which is a strength. However, the upgrade mechanism itself is centralized, with the 'admin' role having the sole authority to initiate upgrades (7.7 Upgrades, 7.5 Governance). This central point of control for upgrades represents a significant trust assumption, as a compromised admin key could lead to malicious contract logic deployment.

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

51.2% in top 10
14.0% in wallets37.2% in contracts
Effective Concentration28.9%

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

$2.23M across 15 pairs
Pancakeswap v3USDTanalysed$1.82M81.6%UniswapUSDC$333.7K15.0%Pancakeswap v3WBNB$32.6K1.5%Pancakeswap v3USDT$21.7K1.0%UniswapUSDT$17.5K0.8%Pancakeswap v2WBNB$5.0K0.2%
Show 4 more pairsShow less
Pancakeswap v3USDC$340.0%UniswapUSDT$320.0%Uniswap v2WBNB$10.0%UniswapWBNB$10.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 Holder38.4%
Top-3 Unlocked74.0%

Key Addresses

11 addresses
Deployer
0x46cd…4fd7
Unlocked LP Held By
0x2f42…a93d0x6079…11140xa23d…2c6a0xca68…a8880xbbde…084c0x13a8…3f160x0342…8e470xee87…1b240xc3bc…9c4d0x58dd…ded5

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)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 20% (51.2% total → 28.9% effective; 14.0% in EOAs, 37.2% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 7 days (early, volatile)
  • 2 High finding(s) from audit
  • 3 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
Block Street (BSB)Critical RiskLIGHTCritical RiskDexeCritical RiskArcium (ARX)Critical RiskSolstice (SLX)Critical RiskFLOKICritical 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