Quantum Audit Logo

Is Renzo Safe?

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

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

Renzo REZ
0x3b50…a6f9
Ethereum
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 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit is based on provided OpenZeppelin library code for `Votes` and a truncated `ERC20` contract. The primary 'Renzo' contract source code was not provided, limiting the scope of this audit to the foundational library components. The OpenZeppelin contracts are well-audited and generally robust, providing a secure base for governance and token functionalities. A comprehensive security assessment of the 'Renzo' protocol requires the full source code of the main contract and its interactions.

1 Low4 Informational
Volume 24h
$690.7K
Liquidity
$626.8K
Price
$0.00384
Token Age
1y
Top 10 Holders
68.8%

Security Findings

1 Low4 Info
Low

Timestamp Dependence in `delegateBySig` Expiry

L-01The `delegateBySig` function uses `block.timestamp` to check the `expiry` of a signed delegation. While standard, `block.timestamp` can be manipulated by miners within a small window (up to 900 seconds on Ethereum). This could potentially allow a miner to include a transaction with an expired signature if they are able to manipulate the timestamp within this window.
IssueThe `delegateBySig` function uses `block.timestamp` to check the `expiry` of a signed delegation. While standard, `block.timestamp` can be manipulated by miners within a small window (up to 900 seconds on Ethereum). This could potentially allow a miner to include a transaction with an expired signature if they are able to manipulate the timestamp within this window.
FixFor critical operations where precise timing is paramount, consider using a time oracle or a mechanism less susceptible to miner manipulation. For delegation signatures, the current `block.timestamp` check is generally acceptable given the typical use case, but users should be aware of this inherent EVM characteristic. Ensure `expiry` values are set with a reasonable buffer.
StatusUnresolved
Info

Incomplete Audit Scope Due to Missing Main Contract Source Code

I-01The audit was conducted on a partial set of source code, specifically OpenZeppelin's `Votes` abstract contract, related interfaces, and a truncated `ERC20` contract. The main 'Renzo' contract, which would inherit from or interact with these components, was not provided. This significantly limits the scope of the audit, as the core business logic, specific integrations, access control mechanisms, and overall architecture of the 'Renzo' protocol could not be reviewed.
IssueThe audit was conducted on a partial set of source code, specifically OpenZeppelin's `Votes` abstract contract, related interfaces, and a truncated `ERC20` contract. The main 'Renzo' contract, which would inherit from or interact with these components, was not provided. This significantly limits the scope of the audit, as the core business logic, specific integrations, access control mechanisms, and overall architecture of the 'Renzo' protocol could not be reviewed.
FixProvide the complete source code for the 'Renzo' main contract and all its dependencies to enable a comprehensive security audit. This is essential for assessing the full attack surface and identifying potential vulnerabilities within the protocol's unique implementation.
StatusUnresolved
Info

Abstract Contract Requires Concrete Implementation of `_getVotingUnits`

I-02The `Votes` abstract contract includes an abstract function `_getVotingUnits(address) internal view virtual returns (uint256)`. This function is critical for determining the amount of voting power an account holds and must be implemented by any concrete contract inheriting from `Votes`. The security and correctness of the governance system heavily depend on the accurate and secure implementation of this function.
IssueThe `Votes` abstract contract includes an abstract function `_getVotingUnits(address) internal view virtual returns (uint256)`. This function is critical for determining the amount of voting power an account holds and must be implemented by any concrete contract inheriting from `Votes`. The security and correctness of the governance system heavily depend on the accurate and secure implementation of this function.
FixEnsure that the inheriting 'Renzo' contract provides a robust and secure implementation for `_getVotingUnits`. This implementation should accurately reflect the protocol's logic for assigning voting power (e.g., based on token balance, staked amount, etc.) and be thoroughly tested for edge cases and potential manipulation.
StatusUnresolved
Info

Reliance on OpenZeppelin Libraries

I-03The provided code heavily relies on well-established and audited OpenZeppelin contracts and libraries (e.g., `Votes`, `ERC20`, `Checkpoints`, `EIP712`, `SafeCast`, `Nonces`). This is generally a strength, as these libraries undergo rigorous security reviews and are widely adopted. However, it also means the project inherits any potential, albeit unlikely, vulnerabilities discovered in these external dependencies.
IssueThe provided code heavily relies on well-established and audited OpenZeppelin contracts and libraries (e.g., `Votes`, `ERC20`, `Checkpoints`, `EIP712`, `SafeCast`, `Nonces`). This is generally a strength, as these libraries undergo rigorous security reviews and are widely adopted. However, it also means the project inherits any potential, albeit unlikely, vulnerabilities discovered in these external dependencies.
FixWhile OpenZeppelin libraries are highly secure, it is good practice to stay updated with their releases and security advisories. Ensure that the project uses the latest stable versions and that any custom code interacting with these libraries correctly adheres to their expected behavior and interfaces.
StatusUnresolved
Info

Robust `CLOCK_MODE` Consistency Check

I-04The `CLOCK_MODE` function includes a consistency check `if (clock() != Time.blockNumber()) { revert ERC6372InconsistentClock(); }`. This ensures that the `clock()` implementation, which is intended to return `Time.blockNumber()`, remains consistent with the underlying `Time` utility. This is a good practice for maintaining the integrity of the `ERC6372` clock interface.
IssueThe `CLOCK_MODE` function includes a consistency check `if (clock() != Time.blockNumber()) { revert ERC6372InconsistentClock(); }`. This ensures that the `clock()` implementation, which is intended to return `Time.blockNumber()`, remains consistent with the underlying `Time` utility. This is a good practice for maintaining the integrity of the `ERC6372` clock interface.
FixMaintain this consistency check in any overrides or custom implementations of `clock()` to ensure the `ERC6372` interface behaves as expected. This helps prevent unexpected behavior if the clock source were to diverge from `block.timestamp`.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The provided code consists of OpenZeppelin's `Votes` abstract contract and related interfaces/utilities, along with a truncated `ERC20` contract. These components are highly robust and well-audited, utilizing secure patterns like `Checkpoints` for historical data and `EIP712` for signature delegation (7.2 Code Security). The `Votes` contract provides a solid foundation for on-chain governance, including delegate functionality and vote tracking. However, the core 'Renzo' contract's implementation, which would integrate and extend these libraries, was not available for review, limiting the assessment of the overall technical architecture (7.1 Architecture).

GovernanceHigh2/10

The `Votes` contract provides essential building blocks for a decentralized governance system, enabling users to delegate voting power and track historical votes (7.5 Governance). This foundational component is designed to be secure and transparent. However, without the full 'Renzo' protocol's source code, the specific economic model, incentive mechanisms, and overall governance structure (7.4 Economic) cannot be assessed. The abstract nature of `_getVotingUnits` implies that the economic logic for determining voting power is to be defined by the inheriting contract.

UpgradesMedium6/10

The provided OpenZeppelin `Votes` and `ERC20` contracts do not inherently include upgrade mechanisms. If the 'Renzo' protocol utilizes a proxy pattern for upgradability, its implementation details (e.g., UUPS, Transparent) would need to be reviewed to assess upgrade safety (7.7 Upgrades). Without the main contract's source, it's impossible to determine if upgradeability is implemented and if it adheres to secure practices, such as proper initialization and storage slot management.

Security Checklist

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

Holder Composition

68.8% in top 10
35.1% in wallets33.7% in contracts
Effective Concentration48.5%

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

$626.8K 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 Holder82.0%
Top-3 Unlocked99.7%

Key Addresses

8 addresses
Deployer
0x40d7…b8b4
Unlocked LP Held By
0x1238…30400xbd10…40180xd728…9ca90xc117…d8790xe9e1…31610xad0f…50e20xdc92…701f

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 status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (68.8% total → 48.5% effective; 35.1% in EOAs, 33.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 82.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 99.7% (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
ADIMedium RiskTakoMedium RiskClearpool (CPOOL)Medium RiskInjective (INJ)Medium RiskLighter (LIT)Medium RiskAaveMedium Risk

Would You Like a More Detailed Audit of Renzo?

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

Get Detailed Audit