Quantum Audit Logo

Is CharacterX a Scam?

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

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

CharacterX CAI
0x7e7e…b774
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit reviewed the provided Solidity code for the CaiToken, which implements the ERC20 standard. The contract largely adheres to well-established patterns, leveraging robust OpenZeppelin-like structures. No critical or high-severity vulnerabilities were identified in the provided abstract ERC20 implementation.

3 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$360.8K
Liquidity
$110.7K
Price
$0.08053
Token Age
2d
Top 10 Holders
100.0%

Security Findings

3 Info
Info

Safe Use of `unchecked` Blocks

I-01The `_update` function utilizes `unchecked` blocks for arithmetic operations such as `_balances[from] = fromBalance - value;` and `_balances[to] += value;`. Similar `unchecked` blocks are used for `_totalSupply` adjustments during minting and burning. This pattern is observed in the `_update` function for both balance and total supply modifications.
IssueThe `_update` function utilizes `unchecked` blocks for arithmetic operations such as `_balances[from] = fromBalance - value;` and `_balances[to] += value;`. Similar `unchecked` blocks are used for `_totalSupply` adjustments during minting and burning. This pattern is observed in the `_update` function for both balance and total supply modifications.
FixThis is a standard and safe practice in Solidity 0.8+ for gas optimization. The necessary checks (e.g., `if (fromBalance < value)`) are performed prior to entering the `unchecked` block, ensuring that underflow conditions are reverted before the `unchecked` operation. No action is required as this implementation is secure.
StatusResolved
Info

ERC20 `approve` Race Condition

I-02The standard ERC20 `approve` function is susceptible to a known race condition. If a user approves an amount for a spender, and then attempts to change that approved amount, a malicious spender could front-run the second `approve` transaction. This allows the spender to spend the original allowance before the new allowance is set, potentially leading to the spender having access to the sum of both allowances.
IssueThe standard ERC20 `approve` function is susceptible to a known race condition. If a user approves an amount for a spender, and then attempts to change that approved amount, a malicious spender could front-run the second `approve` transaction. This allows the spender to spend the original allowance before the new allowance is set, potentially leading to the spender having access to the sum of both allowances.
FixWhile not a vulnerability in the contract's code itself, it's an inherent risk of the ERC20 standard. Users should be advised to set their allowance to zero before setting a new non-zero allowance. Alternatively, consider implementing `increaseAllowance` and `decreaseAllowance` functions, which are safer alternatives for modifying allowances, to mitigate this risk.
StatusUnresolved
Info

Internal `_mint` and `_burn` Functions Require External Exposure and Access Control

I-03The `_mint` and `_burn` functions are declared as `internal` within the abstract `ERC20` contract. This means they cannot be called directly from external accounts. For the `CaiToken` to have minting or burning capabilities, the concrete `CaiToken` contract must implement `external` functions that wrap these `internal` calls.
IssueThe `_mint` and `_burn` functions are declared as `internal` within the abstract `ERC20` contract. This means they cannot be called directly from external accounts. For the `CaiToken` to have minting or burning capabilities, the concrete `CaiToken` contract must implement `external` functions that wrap these `internal` calls.
FixIf `CaiToken` is intended to be a fixed-supply token, no action is needed. However, if minting or burning is desired, ensure that any `external` functions exposing `_mint` or `_burn` are protected by robust access control mechanisms (e.g., `onlyOwner`, `onlyMinter` roles) to prevent unauthorized supply manipulation. The prefill indicates a multisig owner, which would be an appropriate entity to control such functions.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is based on the widely adopted ERC20 standard, utilizing OpenZeppelin-like patterns for core functionalities like `transfer` and `approve`. Code security (7.2) is strong, with appropriate use of `unchecked` blocks for gas optimization, preceded by necessary checks to prevent underflows. The `ECDSA` library is included, indicating potential future use for `permit` functionality, enhancing user experience.

GovernanceHigh3/10

The economic model (7.4) is that of a standard ERC20 token, providing basic transfer and approval functionalities. Governance (7.5) is implied to be robust, with the prefill indicating a multisig owner () with a 2/3 threshold, which enhances security for administrative actions. The internal `_mint` and `_burn` functions require careful external exposure and access control in the concrete token implementation.

UpgradesMedium6/10

The contract is not deployed as a proxy (7.7) and is not designed for upgradeability. This eliminates upgrade-related risks, ensuring immutability post-deployment. Operations (7.8) are straightforward for a standard token.

Security Checklist

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

Holder Composition

100.0% in top 10
0.0% in wallets100.0% in contracts
Effective Concentration40.0%

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

$116.8K across 2 pairs
Pancakeswap v3USDTanalysed$110.7K94.8%UniswapUSDT$6.1K5.2%

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.

Key Addresses

1 addresses
Deployer
0x14b1…3a72

What Raised This Score

4 factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Top-10 concentration > 30% (100.0% total → 40.0% effective; 0.0% in EOAs, 100.0% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • Token age < 7 days (early, volatile)

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
Bitway Token (BTW)Medium RiskMarsCoinMedium RiskCZ'S DOG (BROCCOLI)Medium RiskMame Inu (MAME)Medium RiskAPRO oracle Token (AT)Medium Riskutility token (UTILITY)Medium Risk

Would You Like a More Detailed Audit of CharacterX?

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

Get Detailed Audit