Quantum Audit Logo

Is Ripe DAO Governance Token Safe?

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

Ripe DAO Governance Token RIPE
0x2a0a…ddc0
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The RipeToken contract serves as the governance token for Ripe DAO, implementing the ERC-20 standard with additional administrative features. It heavily relies on an external `RipeHq` contract for critical access control over minting, blacklisting, pausing, and governance changes. While this design centralizes control, a time-locked mechanism is in place for changing the `RipeHq` controller, enhancing security for administrative updates. The contract also includes EIP-2612 permit functionality and robust checks for transfers and allowances. Key risks stem from the extensive power delegated to the `RipeHq` contract and the critical one-time initial setup process.

1 High1 Medium1 Low2 Informational
Volume 24h
$71.5K
Liquidity
$59.1K
Price
$2.4100
Token Age
1y
Top 10 Holders
99.9%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control and High Privileges of RipeHq

H-01The RipeToken contract delegates critical functions such as `mint`, `setBlacklist`, `setTokenPause`, and the ability to change the `RipeHq` controller itself to the `RipeHq` contract. This centralizes significant power, making the token highly dependent on the security and governance of the `RipeHq` contract. A compromise of `RipeHq` or its governance could lead to arbitrary minting, freezing of user funds, or halting all token transfers. This represents a single point of failure for core token functionality (7.1 Architecture, 7.3 Access Control, 7.4 Economic, 7.5 Governance).
IssueThe RipeToken contract delegates critical functions such as `mint`, `setBlacklist`, `setTokenPause`, and the ability to change the `RipeHq` controller itself to the `RipeHq` contract. This centralizes significant power, making the token highly dependent on the security and governance of the `RipeHq` contract. A compromise of `RipeHq` or its governance could lead to arbitrary minting, freezing of user funds, or halting all token transfers. This represents a single point of failure for core token functionality (7.1 Architecture, 7.3 Access Control, 7.4 Economic, 7.5 Governance).
FixConduct a thorough security audit of the `RipeHq` contract, focusing on its access control, governance mechanisms, and overall resilience. Implement robust multi-signature or decentralized governance for the `RipeHq` contract to mitigate single points of failure. Clearly document the powers of the `RipeHq` and its governance to users.
StatusUnresolved
Medium

Critical Initial Setup Dependency

M-01The `setInitialRipeHq` function is a one-time call by the `_initialGov` (stored in `tempGov`) to establish the `ripeHq` address and `hqChangeTimeLock`. If this function is not called correctly, or if the `_initialGov` address is compromised before this call, the contract could be left in an unmanaged state or controlled by an attacker. The `_isValidNewRipeHq` check during this initial setup relies on the `RipeHq` contract's `governance()` view function, which must be correctly implemented (7.8 Operations).
IssueThe `setInitialRipeHq` function is a one-time call by the `_initialGov` (stored in `tempGov`) to establish the `ripeHq` address and `hqChangeTimeLock`. If this function is not called correctly, or if the `_initialGov` address is compromised before this call, the contract could be left in an unmanaged state or controlled by an attacker. The `_isValidNewRipeHq` check during this initial setup relies on the `RipeHq` contract's `governance()` view function, which must be correctly implemented (7.8 Operations).
FixEnsure the `_initialGov` address is a highly secured multi-signature wallet or a trusted governance mechanism. Implement a meticulous deployment and initialization checklist. Consider adding an emergency 'lock' or 'pause' mechanism that can be triggered by a pre-defined trusted address if the initial setup fails or is compromised before `setInitialRipeHq` is called.
StatusUnresolved
Low

Standard ERC-20 Front-Running Risks

L-01Functions like `approve` and `permit` are susceptible to front-running attacks. An attacker can observe a pending transaction, and by submitting a transaction with a higher gas price, can either consume the allowance or set a different allowance before the legitimate transaction is confirmed. This is a common characteristic of ERC-20 tokens and not specific to this implementation (7.2 Code Security).
IssueFunctions like `approve` and `permit` are susceptible to front-running attacks. An attacker can observe a pending transaction, and by submitting a transaction with a higher gas price, can either consume the allowance or set a different allowance before the legitimate transaction is confirmed. This is a common characteristic of ERC-20 tokens and not specific to this implementation (7.2 Code Security).
FixEducate users about the risks of front-running for `approve` and `permit` functions. Advise users to be cautious when approving large allowances and to use `increaseAllowance`/`decreaseAllowance` where possible, although these also have front-running risks. For `permit`, users should be aware of the nonce mechanism preventing replay attacks.
StatusUnresolved
Info

Extensive Administrative Capabilities

I-01The contract includes robust administrative features such as blacklisting addresses, pausing transfers, and a time-locked mechanism for changing the `RipeHq` controller. While these features provide flexibility and control for managing the token, they also introduce a higher degree of centralization and potential for misuse if the controlling entities are compromised or act maliciously (7.3 Access Control, 7.5 Governance).
IssueThe contract includes robust administrative features such as blacklisting addresses, pausing transfers, and a time-locked mechanism for changing the `RipeHq` controller. While these features provide flexibility and control for managing the token, they also introduce a higher degree of centralization and potential for misuse if the controlling entities are compromised or act maliciously (7.3 Access Control, 7.5 Governance).
FixClearly document the administrative powers and the entities authorized to exercise them. Implement transparent reporting and monitoring of all administrative actions. Ensure that the governance process for these actions is robust and well-communicated to the community.
StatusUnresolved
Info

Vyper Version

I-02The contract uses Vyper version `0.4.3`. While Vyper is generally considered secure, using a relatively new version might imply less battle-testing compared to older, more established versions. It's important to ensure the compiler version is stable and free from known bugs (7.2 Code Security).
IssueThe contract uses Vyper version `0.4.3`. While Vyper is generally considered secure, using a relatively new version might imply less battle-testing compared to older, more established versions. It's important to ensure the compiler version is stable and free from known bugs (7.2 Code Security).
FixMonitor Vyper's official releases and security advisories for version `0.4.3` and any subsequent updates. Ensure that the development environment uses a stable and recommended compiler version. Consider running additional fuzzing or formal verification if not already performed.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The RipeToken contract is a Vyper-based ERC-20 implementation with additional features. It demonstrates robust internal checks for transfers, including non-zero amounts, valid recipients, and blacklist status (7.2 Code Security). The contract also incorporates EIP-2612 permit functionality with nonce management and ERC-1271 support for contract wallets. However, a significant technical risk lies in the extensive delegation of critical functions (minting, blacklisting, pausing) to the external `RipeHq` contract, making the token's security highly dependent on the `RipeHq`'s implementation and governance (7.1 Architecture, 7.3 Access Control).

GovernanceHigh1/10

The RipeToken contract exhibits a highly centralized governance and economic model, with the `RipeHq` contract holding extensive power (7.5 Governance). This includes the ability to mint new tokens, blacklist addresses (freezing funds), and pause all token transfers (7.4 Economic). While a time-locked mechanism for changing the `RipeHq` controller provides some safeguard, the overall security and economic stability of the RipeToken are directly tied to the integrity and security of the `RipeHq` contract and its controlling entities. The initial setup of the `RipeHq` address is a critical one-time operation that requires careful execution.

UpgradesHigh3/10

The RipeToken contract itself is not designed as an upgradeable proxy. However, the critical `ripeHq` controller address can be changed through a multi-step, time-locked process (`initiateHqChange`, `confirmHqChange`, `cancelHqChange`) (7.7 Upgrades). This mechanism provides a controlled way to 'upgrade' the administrative control over the token, including the ability to set a new `hqChangeTimeLock` within defined minimum and maximum bounds. This design introduces a delay for critical administrative changes, allowing time for scrutiny and intervention if necessary.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

99.9% in top 10
4.9% in wallets95.0% in contracts
Effective Concentration42.9%

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

$59.2K across 3 pairs
AerodromeWETHanalysed$59.1K99.9%Uniswap v4USDC$340.1%Uniswap v4USDC$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
0xdc4c…0e54
Unlocked LP Held By
0x3a71…e022

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (99.9% total → 42.9% effective; 4.9% in EOAs, 95.0% in contracts — moderate)
  • 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 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
VelvetHigh RiskDiemHigh RiskjesseHigh RiskUmiaHigh RiskJito Staked SOL (JITOSOL)High RiskDolphin (POD)High Risk

Would You Like a More Detailed Audit of Ripe DAO Governance Token?

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

Get Detailed Audit