Quantum Audit Logo

Is Rhea Safe?

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

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

Rhea RHEA
0x4c06…372e
BNB Chain
Not verifiedThis 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 1d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit of the Bridge Token (TokenImplementation) contract, deployed via a BeaconProxy, identified a critical vulnerability related to the EIP-712 Permit functionality, rendering it unusable in its current proxy setup. Additionally, a high-severity issue regarding immutable ownership poses significant operational risks. The contract implements standard ERC-20 features, minting, and burning capabilities, but these are highly centralized. While the upgradeability pattern (BeaconProxy with TokenState) is generally sound, the identified issues require immediate attention to ensure the token's security and functionality.

1 Critical2 High1 Low1 Informational
Volume 24h
$1.94M
Liquidity
$468.5K
Price
$0.03311
Token Age
1y
Top 10 Holders
71.3%

Security Findings

1 Crit2 High1 Low1 Info
Critical

Incorrect EIP-712 `verifyingContract` in Proxy Context

C-01The `_buildDomainSeparator` function, used for EIP-712 signatures (e.g., `permit`), incorrectly uses `address(this)` for the `verifyingContract` parameter. In a proxy pattern, `address(this)` within the implementation contract refers to the implementation's address, not the proxy's address (0x4c06…372e). EIP-712 signatures must be verified against the address of the contract that users interact with (the proxy). This discrepancy will cause all EIP-712 signatures generated by this contract to be invalid when verified against the actual token address, rendering the `permit` functionality completely unusable.
IssueThe `_buildDomainSeparator` function, used for EIP-712 signatures (e.g., `permit`), incorrectly uses `address(this)` for the `verifyingContract` parameter. In a proxy pattern, `address(this)` within the implementation contract refers to the implementation's address, not the proxy's address (). EIP-712 signatures must be verified against the address of the contract that users interact with (the proxy). This discrepancy will cause all EIP-712 signatures generated by this contract to be invalid when verified against the actual token address, rendering the `permit` functionality completely unusable.
FixModify the `_buildDomainSeparator` function to retrieve the proxy's address for the `verifyingContract` parameter. This typically involves storing the proxy's address during initialization or using a mechanism like `ERC1967Utils.get andSetImplementation()` or similar proxy-aware context. For UUPS/Transparent proxies, `_msgSender()` or `_owner()` might be used if the proxy's address is the `owner` or a specific `_verifyingContract` variable is set during initialization.
StatusUnresolved
High

Immutable Owner with Centralized Control

H-01The contract's `owner` address is set during the `initialize` function and stored in `_state.owner`. However, there is no `transferOwnership` or `renounceOwnership` function provided. This means the owner address is permanently fixed after deployment. If the private key associated with this owner address is lost, compromised, or becomes inaccessible, critical functions like `mint`, `burn`, and `updateDetails` will become permanently unusable or exploitable, leading to a single point of failure and significant operational risk for the token.
IssueThe contract's `owner` address is set during the `initialize` function and stored in `_state.owner`. However, there is no `transferOwnership` or `renounceOwnership` function provided. This means the owner address is permanently fixed after deployment. If the private key associated with this owner address is lost, compromised, or becomes inaccessible, critical functions like `mint`, `burn`, and `updateDetails` will become permanently unusable or exploitable, leading to a single point of failure and significant operational risk for the token.
FixImplement a `transferOwnership` function, similar to OpenZeppelin's `Ownable` contract, to allow the current owner to transfer ownership to a new address. Consider also implementing `renounceOwnership` if the intention is to eventually decentralize control. For enhanced security, consider using a multi-signature wallet as the owner.
StatusUnresolved
High

Incomplete `_useNonce` Function for EIP-712 Permit

H-02The `permit` function relies on `_useNonce(owner_)` to prevent replay attacks. However, the provided source code for `_useNonce` and the associated `_nonces` state variable are truncated. Without a complete and correctly implemented nonce management system, the `permit` function is highly vulnerable to replay attacks, where a signed permit message could be submitted multiple times, leading to unauthorized transfers or approvals.
IssueThe `permit` function relies on `_useNonce(owner_)` to prevent replay attacks. However, the provided source code for `_useNonce` and the associated `_nonces` state variable are truncated. Without a complete and correctly implemented nonce management system, the `permit` function is highly vulnerable to replay attacks, where a signed permit message could be submitted multiple times, leading to unauthorized transfers or approvals.
FixProvide the complete implementation of the `_useNonce` function and ensure the `_nonces` mapping is correctly defined and managed. This typically involves incrementing a nonce for each `owner_` after a `permit` signature is used, ensuring each signature can only be consumed once. Refer to OpenZeppelin's `ERC20Permit` implementation for a robust example.
StatusUnresolved
Low

Centralized Control over Token Supply and Metadata

L-01The `mint`, `burn`, and `updateDetails` functions are restricted to the `onlyOwner` modifier. This design centralizes significant control over the token's supply (inflation/deflation) and metadata (name, symbol) to a single address. While common for bridge tokens or tokens with specific operational requirements, this concentration of power means the token's parameters can be altered without broader community consensus or a decentralized governance process.
IssueThe `mint`, `burn`, and `updateDetails` functions are restricted to the `onlyOwner` modifier. This design centralizes significant control over the token's supply (inflation/deflation) and metadata (name, symbol) to a single address. While common for bridge tokens or tokens with specific operational requirements, this concentration of power means the token's parameters can be altered without broader community consensus or a decentralized governance process.
FixAssess if this level of centralization aligns with the project's long-term vision. If decentralization is a goal, consider implementing a time-locked multi-signature wallet or a decentralized autonomous organization (DAO) for these critical functions. If centralization is intended, ensure robust security measures are in place for the owner's private key.
StatusUnresolved
Info

OpenZeppelin `Ownable` Import without Direct Usage

I-01The contract imports `@openzeppelin/contracts/access/Ownable.sol` but does not explicitly inherit from it or use its `owner()` function or `onlyOwner` modifier. Instead, it implements its own `owner()` function (returning `_state.owner`) and `onlyOwner` modifier. While functionally similar, this creates an unused import and deviates from standard OpenZeppelin patterns, potentially leading to confusion or missed features like `transferOwnership` (which is missing, as noted in H-01).
IssueThe contract imports `@openzeppelin/contracts/access/Ownable.sol` but does not explicitly inherit from it or use its `owner()` function or `onlyOwner` modifier. Instead, it implements its own `owner()` function (returning `_state.owner`) and `onlyOwner` modifier. While functionally similar, this creates an unused import and deviates from standard OpenZeppelin patterns, potentially leading to confusion or missed features like `transferOwnership` (which is missing, as noted in H-01).
FixEither fully integrate OpenZeppelin's `Ownable` by inheriting from it and using its provided functions and modifiers, or remove the unused import if a custom ownership implementation is strictly preferred. Consistency with established libraries improves readability and maintainability.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

The contract implements standard ERC-20 token functionalities including transfer, approve, mint, and burn, with appropriate checks for zero addresses and balance/allowance requirements (7.2 Code Security). It also attempts to implement EIP-712 Permit functionality. However, a critical flaw exists where `address(this)` is used for the `verifyingContract` in the EIP-712 domain separator, which is incorrect for a proxy contract and renders the Permit function non-functional (7.2 Code Security). Furthermore, the `_useNonce` function, crucial for Permit's replay protection, is truncated in the provided source, preventing a full security assessment (7.2 Code Security).

GovernanceHigh1/10

The contract's economic model is highly centralized, with an `owner` address having exclusive control over `mint`, `burn`, and `updateDetails` functions (7.4 Economic, 7.5 Governance). A significant risk is the immutability of this owner address, as there is no `transferOwnership` function, meaning the owner cannot be changed after initialization (7.3 Access Control). This creates a single point of failure; compromise or loss of the owner key would permanently disable critical token management functions (7.8 Operations).

UpgradesHigh1/10

The contract is designed as an implementation for a BeaconProxy, utilizing the `TokenState` pattern for state separation, which is a robust approach for upgradeability (7.1 Architecture, 7.7 Upgrades). The `initializer` modifier correctly prevents re-initialization of the logic contract. While the proxy pattern itself is well-chosen, the technical flaw in the EIP-712 `permit` implementation (using `address(this)` incorrectly) means that even after an upgrade, this specific functionality would remain broken unless the implementation logic is corrected (7.7 Upgrades).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

71.3% in top 10
52.6% in wallets18.7% in contracts
Effective Concentration60.1%

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

$468.5K across 2 pairs

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.8%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x7d7a…0043
Unlocked LP Held By
0x1fa9…33790xeab8…b1e20xd353…fb62

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

What Raised This Score

11 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 50% (71.3% total → 60.1% effective; 52.6% in EOAs, 18.7% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.8% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical finding(s) from audit
  • 2 High 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
MITOCritical RiskBased Token (BASED)Critical RiskGRVTCritical RiskFalcon Finance (FF)Critical RiskKGENCritical RiskBinance Brokers (BBROKERS)Critical Risk

Would You Like a More Detailed Audit of Rhea?

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

Get Detailed Audit