Quantum Audit Logo

Is RICE AI Safe?

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

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

RICE AI RICE
0xb576…98d3
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$18.5K
Liquidity
$435.8K
Price
$0.005118
Token Age
1y
Top 10 Holders
79.3%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control Over Token Transfers

H-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Medium

Ambiguous and Complex `setTransferAllowedTimestamp` Logic

M-01The `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.
IssueThe `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.
FixRefactor 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`.
StatusUnresolved
Low

EOA Ownership

L-01The 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.
IssueThe 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.
FixTransfer 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.
StatusUnresolved
Info

Lack of Event for `ETA` Changes

I-01The `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.
IssueThe `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.
FixEmit 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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

UpgradesMedium6/10

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

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

79.3% in top 10
6.7% in wallets72.6% in contracts
Effective Concentration35.7%

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

$450.8K across 8 pairs
Pancakeswap v3WBNBanalysed$435.8K96.7%Pancakeswap v3WBNB$10.1K2.2%UniswapUSDT$3.1K0.7%Pancakeswap v2SKOL$1.6K0.4%Pancakeswap v3WBNB$1060.0%Pancakeswap v3USDC$170.0%
Show 1 more pairShow less
Pancakeswap v2USDT$00.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 Holder99.3%
Top-3 Unlocked100.0%

Key Addresses

5 addresses
Deployer
0x70fa…9e6b
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.

What Raised This Score

8 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

Related Audits

6 more on the record
Slap Cat (SLAP)High RiskUnitas (UP)High RiskniulaiHigh RiskPrometeus (PROM)High RiskDAPPOS (DOS)High RiskDeAgentAI (AIA)High Risk

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