Quantum Audit Logo
Launch App

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

Is RICE AI Safe?

RICEBNB 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
Technical8/10Governance1/10Upgrades6/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The RiceAI contract is an ERC20 token with a time-locked transfer mechanism and a whitelist.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.3%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 30% (79.3% total → 35.7% effective; 6.7% in EOAs, 72.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.3% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
72.6%Contracts6.7%Wallets20.7%Everyone else
72.6%Contracts6.7%20.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
79.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking72.6%
  • Walletsanonymous holders, free to sell6.7%
  • Everyone elsethe rest of the supply20.7%
Effective concentrationwhat the score reads35.7%
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$450.8K across 8 pairs
Show 1 more pair

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$435.8KShare of depth96.7%
Top-1 Unlocked Holder99.3%
Top-3 Unlocked100.0%
Unlocked LP held by
0x94cc…0f1f0xd5d6…92570x556b…d59e0x4482…3bc5

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control Over Token Transfers

The Ownable contract grants the owner extensive power to control token transfers. The owner can arbitrarily add/remove addresses from the whitelist using addToWhitelist and removeFromWhitelist, allowing them to bypass the transferAllowedTimestamp. More critically, the owner can manipulate the transferAllowedTimestamp itself via setTransferAllowedTimestamp, potentially extending the lock indefinitely or unlocking tokens prematurely for all non-whitelisted users. This introduces a single point of failure and significant trust assumptions, impacting 7.3 Access Control, 7.4 Economic, and 7.8 Operations.H-01

Issue

The Ownable contract grants the owner extensive power to control token transfers. The owner can arbitrarily add/remove addresses from the whitelist using addToWhitelist and removeFromWhitelist, allowing them to bypass the transferAllowedTimestamp. More critically, the owner can manipulate the transferAllowedTimestamp itself via setTransferAllowedTimestamp, potentially extending the lock indefinitely or unlocking tokens prematurely for all non-whitelisted users. This introduces a single point of failure and significant trust assumptions, impacting 7.3 Access Control, 7.4 Economic, and 7.8 Operations.

Fix

Consider implementing a multi-signature wallet for ownership or introducing a time-lock for critical owner actions (e.g., changing transferAllowedTimestamp or managing the whitelist) to reduce the risk of a single point of compromise or malicious action. Clearly communicate the extent of owner control to token holders.

Status

Unresolved

Medium

Ambiguous and Complex setTransferAllowedTimestamp Logic

The setTransferAllowedTimestamp function contains complex conditional logic involving transferAllowedTimestamp and an ETA variable. The initial condition if (transferAllowedTimestamp > block.timestamp && ETA == 0) allows the owner to set transferAllowedTimestamp to *any* value, effectively bypassing the ETA mechanism if ETA has not been set. This could lead to unexpected behavior, such as an indefinite extension of the lock or an immediate unlock, depending on the owner's intent. The purpose and implications of the ETA variable are not immediately clear and could be simplified, impacting 7.2 Code Security and 7.4 Economic.M-01

Issue

The setTransferAllowedTimestamp function contains complex conditional logic involving transferAllowedTimestamp and an ETA variable. The initial condition if (transferAllowedTimestamp > block.timestamp && ETA == 0) allows the owner to set transferAllowedTimestamp to *any* value, effectively bypassing the ETA mechanism if ETA has not been set. This could lead to unexpected behavior, such as an indefinite extension of the lock or an immediate unlock, depending on the owner's intent. The purpose and implications of the ETA variable are not immediately clear and could be simplified, impacting 7.2 Code Security and 7.4 Economic.

Fix

Refactor the setTransferAllowedTimestamp function to simplify its logic and clearly define the rules for modifying the transfer timestamp. Ensure that the intended behavior (e.g., only allowing extensions, or only allowing reductions within certain bounds) is explicitly enforced and easily auditable. Add comprehensive NatSpec comments explaining the logic and the role of ETA.

Status

Unresolved

Low

EOA Ownership

The contract is currently owned by an Externally Owned Account (EOA). If the private key associated with this EOA is compromised, all owner-controlled functions, including whitelisting and modifying the transfer timestamp, could be maliciously exploited. This introduces a single point of failure for critical operations, impacting 7.8 Operations and 7.3 Access Control.L-01

Issue

The contract is currently owned by an Externally Owned Account (EOA). If the private key associated with this EOA is compromised, all owner-controlled functions, including whitelisting and modifying the transfer timestamp, could be maliciously exploited. This introduces a single point of failure for critical operations, impacting 7.8 Operations and 7.3 Access Control.

Fix

Transfer ownership to a multi-signature wallet (e.g., Gnosis Safe) to enhance security and require multiple approvals for critical operations. This distributes trust and reduces the risk associated with a single compromised key.

Status

Unresolved

Info

Lack of Event for ETA Changes

The ETA variable plays a role in the setTransferAllowedTimestamp logic, but there is no event emitted when ETA is set or modified. This makes it difficult for off-chain monitoring tools or users to track changes to this critical parameter, impacting 7.2 Code Security and 7.8 Operations.I-01

Issue

The ETA variable plays a role in the setTransferAllowedTimestamp logic, but there is no event emitted when ETA is set or modified. This makes it difficult for off-chain monitoring tools or users to track changes to this critical parameter, impacting 7.2 Code Security and 7.8 Operations.

Fix

Emit an event, such as ETAUpdated(uint256 oldETA, uint256 newETA), whenever the ETA variable is set or changed within the setTransferAllowedTimestamp function. This improves transparency and allows for better off-chain monitoring.

Status

Unresolved

Analysis

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

The RiceAI contract is an ERC20 token with a time-locked transfer mechanism and a whitelist. It leverages OpenZeppelin's Ownable and ERC20 standards. The primary security concerns revolve around the high degree of centralized control held by the owner over token transfers and the complexity of the setTransferAllowedTimestamp function's logic. While the core ERC20 functionality is sound, the owner's ability to manipulate transfer restrictions introduces significant trust assumptions and potential for unexpected behavior.

Technical8/10Low risk

The contract leverages OpenZeppelin's ERC20 and Ownable implementations, providing a solid foundation for token functionality and access control (7.2 Code Security). The _update override correctly enforces transfer restrictions based on a timestamp and whitelist. However, the setTransferAllowedTimestamp function contains complex conditional logic involving an ETA variable, which could lead to unexpected behavior and is difficult to audit (7.2 Code Security). There are no apparent reentrancy or integer overflow/underflow vulnerabilities.

Governance1/10High risk

The contract exhibits a high degree of centralization, with the owner possessing significant control over token transfers (7.4 Economic, 7.3 Access Control). The owner can freely add or remove addresses from the whitelist, allowing them to bypass time-lock restrictions. Furthermore, the owner can manipulate the transferAllowedTimestamp to extend the lock indefinitely or unlock tokens prematurely, creating a single point of failure and substantial trust assumptions (7.4 Economic). The ownership by an EOA further exacerbates operational risks (7.8 Operations).

Upgrades6/10Medium risk

The contract is not designed with an upgrade mechanism, meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates upgrade-related risks such as proxy misconfigurations or storage collisions. However, it also means that any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and token migration (7.7 Upgrades).

Final RecommendationWhat to do about this score

It is strongly recommended to implement a multi-signature wallet for contract ownership to mitigate the risks associated with centralized control and EOA ownership.

The logic within the setTransferAllowedTimestamp function should be simplified and clarified with comprehensive NatSpec comments to ensure predictable behavior and ease of auditing. Clearly communicate the extent of owner control and the implications of the time-lock and whitelist mechanisms to all token holders.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0xb576…98d3
Deployer0x70fa…9e6b
Badge for your website
RICE AI 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. Aug 20, 202659Medium

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

Frequently Asked Questions

What is the RICE contract address?

The RICE AI (RICE) contract on BNB Chain is 0xb5761f36fdfe2892f1b54bc8ee8babb2a1b698d3. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is RICE AI a scam?

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

Is RICE liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $450.8K.

Who holds RICE?

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

Related Audits

6 more on the recordAll audits
Slap CatSLAP · BNB Chain59MediumUnitasUP · BNB Chain59MediumniulaiBNB Chain59MediumPrometeusPROM · BNB Chain59MediumDAPPOSDOS · BNB Chain59MediumDeAgentAIAIA · BNB Chain59Medium

Would You Like a More Detailed Audit of RICE AI?

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