On-chain security analysis — is it a scam or legit?
The RollToken contract is a standard ERC20 token with permit functionality, inheriting from OpenZeppelin's battle-tested libraries.
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
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
The 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.
0xf949…02980xd860…84800x4835…1de10x4e5b…9a240x5a01…a692No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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.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.
Implement 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.
Unresolved
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.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.
Consider 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.
Unresolved
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.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.
Educate 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.
Unresolved
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.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.
This 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.
Unresolved
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.
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.
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).
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.
It is strongly recommended to implement robust security measures for the treasury address, such as a multi-signature wallet (e.g., Gnosis Safe) with a diverse set of signers, to mitigate the high centralization risk associated with holding the entire token supply.
Consider the long-term implications of a fixed supply and the absence of a pause mechanism for future operational flexibility.
For permit functionality, educate users on best practices to avoid front-running, such as using private transaction relays.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
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
