Quantum Audit Logo
Launch App

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

Is River Safe?

RIVERBNB 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/10Governance2/10Upgrades7/10Checks passed5 of 7Findings2 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The River token contract is an Omnichain Fungible Token (OFT) built on LayerZero, inheriting from OpenZeppelin's Ownable.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 95.2%
  • LP top3 unlocked holders = 97.6%
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
71.8%Contracts17.5%Wallets10.7%Everyone else
71.8%Contracts17.5%10.7%
ContractsWalletsEveryone elseBubble area = share of supply
89.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking71.8%
  • Walletsanonymous holders, free to sell17.5%
  • Everyone elsethe rest of the supply10.7%
Effective concentrationwhat the score reads46.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$183.3K across 7 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$160.8KShare of depth87.7%
Top-1 Unlocked Holder95.2%
Top-3 Unlocked97.6%
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.

Security Findings

2 High1 Medium1 Low1 Info
High

Centralized and Irreversible Initial Token Distribution

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

Issue

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

Fix

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

Status

Unresolved

High

Potential Denial of Service (DoS) in initialize Function

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

Issue

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

Fix

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

Status

Unresolved

Medium

Immutability of isNativeChain Flag

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

Issue

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

Fix

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

Status

Unresolved

Low

Lack of Event Emission for Critical Initialization

The 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)L-01

Issue

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

Fix

Add an event, such as `Initialized(uint256 totalMintedSupply, uint256 numRecipients, bytes32 distributionHash), to be emitted at the end of the initialize` function.

Status

Unresolved

Info

External Dependency on LayerZero Security

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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

Governance2/10High risk

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

Upgrades7/10Low risk

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

Final RecommendationWhat to do about this score

Prioritize the implementation of a robust and secure initial token distribution mechanism, potentially involving batching or a multi-stage process to mitigate DoS and irreversible error risks.

Enhance transparency by emitting events for critical operations like initialization. Thoroughly review and document the rationale for immutable design choices, such as the isNativeChain flag. Maintain continuous monitoring of LayerZero's security posture due to the inherent dependency on its cross-chain infrastructure.

Contract & Record

1 audit on record
TypeSolidity 0.8.26
NetworkBNB Chain
Token age11mo
Contract0xda7a…52b3
Deployer0x1fa6…555e
Badge for your website
River 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 30, 202644Medium

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

Related Audits

6 more on the recordAll audits
吉祥马BNB Chain44MediumARAI TokenAA · BNB Chain44MediumCZBURNCBURN · BNB Chain44MediumGeniusBNB Chain44MediumKavaBNB Chain44MediumChainLink TokenLINK · BNB Chain44Medium

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