Quantum Audit Logo
Launch App

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

Is CRYSTAL STONES Safe?

BNB Chain
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance5/10Upgrades8/10Checks passed5 of 5Findings1 Critical · 3 High · 1 Medium · 1 Info6
SummaryAI Copilot

The provided source code for the FatToken contract is incomplete, specifically missing the critical _transfer function implementation.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 1 Critical finding(s) from audit
  • 3 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
15.3%Contracts26.0%Wallets58.6%Everyone else
15.3%Contracts26.0%Wallets58.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
41.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking15.3%
  • Walletsanonymous holders, free to sell26.0%
  • Everyone elsethe rest of the supply58.6%
Effective concentrationwhat the score reads32.2%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$62.6K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$62.6KShare of depth100.0%
LP Burned3.8%
LP Locked76.9% · Null Address, PinkLock02
Top-1 Unlocked Holder20.9%
Top-3 Unlocked23.1%
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.

Security Findings

1 Critical3 High1 Medium1 Info
Critical

Incomplete Source Code Provided

The 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.C-01

Issue

The 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.

Fix

Provide 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.

Status

Unresolved

High

High and Complex Transaction Fees

The 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.H-01

Issue

The 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.

Fix

Re-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.

Status

Unresolved

High

Centralized Control and Potential for Abuse

The 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.H-02

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

High

Anti-Bot/Anti-Whale Mechanisms Complexity and Risk

The 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.H-03

Issue

The 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.

Fix

Thoroughly 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.

Status

Unresolved

Medium

Reward Path Configuration Risk

The 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.M-01

Issue

The 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.

Fix

Simplify 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.

Status

Unresolved

Info

TokenDistributor Approval Pattern

The 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.I-01

Issue

The 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.

Fix

Ensure 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical5/10Medium risk

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).

Governance5/10Medium risk

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).

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

It is critical to provide the complete and verified source code for a comprehensive security audit.

Without the full _transfer function, the contract's core functionality and security cannot be properly evaluated. We strongly recommend simplifying the token's economic model, particularly the fee structure and anti-bot mechanisms, to reduce complexity and potential attack vectors. Furthermore, consider implementing a multi-signature wallet for critical administrative functions to mitigate the risks associated with centralized control and a single point of failure.

Contract & Record

1 audit on record
TypeFatToken
NetworkBNB Chain
Token age2y
Contract0xe252…0b00
Deployer0xb8c3…1dd3
Badge for your website
CRYSTAL STONES security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202649Medium
  2. Aug 5, 202655Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the CRYSTAL STONES contract address?

The CRYSTAL STONES contract on BNB Chain is 0xe252fcb1aa2e0876e9b5f3ed1e15b9b4d11a0b00. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is CRYSTAL STONES a scam?

Quantum Audit's risk score for CRYSTAL STONES is 49/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is CRYSTAL STONES liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $62.6K.

Who holds CRYSTAL STONES?

As of Sep 4, 2026, the 10 largest holders own 41.4% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Ethereum TokenETH · BNB Chain49MediumUSELESS COINUSELESS · BNB Chain49MediumPepeBNB Chain49MediumBSquared TokenB2 · BNB Chain48MediumBrokBNB Chain48Mediumo1.exchangeO · BNB Chain50Medium

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 Is this your token? Publish your own audit on this page