Quantum Audit Logo

Is RIZE Safe?

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

RIZE RIZE
0x9818…3583
Base Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

The RizeToken contract is an ERC20 token implementation leveraging OpenZeppelin standards for flash minting, permits, and a capped supply. It also integrates EIP-3009 for signed authorizations and a custom AccessRestricted contract for role-based access control. The contract exhibits good adherence to established patterns but introduces centralized control points for token supply and flash loan fees, alongside a critical dependency on an external access control contract. These factors contribute to a Medium overall risk level.

1 High2 Medium1 Low1 Informational
Volume 24h
$24.9K
Liquidity
$24.4K
Price
$0.004036
Token Age
1y
Top 10 Holders
90.2%

Security Findings

High

Centralized Control Over Token Supply (Mint/Burn)

H-01The `mint` and `burn` functions are restricted to the `onlyBridge` role. This grants significant power to the entity controlling the bridge, allowing them to increase or decrease the token supply. While the token has a cap, a compromised bridge could lead to unauthorized inflation up to the cap or deflation, impacting tokenomics and user trust.
IssueThe `mint` and `burn` functions are restricted to the `onlyBridge` role. This grants significant power to the entity controlling the bridge, allowing them to increase or decrease the token supply. While the token has a cap, a compromised bridge could lead to unauthorized inflation up to the cap or deflation, impacting tokenomics and user trust.
FixImplement a multi-signature wallet or a robust governance mechanism for the `onlyBridge` role to reduce the risk of a single point of failure. Consider time-locks for large mint/burn operations to allow for community review and reaction.
StatusUnresolved
Medium

Centralized Control Over Flash Loan Fees

M-01The `setFeesBps` function, which controls the flash loan fees, is restricted to the `onlyCommittee` role. A single committee member or a small group could unilaterally change the fees, potentially setting them to zero (making flash loans free) or to the maximum (100%). While a 100% fee is checked, setting fees to 0 could enable certain types of economic attacks on integrated protocols that rely on flash loan costs.
IssueThe `setFeesBps` function, which controls the flash loan fees, is restricted to the `onlyCommittee` role. A single committee member or a small group could unilaterally change the fees, potentially setting them to zero (making flash loans free) or to the maximum (100%). While a 100% fee is checked, setting fees to 0 could enable certain types of economic attacks on integrated protocols that rely on flash loan costs.
FixImplement a multi-signature wallet or a governance proposal system for the `onlyCommittee` role. Consider adding a time-lock for fee changes to allow for community review and reaction.
StatusUnresolved
Medium

Critical Reliance on External Access Control Contract

M-02The `RizeToken` contract heavily relies on an external `AccessRestricted` contract (and its `IAccessList` interface) for defining privileged roles (`onlyCommittee`, `onlyBridge`) and determining the `_flashFeeReceiver`. The `accessList` address is set immutably in the constructor. If the `AccessRestricted` contract is compromised, misconfigured, or if `IAccessList.getTreasury()` returns a malicious address, critical functions could be abused, or flash loan fees could be misdirected. The security of `RizeToken` is directly tied to the security and immutability of this external dependency.
IssueThe `RizeToken` contract heavily relies on an external `AccessRestricted` contract (and its `IAccessList` interface) for defining privileged roles (`onlyCommittee`, `onlyBridge`) and determining the `_flashFeeReceiver`. The `accessList` address is set immutably in the constructor. If the `AccessRestricted` contract is compromised, misconfigured, or if `IAccessList.getTreasury()` returns a malicious address, critical functions could be abused, or flash loan fees could be misdirected. The security of `RizeToken` is directly tied to the security and immutability of this external dependency.
FixConduct a thorough audit of the `AccessRestricted` and `IAccessList` contracts. Ensure the `accessList` address provided in the constructor is correct and points to a secure, immutable, and well-governed contract. Implement robust monitoring for the `AccessRestricted` contract's state.
StatusUnresolved
Low

Non-Upgradeable Contract Design

L-01The `RizeToken` contract is implemented as a standard, non-upgradeable contract. This design choice means that once deployed, its logic cannot be modified. While this removes upgrade-related risks, it also prevents bug fixes, security patches, or feature enhancements without a complete redeployment and migration of user funds, which can be a complex and risky process.
IssueThe `RizeToken` contract is implemented as a standard, non-upgradeable contract. This design choice means that once deployed, its logic cannot be modified. While this removes upgrade-related risks, it also prevents bug fixes, security patches, or feature enhancements without a complete redeployment and migration of user funds, which can be a complex and risky process.
FixAcknowledge the implications of a non-upgradeable design. Ensure the contract is thoroughly tested and audited before deployment, as any discovered vulnerabilities will be permanent. If future flexibility is desired, consider a proxy-based upgradeable architecture for future versions or related contracts.
StatusUnresolved
Info

EIP-3009 Authorization Complexity and User Risk

I-01The contract implements EIP-3009 for `transferWithAuthorization`, `receiveWithAuthorization`, and `cancelAuthorization`. This allows users to authorize token transfers off-chain via signed messages, which can be executed by anyone. While this offers gasless transactions, it introduces additional complexity for users and a new vector for potential fund loss if private keys are compromised or if users are tricked into signing malicious authorizations. The `nonce` mechanism prevents replay, but user education is crucial.
IssueThe contract implements EIP-3009 for `transferWithAuthorization`, `receiveWithAuthorization`, and `cancelAuthorization`. This allows users to authorize token transfers off-chain via signed messages, which can be executed by anyone. While this offers gasless transactions, it introduces additional complexity for users and a new vector for potential fund loss if private keys are compromised or if users are tricked into signing malicious authorizations. The `nonce` mechanism prevents replay, but user education is crucial.
FixProvide clear documentation and user education on the secure use of EIP-3009 authorizations, emphasizing the importance of protecting private keys and carefully reviewing signed messages. Implement robust front-end safeguards to prevent users from signing unintended transactions.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The RizeToken contract utilizes well-audited OpenZeppelin libraries for its core ERC20 functionality, including flash minting, permits, and a capped supply (7.1 Architecture, 7.2 Code Security). The EIP-3009 implementation for signed transfers includes nonce management to prevent replay attacks. However, a significant technical risk stems from the contract's reliance on an external `AccessRestricted` contract for critical role management and treasury address resolution (7.6 External). The security of `RizeToken` is directly dependent on the integrity and immutability of this external dependency.

GovernanceHigh1/10

The contract implements a capped token supply, which is a positive economic control (7.4 Economic). Flash loan fees are configurable, allowing for dynamic adjustments. However, the `onlyBridge` role has centralized control over `mint` and `burn` functions, enabling significant manipulation of the token supply up to the cap (7.3 Access Control). Similarly, the `onlyCommittee` role can unilaterally adjust flash loan fees, which could impact the protocol's economics (7.5 Governance). These centralized controls represent significant economic and governance risks if the privileged roles are compromised.

UpgradesMedium5/10

The RizeToken contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates risks associated with upgrade mechanisms, such as proxy implementation bugs or improper upgrade paths. However, it also means that any discovered vulnerabilities or desired feature enhancements would necessitate a complete redeployment and migration, which can be a complex and costly operational undertaking (7.8 Operations).

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

23.5% in wallets66.7% in contracts
Effective Concentration50.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

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 Holder62.4%
Top-3 Unlocked96.1%

Key Addresses

Deployer
0x1829…a885
Unlocked LP Held By
0xfa2b…52bb0x745b…d37f0x1318…41130xd9a2…3a880x0500…91de

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply, but capped at 1.1%/year
  • Top-10 concentration > 50% (90.2% total → 50.2% effective; 23.5% in EOAs, 66.7% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($24,395 across 2 pairs — thin market)
  • LP top1 unlocked holder = 62.4% (independent LP — depth risk)
  • LP top3 unlocked holders = 96.1% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 2 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

XMAQUINA (DEUS)Critical RiskTownsCritical RiskICPCritical RiskEthy AI by Virtuals (ETHY)High RiskGAME by Virtuals (GAME)Critical RiskMetronome Synth USD (MSUSD)High Risk

Would You Like a More Detailed Audit of RIZE?

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

Get Detailed Audit