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.
On-chain security analysis — is it a scam or legit?
Is RIZE Safe?
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 →The RizeToken contract is an ERC20 token implementation leveraging OpenZeppelin standards for flash minting, permits, and a capped supply.
Read the full analysis- Ownership status UNKNOWN
- Mintable supply, but capped at 1.1%/year
- Top-10 concentration > 50%
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- Liquidity < $50k
- LP top1 unlocked holder = 62.4%
- LP top3 unlocked holders = 96.1%
- 1 High finding(s) from audit
- 2 Medium finding(s) from audit
- 1 Low finding(s) from audit
Exact factors
- 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking66.7%
- Walletsanonymous holders, free to sell23.5%
- Everyone elsethe rest of the supply9.8%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xfa2b…52bb0x745b…d37f0x1318…41130xd9a2…3a880x0500…91deNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized Control Over Token Supply (Mint/Burn)
The 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.H-01
Issue
The 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.
Fix
Implement 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.
Status
Unresolved
MediumCentralized Control Over Flash Loan Fees
The 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.M-01
Issue
The 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.
Fix
Implement 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.
Status
Unresolved
MediumCritical Reliance on External Access Control Contract
The 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.M-02
Issue
The 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.
Fix
Conduct 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.
Status
Unresolved
LowNon-Upgradeable Contract Design
The 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.L-01
Issue
The 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.
Fix
Acknowledge 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.
Status
Unresolved
InfoEIP-3009 Authorization Complexity and User Risk
The 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.I-01
Issue
The 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.
Fix
Provide 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.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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.
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.
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).
Prioritize securing the privileged roles (onlyBridge, onlyCommittee) by implementing robust multi-signature controls and potentially time-locks for critical operations like large mints/burns or significant fee changes.
Conduct a comprehensive audit of the external AccessRestricted and IAccessList contracts to ensure their security, immutability, and proper configuration, as the RizeToken's security is directly tied to these dependencies. Provide clear documentation and user education regarding the EIP-3009 authorization mechanism to mitigate user-side risks.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202670High
- Aug 15, 202657Medium
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the RIZE contract address?
The RIZE contract on Base is 0x9818b6c09f5ecc843060927e8587c427c7c93583. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is RIZE a scam?
Quantum Audit's risk score for RIZE is 70/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is RIZE liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $24.4K.
Who holds RIZE?
As of Sep 4, 2026, the 10 largest holders own 90.2% of the supply. The Holders section on this page shows who they are by holder type.
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 Is this your token? Publish your own audit on this page