Quantum Audit Logo

Is Roll Safe?

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

Roll ROLL
0xab63…d021
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The RollToken contract is a standard ERC20 token with `permit` functionality, inheriting from OpenZeppelin's battle-tested libraries. The primary risk identified is the complete centralization of the token's initial supply to a single treasury address, posing a significant single point of failure. The technical implementation is robust due to the use of audited libraries.

1 High1 Low2 Informational
Volume 24h
$246.5K
Liquidity
$1.63M
Price
$0.1292
Token Age
7mo
Top 10 Holders
95.2%

Security Findings

1 High1 Low2 Info
High

Centralized Control of Total Supply

H-01The `RollToken` contract's constructor mints the entire `MAX_SUPPLY` (1 billion tokens) to a single `treasury` address. This design centralizes control over the entire token supply to one entity (7.3 Access Control, 7.4 Economic). If the `treasury` address is compromised, the entire token supply is at risk of theft or misuse, leading to a complete loss of value for the token holders.
IssueThe `RollToken` contract's constructor mints the entire `MAX_SUPPLY` (1 billion tokens) to a single `treasury` address. This design centralizes control over the entire token supply to one entity (7.3 Access Control, 7.4 Economic). If the `treasury` address is compromised, the entire token supply is at risk of theft or misuse, leading to a complete loss of value for the token holders.
FixImplement robust security measures for the `treasury` address. A multi-signature wallet (e.g., Gnosis Safe) with a diverse set of trusted signers is highly recommended to distribute control and reduce the single point of failure risk. Consider a phased distribution or vesting schedule for the tokens to further decentralize control over time.
StatusUnresolved
Low

Lack of Emergency Pause Mechanism

L-01The `RollToken` contract does not include any mechanism to pause token transfers or other critical functions (7.8 Operations). While a simple ERC20 token may not always require this, in the event of a critical vulnerability discovered in the token itself or a dependent protocol, the inability to pause operations could prevent mitigation of further damage or loss of funds.
IssueThe `RollToken` contract does not include any mechanism to pause token transfers or other critical functions (7.8 Operations). While a simple ERC20 token may not always require this, in the event of a critical vulnerability discovered in the token itself or a dependent protocol, the inability to pause operations could prevent mitigation of further damage or loss of funds.
FixConsider implementing a pausable mechanism (e.g., inheriting from OpenZeppelin's `Pausable` contract) controlled by a trusted entity (like the multi-sig treasury). This would provide an emergency stop-gap in unforeseen circumstances, allowing time to address critical issues. Clearly define the conditions under which the pause can be activated and deactivated.
StatusUnresolved
Info

Permit Function Front-Running Risk

I-01The `ERC20Permit` functionality allows for gasless approvals via signed messages. However, if a user's signed `permit` message is broadcast publicly (e.g., on a public mempool), a malicious actor could front-run the legitimate transaction by submitting their own transaction with the same signed message, potentially approving themselves as the `spender` before the intended `spender` (7.2 Code Security, 7.6 External). This is an inherent characteristic of the `permit` design and not a flaw in the implementation.
IssueThe `ERC20Permit` functionality allows for gasless approvals via signed messages. However, if a user's signed `permit` message is broadcast publicly (e.g., on a public mempool), a malicious actor could front-run the legitimate transaction by submitting their own transaction with the same signed message, potentially approving themselves as the `spender` before the intended `spender` (7.2 Code Security, 7.6 External). This is an inherent characteristic of the `permit` design and not a flaw in the implementation.
FixEducate users on the risks associated with public `permit` message broadcasting. Recommend using private transaction relays or services that offer front-running protection when interacting with `permit` functions. Users should be cautious about sharing signed messages in public channels.
StatusUnresolved
Info

Fixed Token Supply

I-02The `RollToken` contract has a `MAX_SUPPLY` that is entirely minted during deployment, and no further minting or burning capabilities are exposed (7.4 Economic). This results in a fixed and immutable total supply. While this provides predictability, it limits the protocol's flexibility for future economic models, such as introducing inflation/deflation mechanisms, ecosystem incentives, or adjusting supply based on demand.
IssueThe `RollToken` contract has a `MAX_SUPPLY` that is entirely minted during deployment, and no further minting or burning capabilities are exposed (7.4 Economic). This results in a fixed and immutable total supply. While this provides predictability, it limits the protocol's flexibility for future economic models, such as introducing inflation/deflation mechanisms, ecosystem incentives, or adjusting supply based on demand.
FixThis is a design choice. If future flexibility is desired, consider adding controlled minting/burning functionalities, possibly governed by a multi-signature wallet or a decentralized autonomous organization (DAO). If a fixed supply is the intended design, ensure this is clearly communicated to the community.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The RollToken contract is a straightforward ERC20 implementation, leveraging OpenZeppelin's robust `ERC20` and `ERC20Permit` libraries (7.1 Architecture). This approach significantly reduces the likelihood of common technical vulnerabilities such as reentrancy or integer overflows (7.2 Code Security). The code is minimal and well-structured, demonstrating good practices. No complex custom logic was introduced beyond the initial minting, contributing to its technical simplicity and security.

GovernanceHigh1/10

The economic model of the RollToken involves minting the entire `MAX_SUPPLY` to a single `treasury` address during deployment (7.4 Economic). This design choice centralizes control over the token's initial distribution and liquidity, creating a significant single point of failure. While simple, it introduces a high dependency on the security of the `treasury` address, as its compromise would jeopardize the entire token supply. There are no governance mechanisms implemented within this contract (7.5 Governance).

UpgradesMedium6/10

The RollToken contract is implemented as a standard, non-upgradeable ERC20 token. This design choice eliminates the complexities and potential risks associated with upgrade mechanisms, such as proxy pattern vulnerabilities or storage collisions (7.7 Upgrades). The immutability of the contract ensures that its logic cannot be altered post-deployment, providing a predictable and stable environment for users.

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

95.2% in top 10
1.7% in wallets93.5% in contracts
Effective Concentration39.1%

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

$1.65M across 5 pairs
Uniswap v4USDCanalysed$1.63M99.1%Uniswap v3USDC$13.5K0.8%PancakeswapUSDC$1.6K0.1%PancakeswapWETH$00.0%

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 Holder93.8%
Top-3 Unlocked100.0%

Key Addresses

6 addresses
Deployer
0xbfd7…0c51
Unlocked LP Held By
0xf949…02980xd860…84800x4835…1de10x4e5b…9a240x5a01…a692

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 status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (95.2% total → 39.1% effective; 1.7% in EOAs, 93.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 93.8% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 High 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

6 more on the record
Aave Token (AAVE)Medium RiskBaseUncMedium RiskOpenGradient (OPG)Medium RiskZoraMedium RiskHorizen (ZEN)Medium RiskSquid (QUID)Medium Risk

Would You Like a More Detailed Audit of Roll?

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

Get Detailed Audit