Quantum Audit Logo

Is River Safe?

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

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

River RIVER
0xda7a…52b3
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The River token contract is an Omnichain Fungible Token (OFT) built on LayerZero, inheriting from OpenZeppelin's Ownable. Its primary function is a one-time, owner-controlled initialization process to mint and distribute the entire token supply. While the initialization includes robust input validation, significant risks are identified concerning the centralized and irreversible nature of this critical distribution, potential denial of service for large recipient lists, and the inherent dependencies on LayerZero's security. The contract is not upgradeable, fixing its logic and dependencies.

2 High1 Medium1 Low1 Informational
Volume 24h
$158.6K
Liquidity
$160.8K
Price
$1.2800
Token Age
11mo
Top 10 Holders
89.3%

Security Findings

2 High1 Med1 Low1 Info
High

Centralized and Irreversible Initial Token Distribution

H-01The `initialize` function, callable only once by the contract owner, is responsible for minting the entire `TOTAL_SUPPLY` and distributing it to specified recipients. This process is irreversible. Any error in the `_recipients` or `_amounts` arrays during this single, critical call would permanently misallocate the token supply, with no on-chain mechanism to correct it. This places a high degree of trust in the owner's operational security and data accuracy. (7.3 Access Control, 7.4 Economic, 7.8 Operations)
IssueThe `initialize` function, callable only once by the contract owner, is responsible for minting the entire `TOTAL_SUPPLY` and distributing it to specified recipients. This process is irreversible. Any error in the `_recipients` or `_amounts` arrays during this single, critical call would permanently misallocate the token supply, with no on-chain mechanism to correct it. This places a high degree of trust in the owner's operational security and data accuracy. (7.3 Access Control, 7.4 Economic, 7.8 Operations)
FixImplement a multi-stage distribution process or a timelock for the `initialize` function to allow for review and potential cancellation before final execution. Consider a mechanism for a limited, owner-controlled re-distribution or burn in case of minor errors, though this adds complexity and centralization. Ensure rigorous off-chain verification of recipient lists and amounts.
StatusUnresolved
High

Potential Denial of Service (DoS) in `initialize` Function

H-02The `initialize` function iterates through `_recipients` and `_amounts` arrays to mint tokens. If the number of recipients is excessively large, the gas cost of this transaction could exceed the block gas limit, preventing the successful execution of the `initialize` function. This would effectively block the initial distribution of the token, rendering the contract unusable. (7.2 Code Security, 7.8 Operations)
IssueThe `initialize` function iterates through `_recipients` and `_amounts` arrays to mint tokens. If the number of recipients is excessively large, the gas cost of this transaction could exceed the block gas limit, preventing the successful execution of the `initialize` function. This would effectively block the initial distribution of the token, rendering the contract unusable. (7.2 Code Security, 7.8 Operations)
FixImplement a batched distribution mechanism for the `initialize` function, allowing the owner to distribute tokens to recipients in multiple transactions, each within the block gas limit. Alternatively, limit the maximum number of recipients in a single call or use a Merkle tree for claiming.
StatusUnresolved
Medium

Immutability of `isNativeChain` Flag

M-01The `isNativeChain` flag, which determines if the `initialize` function can be called, is set in the constructor and cannot be modified thereafter. While this design choice ensures a fixed role for the contract (native vs. non-native chain), it removes flexibility. If the project's strategy regarding the native chain changes, or if the initial deployment decision was incorrect, a new contract deployment would be required, leading to significant operational overhead. (7.1 Architecture, 7.8 Operations)
IssueThe `isNativeChain` flag, which determines if the `initialize` function can be called, is set in the constructor and cannot be modified thereafter. While this design choice ensures a fixed role for the contract (native vs. non-native chain), it removes flexibility. If the project's strategy regarding the native chain changes, or if the initial deployment decision was incorrect, a new contract deployment would be required, leading to significant operational overhead. (7.1 Architecture, 7.8 Operations)
FixIf future flexibility is desired, consider making the `isNativeChain` flag configurable by the owner (e.g., via an `onlyOwner` function) before initialization, or at least provide a clear rationale for its immutability in documentation. Given the current design, ensure the initial deployment strategy is thoroughly vetted.
StatusUnresolved
Low

Lack of Event Emission for Critical Initialization

L-01The `initialize` function performs the critical, one-time action of minting the entire token supply and distributing it. However, it does not emit an event upon successful completion. Emitting an event with details like the total supply minted, the number of recipients, and a hash of the distribution parameters would provide an on-chain, easily auditable record of this crucial operation, enhancing transparency and traceability. (7.2 Code Security, 7.8 Operations)
IssueThe `initialize` function performs the critical, one-time action of minting the entire token supply and distributing it. However, it does not emit an event upon successful completion. Emitting an event with details like the total supply minted, the number of recipients, and a hash of the distribution parameters would provide an on-chain, easily auditable record of this crucial operation, enhancing transparency and traceability. (7.2 Code Security, 7.8 Operations)
FixAdd an event, such as `Initialized(uint256 totalMintedSupply, uint256 numRecipients, bytes32 distributionHash)`, to be emitted at the end of the `initialize` function.
StatusUnresolved
Info

External Dependency on LayerZero Security

I-01The `River` token inherits from LayerZero's OFT (Omnichain Fungible Token) contract, making its cross-chain functionality entirely dependent on the security and operational integrity of the LayerZero protocol and its endpoints. Any vulnerability or compromise within the LayerZero infrastructure could directly impact the security, transferability, and overall functionality of the `River` token across different chains. (7.6 External)
IssueThe `River` token inherits from LayerZero's OFT (Omnichain Fungible Token) contract, making its cross-chain functionality entirely dependent on the security and operational integrity of the LayerZero protocol and its endpoints. Any vulnerability or compromise within the LayerZero infrastructure could directly impact the security, transferability, and overall functionality of the `River` token across different chains. (7.6 External)
FixProject teams should continuously monitor LayerZero's security announcements, audits, and operational status. Implement robust monitoring for LayerZero-related transactions and potential anomalies. Understand the risks associated with cross-chain bridging solutions.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good code quality, utilizing standard and audited libraries from OpenZeppelin and LayerZero. The `initialize` function includes comprehensive checks for zero addresses, zero amounts, array length mismatches, and ensures the total minted amount matches the `TOTAL_SUPPLY` (7.2 Code Security). However, a significant technical risk is the potential for a Denial of Service (DoS) in the `initialize` function if the number of recipients is too large, exceeding block gas limits (7.2 Code Security). Additionally, the critical `initialize` function lacks event emission for transparency (7.2 Code Security).

GovernanceHigh2/10

The economic model is a fixed-supply token with a single, owner-controlled initial distribution. The use of a multisig for ownership (as per prefilled data) is a strong security practice, mitigating single points of failure for administrative actions (7.5 Governance). However, the entire token supply is minted and distributed in a single, irreversible `initialize` call, posing a high economic risk if errors occur in the recipient list or amounts (7.4 Economic). The contract's cross-chain functionality relies entirely on LayerZero, introducing external bridge-related economic risks (7.6 External).

UpgradesLow7/10

The contract is not designed to be upgradeable, which simplifies its architecture and eliminates risks associated with upgrade mechanisms like proxy patterns (7.7 Upgrades). This immutability ensures that the contract's logic, once deployed, cannot be altered. However, it also means that any discovered bugs or desired feature changes would necessitate a complete redeployment and migration, which can be a complex and costly operational task (7.8 Operations).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

89.3% in top 10
17.5% in wallets71.8% in contracts
Effective Concentration46.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

$183.3K across 7 pairs
Pancakeswap v3USDTanalysed$160.8K87.7%UniswapUSDT$16.3K8.9%UniswapUSDT$3.6K2.0%Pancakeswap v3USDT$2.1K1.1%Pancakeswap v3USDT$3660.2%Pancakeswap v3WBNB$250.0%
Show 1 more pairShow less
Pancakeswap v2WBNB$30.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 Holder95.2%
Top-3 Unlocked97.6%

Key Addresses

11 addresses
Deployer
0x1fa6…555e
Unlocked LP Held By
0x00b0…c7660x3262…f28a0x0c5f…52350xffc6…58010xdf1d…444d0x1623…a6fa0x556b…d59e0x966d…e41a0x34a1…0ee70xf7f2…ce6b

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 — Multisig (3-of-4)
  • Top-10 concentration > 30% (89.3% total → 46.2% effective; 17.5% in EOAs, 71.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 95.2% (independent LP — depth risk, pool = 88% of DEX liquidity)
  • LP top3 unlocked holders = 97.6% (independent LP — depth risk, pool = 88% of DEX liquidity)
  • 2 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
吉祥马Medium RiskARAI Token (AA)Medium RiskCZBURN (CBURN)Medium RiskGeniusMedium RiskGUAMedium RiskTrenchesStarterPack (战壕入门包)Medium Risk

Would You Like a More Detailed Audit of River?

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

Get Detailed Audit