Quantum Audit Logo

Is RaveDAO Safe?

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

RaveDAO RAVE
0x1aa8…cfc3
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The RaveToken contract is an Omnichain Fungible Token (OFT) built on LayerZero v2, inheriting from OpenZeppelin's Ownable. The contract implements a standard fixed-supply ERC-20 token with a burn function. The audit identified no critical or high-severity vulnerabilities. A low-severity finding relates to the centralization of control via the owner, and several informational findings highlight architectural and best-practice aspects. The contract's reliance on well-audited libraries and a simple logic contributes to its low overall risk profile.

1 Low3 Informational
Volume 24h
$102.8K
Liquidity
$162.9K
Price
$0.2516
Token Age
1y
Top 10 Holders
81.7%

Security Findings

1 Low3 Info
Low

Centralization Risk of Owner

L-01The `RaveToken` contract inherits `Ownable`, granting significant administrative control to a single owner address. This owner, even if a multisig, has the ability to configure critical LayerZero parameters (e.g., `setTrustedRemoteAddress`, `setPeer`, `setMinDstGas`, `setFeeManager`) through the inherited `OFT` functions. A compromise of the multisig or malicious intent by its signers could lead to operational issues, unexpected cross-chain transfer fees, or disruption of token bridging functionality (7.3 Access Control, 7.8 Operations).
IssueThe `RaveToken` contract inherits `Ownable`, granting significant administrative control to a single owner address. This owner, even if a multisig, has the ability to configure critical LayerZero parameters (e.g., `setTrustedRemoteAddress`, `setPeer`, `setMinDstGas`, `setFeeManager`) through the inherited `OFT` functions. A compromise of the multisig or malicious intent by its signers could lead to operational issues, unexpected cross-chain transfer fees, or disruption of token bridging functionality (7.3 Access Control, 7.8 Operations).
FixWhile a multisig mitigates single points of failure, consider implementing a timelock for critical owner-controlled functions. This would introduce a delay before changes take effect, allowing for community review or emergency intervention in case of a compromised key or malicious action. Regularly review and secure the multisig signers and their operational procedures.
StatusUnresolved
Info

Reliance on LayerZero v2 Protocol

I-01The `RaveToken` contract is built as an Omnichain Fungible Token (OFT) using the LayerZero v2 protocol. Its core cross-chain transfer functionality is entirely dependent on the security, correctness, and availability of the LayerZero endpoint, message libraries, and overall infrastructure. Any vulnerabilities, misconfigurations, or operational issues within the LayerZero protocol itself could directly impact the security and functionality of the RaveToken (7.6 External).
IssueThe `RaveToken` contract is built as an Omnichain Fungible Token (OFT) using the LayerZero v2 protocol. Its core cross-chain transfer functionality is entirely dependent on the security, correctness, and availability of the LayerZero endpoint, message libraries, and overall infrastructure. Any vulnerabilities, misconfigurations, or operational issues within the LayerZero protocol itself could directly impact the security and functionality of the RaveToken (7.6 External).
FixAcknowledge the inherent dependency risk associated with using a third-party protocol. Monitor LayerZero's security announcements, audits, and community channels. Ensure that the configured LayerZero endpoint and associated libraries are the official and most secure versions. Consider a robust incident response plan for potential LayerZero-related issues.
StatusUnresolved
Info

Fixed Supply Token Model

I-02The `RaveToken` contract mints a fixed `totalSupply` to the specified owner address during its constructor execution. There are no additional minting capabilities provided after initial deployment. This establishes a fixed supply token model, which can be beneficial for transparency and predictability of tokenomics (7.4 Economic). The `burn` function allows for a reduction in total supply by any token holder.
IssueThe `RaveToken` contract mints a fixed `totalSupply` to the specified owner address during its constructor execution. There are no additional minting capabilities provided after initial deployment. This establishes a fixed supply token model, which can be beneficial for transparency and predictability of tokenomics (7.4 Economic). The `burn` function allows for a reduction in total supply by any token holder.
FixDocument this fixed supply model clearly in the project's whitepaper or tokenomics documentation to ensure transparency for users and investors. This design choice is generally considered a positive security and economic characteristic for many token projects.
StatusUnresolved
Info

Use of Latest Solidity Version

I-03The contract utilizes `pragma solidity ^0.8.28;`, which is the latest stable version of the Solidity compiler at the time of this audit. This ensures that the contract benefits from the most recent compiler optimizations, bug fixes, and security features, including default checked arithmetic for integer operations, which prevents common overflow/underflow vulnerabilities (7.2 Code Security).
IssueThe contract utilizes `pragma solidity ^0.8.28;`, which is the latest stable version of the Solidity compiler at the time of this audit. This ensures that the contract benefits from the most recent compiler optimizations, bug fixes, and security features, including default checked arithmetic for integer operations, which prevents common overflow/underflow vulnerabilities (7.2 Code Security).
FixContinue to monitor Solidity compiler updates and security advisories. While using the latest version is beneficial, always thoroughly test contracts with the specific compiler version used for deployment to ensure consistent behavior and avoid unexpected issues from minor version changes.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The RaveToken contract exhibits good technical security (7.2 Code Security) by leveraging battle-tested OpenZeppelin `Ownable` and LayerZero v2 `OFT` libraries. The contract logic is minimal and straightforward, primarily consisting of a constructor for initial minting and a `burn` function, reducing the attack surface. The use of Solidity 0.8.28 ensures default checked arithmetic, mitigating integer overflow/underflow risks. No reentrancy vectors or complex external interactions were identified.

GovernanceHigh1/10

The economic model (7.4 Economic) of RaveToken is a fixed-supply token, with all tokens minted to the owner at deployment, and no further minting capabilities. The `burn` function allows users to reduce supply. Governance (7.5 Governance) is centralized through an `Ownable` pattern, where a multisig address acts as the owner, controlling critical LayerZero configurations such as `setTrustedRemoteAddress` and `setFeeManager`. While a multisig enhances security over a single EOA, this still represents a point of centralization (7.3 Access Control, 7.8 Operations). The contract's functionality is heavily reliant on the LayerZero v2 protocol (7.6 External), introducing dependency risk.

UpgradesLow7/10

The RaveToken contract is implemented as a standard, non-upgradeable contract. There are no proxy patterns (e.g., UUPS, Transparent) or other mechanisms for on-chain upgradeability. This design choice eliminates upgrade-related risks (7.7 Upgrades) such as proxy misconfigurations, storage collisions, or logic inconsistencies between versions. Any changes to the contract's logic would require a new deployment.

Security Checklist

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

Holder Composition

81.7% in top 10
81.7% in wallets0.0% in contracts
Effective Concentration81.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

$162.9K across 3 pairs
AerodromeUSDCanalysed$162.9K100.0%Uniswap v4ETH$80.0%AerodromeWETH$10.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x17f1…b9f5
Unlocked LP Held By
0x8815…288b

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

What Raised This Score

6 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 70% (81.7% total → 81.7% effective; 81.7% in EOAs, 0.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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
Aerodrome Finance (AERO)Medium RiskSapienMedium RiskNockchain (NOCK)Medium RiskSolana (Universal) (USOL)Medium RiskElsaMedium RiskLil Finder Guy (LFG)Medium Risk

Would You Like a More Detailed Audit of RaveDAO?

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

Get Detailed Audit