Quantum Audit Logo

Is CRYSTAL STONES Safe?

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

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

CRYSTAL STONES CRYSTAL STONES
0xe252…0b00
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The provided source code for the FatToken contract is incomplete, specifically missing the critical `_transfer` function implementation. This omission severely limits the scope and depth of the security audit, as core token logic, fee application, and anti-bot mechanisms cannot be fully assessed. Based on the available code, the contract exhibits a highly centralized ownership model, complex and potentially high transaction fees, and intricate anti-bot/anti-whale mechanisms, all of which introduce significant security and economic risks.

1 Critical3 High1 Medium1 Informational
Volume 24h
$7.2K
Liquidity
$62.6K
Price
$0.004341
Token Age
2y
Top 10 Holders
41.4%

Security Findings

1 Crit3 High1 Med1 Info
Critical

Incomplete Source Code Provided

C-01The provided source code is truncated, specifically missing the entire implementation of the `_transfer` function. This function is fundamental to any ERC-20 token, handling all token movements, applying fees, and enforcing anti-bot/anti-whale limits. Without this critical component, a comprehensive security audit of the token's core logic, economic model, and anti-manipulation features is impossible.
IssueThe provided source code is truncated, specifically missing the entire implementation of the `_transfer` function. This function is fundamental to any ERC-20 token, handling all token movements, applying fees, and enforcing anti-bot/anti-whale limits. Without this critical component, a comprehensive security audit of the token's core logic, economic model, and anti-manipulation features is impossible.
FixProvide the complete and verified source code for the FatToken contract, including all internal helper functions and the full `_transfer` implementation, to enable a thorough security assessment.
StatusUnresolved
High

High and Complex Transaction Fees

H-01The contract allows for transaction fees up to 25% (checked by `_buyFundFee + ... < 2500`). While explicitly capped, a 25% fee is exceptionally high and can deter legitimate trading, leading to poor liquidity and a negative user experience. The fee structure is also complex, with separate fund, LP, reward, and burn fees for both buy and sell transactions, increasing the likelihood of miscalculation or unexpected behavior.
IssueThe contract allows for transaction fees up to 25% (checked by `_buyFundFee + ... < 2500`). While explicitly capped, a 25% fee is exceptionally high and can deter legitimate trading, leading to poor liquidity and a negative user experience. The fee structure is also complex, with separate fund, LP, reward, and burn fees for both buy and sell transactions, increasing the likelihood of miscalculation or unexpected behavior.
FixRe-evaluate and significantly reduce the maximum allowable transaction fees to a more reasonable and sustainable level (e.g., below 10%). Simplify the fee structure by consolidating fee types where possible to reduce complexity and potential for errors.
StatusUnresolved
High

Centralized Control and Potential for Abuse

H-02The `Ownable` pattern grants the contract owner extensive control over critical functionalities. The owner can enable/disable trading (`enableOffTrade`), adjust taxes (`enableChangeTax`), manage whitelists (`_feeWhiteList`, `_rewardList`, `isMaxEatExempt`), and control anti-bot mechanisms. This high degree of centralization creates a single point of failure, making the protocol vulnerable to malicious actions by a compromised or rogue owner, including potential rug pulls or market manipulation.
IssueThe `Ownable` pattern grants the contract owner extensive control over critical functionalities. The owner can enable/disable trading (`enableOffTrade`), adjust taxes (`enableChangeTax`), manage whitelists (`_feeWhiteList`, `_rewardList`, `isMaxEatExempt`), and control anti-bot mechanisms. This high degree of centralization creates a single point of failure, making the protocol vulnerable to malicious actions by a compromised or rogue owner, including potential rug pulls or market manipulation.
FixConsider implementing a multi-signature wallet for critical administrative functions to distribute control and reduce the risk associated with a single point of failure. Explore mechanisms to gradually decentralize control over time, such as time-locks for sensitive operations or community governance for parameter changes.
StatusUnresolved
High

Anti-Bot/Anti-Whale Mechanisms Complexity and Risk

H-03The contract incorporates a multitude of anti-bot and anti-whale mechanisms, including `maxBuyAmount`, `maxSellAmount`, `maxWalletAmount`, `_feeWhiteList`, `isMaxEatExempt`, `user2blocks`, `batchBots`, `enableKillBatchBots`, and `killBatchBlockNumber`. Such complex systems are notoriously difficult to implement without introducing unintended side effects, false positives, or bypasses. They can lead to legitimate users being blocked, create a honeypot scenario where only certain addresses can sell, or be exploited by sophisticated attackers.
IssueThe contract incorporates a multitude of anti-bot and anti-whale mechanisms, including `maxBuyAmount`, `maxSellAmount`, `maxWalletAmount`, `_feeWhiteList`, `isMaxEatExempt`, `user2blocks`, `batchBots`, `enableKillBatchBots`, and `killBatchBlockNumber`. Such complex systems are notoriously difficult to implement without introducing unintended side effects, false positives, or bypasses. They can lead to legitimate users being blocked, create a honeypot scenario where only certain addresses can sell, or be exploited by sophisticated attackers.
FixThoroughly review and simplify the anti-bot/anti-whale logic. Conduct extensive testing, including edge cases and adversarial simulations, to ensure fairness and prevent unintended consequences. Consider whether the benefits of these complex mechanisms outweigh the inherent risks and potential for abuse.
StatusUnresolved
Medium

Reward Path Configuration Risk

M-01The `rewardPath` array, crucial for multi-hop swaps in reward distribution and LP additions, is constructed with complex conditional logic in the constructor. The path depends on `currency`, `ETH`, and `_swapRouter.WETH()`. Incorrect configuration or unexpected values for these addresses could lead to an invalid swap path, causing reward distribution or liquidity provision functions to fail, effectively breaking a core part of the tokenomics.
IssueThe `rewardPath` array, crucial for multi-hop swaps in reward distribution and LP additions, is constructed with complex conditional logic in the constructor. The path depends on `currency`, `ETH`, and `_swapRouter.WETH()`. Incorrect configuration or unexpected values for these addresses could lead to an invalid swap path, causing reward distribution or liquidity provision functions to fail, effectively breaking a core part of the tokenomics.
FixSimplify the `rewardPath` construction logic if possible. Implement robust validation for `currency`, `ETH`, and `_swapRouter.WETH()` addresses to ensure they are valid and correctly configured. Consider adding owner-only functions to update the `rewardPath` in case of misconfiguration, along with a time-lock to prevent immediate malicious changes.
StatusUnresolved
Info

`TokenDistributor` Approval Pattern

I-01The `TokenDistributor` contract's constructor immediately approves `msg.sender` for `uint256(~uint256(0))` (maximum allowance) of the specified token. While in this specific context, `FatToken` deploys `TokenDistributor` and thus `FatToken` itself receives the approval (likely for internal operations), this pattern can be risky if `TokenDistributor` is deployed by an untrusted address or with a malicious token, granting excessive control to the deployer.
IssueThe `TokenDistributor` contract's constructor immediately approves `msg.sender` for `uint256(~uint256(0))` (maximum allowance) of the specified token. While in this specific context, `FatToken` deploys `TokenDistributor` and thus `FatToken` itself receives the approval (likely for internal operations), this pattern can be risky if `TokenDistributor` is deployed by an untrusted address or with a malicious token, granting excessive control to the deployer.
FixEnsure that any deployment of `TokenDistributor` is done by a trusted entity and with a legitimate token. For future designs, consider if such a broad, immediate approval is strictly necessary or if a more granular, on-demand approval mechanism could be used to reduce potential attack surface.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The technical architecture (7.1 Architecture) of FatToken is complex, incorporating various anti-bot and fee mechanisms. A critical issue is the incomplete source code, specifically the missing `_transfer` function, which prevents a full assessment of core token security (7.2 Code Security). The reward path configuration (7.2 Code Security) also presents a risk due to its intricate logic, potentially leading to failed transactions if misconfigured. The anti-bot/anti-whale mechanisms, while intended to protect, introduce significant complexity and potential for unintended behavior or bypasses (7.2 Code Security).

GovernanceMedium5/10

The contract's economic model (7.4 Economic) features highly dynamic and potentially high transaction fees (up to 25%), which can significantly impact user experience and market stability. The governance model (7.5 Governance) is highly centralized, with the owner possessing extensive control over critical parameters such as trading enablement (`enableOffTrade`), fee adjustments (`enableChangeTax`), and anti-bot whitelists. This centralization introduces a single point of failure and significant rug-pull risk. The anti-bot/anti-whale mechanisms, while aiming for fair distribution, can inadvertently create a honeypot scenario or unfairly penalize legitimate users (7.4 Economic).

UpgradesLow8/10

The FatToken contract is not designed with upgradeability features (7.7 Upgrades), meaning its logic cannot be modified after deployment. This eliminates upgrade-related risks but also removes the flexibility to fix bugs or introduce new features without a full redeployment.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

41.4% in top 10
26.0% in wallets15.3% in contracts
Effective Concentration32.2%

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

$62.6K

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

LP Burned3.8%
LP Locked76.9% · Null Address, PinkLock02
Top-1 Unlocked Holder20.9%
Top-3 Unlocked23.1%

Key Addresses

5 addresses
Deployer
0xb8c3…1dd3
Unlocked LP Held By
0x9f3a…605b0x0ed9…97060x6d00…37bf0xc924…5ea4

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

What Raised This Score

4 factors
  • Top-10 concentration > 30% (41.4% total → 32.2% effective; 26.0% in EOAs, 15.3% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 3 High finding(s) from audit
  • 1 Medium 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
Ethereum Token (ETH)High RiskUSELESS COIN (USELESS)High RiskBSquared Token (B2)High RiskBrokHigh Risko1.exchange (O)High RiskBaby Ansem (BABYANSEM)High Risk

Would You Like a More Detailed Audit of CRYSTAL STONES?

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

Get Detailed Audit