Quantum Audit Logo

Is R2 Safe?

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

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

R2 R2
0x223a…9222
BNB Chain
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The R2 contract is an ERC20 token with ERC20Permit functionality, inheriting from OpenZeppelin's Ownable2Step for robust access control. The contract includes owner-only functions for emergency recovery of BNB and other ERC20 tokens. Initial token supply is minted to the deployer. The contract generally demonstrates good security practices through its use of battle-tested OpenZeppelin libraries and clear design choices.

2 Low2 Informational
Volume 24h
$1.27M
Liquidity
$171.8K
Price
$0.008828
Token Age
7d
Top 10 Holders
93.8%

Security Findings

2 Low2 Info
Low

Centralized Control of Recovery Functions

L-01The `recoverBNB()` and `recoverTokens()` functions are restricted to the contract owner. This grants the owner (a 3/5 multisig) the sole authority to extract any BNB or ERC20 tokens sent to the contract. While this is a common and often desired emergency feature, it represents a centralization point where the security of these assets relies entirely on the owner's integrity and security practices.
IssueThe `recoverBNB()` and `recoverTokens()` functions are restricted to the contract owner. This grants the owner (a 3/5 multisig) the sole authority to extract any BNB or ERC20 tokens sent to the contract. While this is a common and often desired emergency feature, it represents a centralization point where the security of these assets relies entirely on the owner's integrity and security practices.
FixEnsure the multisig wallet controlling the owner address is highly secure, with robust key management and operational procedures. Regular audits of the multisig's signers and transaction policies are recommended. This is a design choice, and the current multisig setup mitigates the risk significantly.
StatusUnresolved
Low

Potential Gas Limit Exceedance in `recoverTokens`

L-02The `recoverTokens` function iterates through arrays of `tokens` and `amounts`. If the number of tokens to recover in a single transaction is excessively large, the transaction might exceed the block gas limit, preventing the owner from recovering all desired tokens in one call. This could lead to operational inconvenience for the owner during an emergency.
IssueThe `recoverTokens` function iterates through arrays of `tokens` and `amounts`. If the number of tokens to recover in a single transaction is excessively large, the transaction might exceed the block gas limit, preventing the owner from recovering all desired tokens in one call. This could lead to operational inconvenience for the owner during an emergency.
FixWhile this is an emergency function, consider the practical implications. If a very large number of different tokens need to be recovered, the owner may need to split the recovery into multiple transactions with smaller array sizes. Document this operational consideration for the owner.
StatusUnresolved
Info

Initial Token Mint to Deployer

I-01In the constructor, 1,000,000,000 tokens (1 billion) are minted directly to `msg.sender` (the contract deployer). This establishes the initial total supply and its distribution. This is a standard practice for many ERC20 token deployments.
IssueIn the constructor, 1,000,000,000 tokens (1 billion) are minted directly to `msg.sender` (the contract deployer). This establishes the initial total supply and its distribution. This is a standard practice for many ERC20 token deployments.
FixEnsure that the initial distribution strategy is clearly communicated to the community and stakeholders. Transparency regarding the initial token holder and any subsequent distribution plans is crucial for trust and understanding of the token's economics.
StatusUnresolved
Info

Explicit BNB Rejection in `receive()`

I-02The `receive()` external payable function explicitly reverts with the message 'BNB not accepted'. This design choice prevents any direct transfers of native blockchain currency (BNB on BSC) to the contract address, ensuring that the contract does not hold unintended BNB.
IssueThe `receive()` external payable function explicitly reverts with the message 'BNB not accepted'. This design choice prevents any direct transfers of native blockchain currency (BNB on BSC) to the contract address, ensuring that the contract does not hold unintended BNB.
FixThis is a clear and intentional design choice. No specific recommendation is needed other than to ensure this behavior aligns with the project's requirements and user expectations. Users attempting to send BNB directly to the contract will have their transactions reverted.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes well-audited OpenZeppelin libraries for ERC20, ERC20Permit, and Ownable2Step, contributing to a strong technical foundation (7.2 Code Security). Solidity version 0.8.26 mitigates integer overflow/underflow risks. Access control for critical functions like `recoverBNB` and `recoverTokens` is properly enforced via `onlyOwner` (7.3 Access Control). The `receive()` function explicitly reverts, preventing unintended BNB deposits.

GovernanceMedium4/10

The contract's economic model involves an initial mint of 1 billion tokens to the deployer (7.4 Economic). The owner, a 3/5 multisig, holds significant power, including the ability to recover any BNB or ERC20 tokens accidentally sent to the contract (7.5 Governance). While centralized, this is a common and often necessary feature for emergency asset management, and the multisig setup enhances security against single points of failure.

UpgradesLow7/10

The R2 contract is implemented as a standalone token and does not utilize a proxy pattern for upgradeability (7.7 Upgrades). This design choice eliminates upgrade-related risks such as proxy misconfigurations or logic contract vulnerabilities introduced during upgrades. Any future changes would require a new deployment and migration.

Security Checklist

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

Holder Composition

93.8% in top 10
3.9% in wallets89.9% in contracts
Effective Concentration39.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

$197.2K across 2 pairs
Pancakeswap v3USDTanalysed$171.8K87.1%UniswapUSDT$25.4K12.9%

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

3 addresses
Deployer
0x97bd…3a3b
Unlocked LP Held By
0x9491…166b0x55d8…ebc3

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

What Raised This Score

7 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 30% (93.8% total → 39.9% effective; 3.9% in EOAs, 89.9% 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, pool = 87% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 87% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 2 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
Bitway Token (BTW)Medium RiskMarsCoinMedium RiskCZ'S DOG (BROCCOLI)Medium RiskCharacterX (CAI)Medium Risk永生果蝇 (果蝇)Medium RiskFetch (FET)Medium Risk

Would You Like a More Detailed Audit of R2?

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

Get Detailed Audit