Quantum Audit Logo
Launch App

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

Is RIZE Safe?

Base
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 →
Last checked Sep 4, 2026 · 1 audit on record
SummaryAI Copilot

The RizeToken contract is an ERC20 token implementation leveraging OpenZeppelin standards for flash minting, permits, and a capped supply.

Read the full analysis
What raised the score
  • 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
66.7%Contracts23.5%Wallets9.8%Everyone else
66.7%Contracts23.5%Wallets9.8%
ContractsWalletsEveryone elseBubble area = share of supply
90.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking66.7%
  • Walletsanonymous holders, free to sell23.5%
  • Everyone elsethe rest of the supply9.8%
Effective concentrationwhat the score reads50.2%
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 4$24.4K across 2 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$24.4KShare of depth100.0%
Top-1 Unlocked Holder62.4%
Top-3 Unlocked96.1%
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.

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized 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

Medium

Centralized 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

Medium

Critical 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

Low

Non-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

Info

EIP-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 4
Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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.

Governance1/10High risk

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.

Upgrades5/10Medium risk

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).

Final RecommendationWhat to do about this score

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

1 audit on record
TypeRizeToken
NetworkBase
Token age1y
Contract0x9818…3583
Deployer0x1829…a885
Badge for your website
RIZE security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202670High
  2. 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