Quantum Audit Logo

Is CreoEngine Safe?

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

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

CreoEngine CREO
0x9521…1eb7
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
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The CreoEngine BEP20 token implements standard token functionalities along with custom anti-sniper and anti-whale mechanisms. The contract uses SafeMath for arithmetic safety and Ownable for access control, with the owner being a 2/3 multisig. A critical design flaw in the anti-sniper mechanism could lead to legitimate users being unable to transfer their tokens, posing a significant risk to user funds.

1 High2 Medium1 Low1 Informational
Volume 24h
$88.5K
Liquidity
$57.7K
Price
$0.002354
Token Age
2y
Top 10 Holders
58.3%

Security Findings

1 High2 Med1 Low1 Info
High

Flawed Anti-Sniper Mechanism Leading to Legitimate User Lockout

H-01The `_transfer` function marks the `recipient` as a sniper if a transfer occurs within `deadBlocks` after `launchedAt`. This logic means any user receiving tokens during this initial period, even legitimate buyers or users receiving tokens from the owner, will be permanently marked as a sniper. Once marked, these addresses are unable to transfer their tokens, effectively locking their funds indefinitely. This design flaw can lead to significant financial loss for innocent users.
IssueThe `_transfer` function marks the `recipient` as a sniper if a transfer occurs within `deadBlocks` after `launchedAt`. This logic means any user receiving tokens during this initial period, even legitimate buyers or users receiving tokens from the owner, will be permanently marked as a sniper. Once marked, these addresses are unable to transfer their tokens, effectively locking their funds indefinitely. This design flaw can lead to significant financial loss for innocent users.
FixRe-evaluate the anti-sniper logic. Consider alternative mechanisms that do not permanently lock legitimate users' funds. If a temporary restriction is desired, ensure there is a clear and automatic expiration or an owner-controlled mechanism to remove sniper status for legitimate users. For example, restrict transfers only for a specific duration or implement a whitelist for initial liquidity providers/buyers.
StatusUnresolved
Medium

Centralized Control Over Critical Parameters

M-01The `owner` (a 2/3 multisig) has extensive control over core contract functionalities, including `openTrading`, `maxTxAmount`, and the `_isSniper` list. While the multisig mitigates a single-point-of-failure, this level of control can significantly impact token tradability, user experience, and the overall economic model. For instance, the owner can unilaterally pause trading or restrict transaction amounts at will, affecting all token holders.
IssueThe `owner` (a 2/3 multisig) has extensive control over core contract functionalities, including `openTrading`, `maxTxAmount`, and the `_isSniper` list. While the multisig mitigates a single-point-of-failure, this level of control can significantly impact token tradability, user experience, and the overall economic model. For instance, the owner can unilaterally pause trading or restrict transaction amounts at will, affecting all token holders.
FixConsider implementing a timelock for critical parameter changes (e.g., `openTrading`, `maxTxAmount`) to provide transparency and allow users to react to impending changes. As the project matures, explore options for progressive decentralization or community governance over these parameters.
StatusUnresolved
Medium

Potential for Denial of Service via `tradingOpen` and `maxTxAmount`

M-02The owner can unilaterally set `tradingOpen` to `false`, effectively pausing all non-owner transfers. Additionally, the `maxTxAmount` can be set to a very low value, severely restricting trading for non-exempt addresses. While these features might be intended for emergency situations or launch control, they present a significant centralization risk and potential for denial of service for token holders, hindering liquidity and market operations.
IssueThe owner can unilaterally set `tradingOpen` to `false`, effectively pausing all non-owner transfers. Additionally, the `maxTxAmount` can be set to a very low value, severely restricting trading for non-exempt addresses. While these features might be intended for emergency situations or launch control, they present a significant centralization risk and potential for denial of service for token holders, hindering liquidity and market operations.
FixClearly define and communicate the circumstances under which `tradingOpen` would be toggled or `maxTxAmount` would be adjusted. Implement a timelock for changes to these critical variables to provide transparency and allow users to react. Consider adding a minimum threshold for `maxTxAmount` to prevent it from being set to an arbitrarily low value.
StatusUnresolved
Low

Lack of Event Emission for Critical Administrative Actions

L-01The provided code snippet shows `setMaxTxAmount` (truncated) and implies management of `_isMaxWalletExempt`. It is crucial that all state-changing administrative actions, especially those affecting core token mechanics like `maxTxAmount` or user exemptions, emit corresponding events. Without events, off-chain monitoring and transparency for users regarding these critical changes are significantly hampered.
IssueThe provided code snippet shows `setMaxTxAmount` (truncated) and implies management of `_isMaxWalletExempt`. It is crucial that all state-changing administrative actions, especially those affecting core token mechanics like `maxTxAmount` or user exemptions, emit corresponding events. Without events, off-chain monitoring and transparency for users regarding these critical changes are significantly hampered.
FixEnsure all administrative functions that modify critical state variables (e.g., `maxTxAmount`, `_isMaxWalletExempt` status) emit corresponding events. This improves auditability, allows for off-chain tracking, and enhances transparency for the community.
StatusUnresolved
Info

Old Solidity Compiler Version

I-01The contract is compiled with Solidity version `0.5.12`. While `SafeMath` is used to mitigate integer overflow/underflow, newer compiler versions (e.g., 0.8.x) include built-in overflow/underflow checks by default, reducing reliance on external libraries and potentially improving gas efficiency. Newer versions also offer various language improvements and bug fixes.
IssueThe contract is compiled with Solidity version `0.5.12`. While `SafeMath` is used to mitigate integer overflow/underflow, newer compiler versions (e.g., 0.8.x) include built-in overflow/underflow checks by default, reducing reliance on external libraries and potentially improving gas efficiency. Newer versions also offer various language improvements and bug fixes.
FixConsider upgrading to a more recent Solidity compiler version (e.g., 0.8.x) for future deployments. This would allow for the removal of `SafeMath` (as arithmetic operations would revert on overflow/underflow by default) and leverage other compiler optimizations and security features.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages SafeMath for arithmetic safety (7.2 Code Security) and adheres to the BEP20 standard. A custom anti-sniper mechanism is implemented, intended to prevent early trading manipulation. However, this mechanism has a critical flaw (7.2 Code Security) where legitimate recipients during the initial 'deadBlocks' period are permanently marked as snipers, locking their funds. The contract also includes functions for recovering stuck BNB and other tokens (7.8 Operations).

GovernanceHigh3/10

The contract employs an Ownable pattern with a 2/3 multisig owner, enhancing access control (7.3 Access Control) compared to a single owner. The owner has significant control over 'tradingOpen', 'maxTxAmount', and the '_isSniper' list (7.4 Economic, 7.5 Governance). This centralization, while common for new projects, introduces potential for denial of service and requires careful management (7.8 Operations) to prevent adverse impacts on token holders.

UpgradesMedium6/10

The CreoEngine contract is not designed with an upgrade mechanism (7.7 Upgrades). Any future modifications to the token logic would necessitate deploying a new contract and migrating existing token holders. This approach avoids upgrade-related complexities and risks but requires a full redeployment for any significant changes.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

58.3% in top 10
46.6% in wallets11.7% in contracts
Effective Concentration51.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

$58.8K across 3 pairs
Pancakeswap v2USDTanalysed$57.7K98.2%Pancakeswap v2BUSD$1.1K1.8%Pancakeswap v2WBNB$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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x939d…8fae
Unlocked LP Held By
0xe123…1741

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 — Multisig (2-of-3)
  • Top-10 concentration > 50% (58.3% total → 51.3% effective; 46.6% in EOAs, 11.7% in contracts — heavy)
  • 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)
  • LP claimed locked but only 0.0% actually locked
  • 1 High finding(s) from audit
  • 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

Related Audits

6 more on the record
Quack AI Token (Q)High RiskHoloworld AI (HOLO)High RiskPowerHigh RiskOpenGradient (OPG)High RiskXPULSHigh RiskHana Token (HANA)High Risk

Would You Like a More Detailed Audit of CreoEngine?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit