Quantum Audit Logo

Is Rollbit Coin Safe?

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

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

Rollbit Coin RLB
0x046e…3f3d
Ethereum
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? → Critical Risk
Executive SummaryAI Copilot

This audit covers the OpenZeppelin TransparentUpgradeableProxy contract. The contract itself is a well-vetted standard, providing robust upgradeability. However, the security posture is significantly impacted by the configuration of its admin, which is an externally owned account (EOA). This centralization introduces a critical single point of failure. Additionally, the absence of a timelock for upgrades and the inherent risk of storage collisions in the implementation contract are noted. The overall risk is High due to the critical nature of the EOA admin.

1 Critical1 Medium1 Low2 Informational
Volume 24h
$432.3K
Liquidity
$2.58M
Price
$0.07921
Token Age
3y
Top 10 Holders
80.2%

Security Findings

1 Crit1 Med1 Low2 Info
Critical

Centralized Upgrade Control via EOA Admin

C-01The proxy's admin address, which has full control over contract upgrades and administrative functions, is currently an Externally Owned Account (EOA). This creates a critical single point of failure. If this EOA's private key is compromised, a malicious actor could instantly upgrade the proxy to a malicious implementation, potentially leading to a complete loss of funds or system control. (7.3 Access Control, 7.5 Governance, 7.8 Operations)
IssueThe proxy's admin address, which has full control over contract upgrades and administrative functions, is currently an Externally Owned Account (EOA). This creates a critical single point of failure. If this EOA's private key is compromised, a malicious actor could instantly upgrade the proxy to a malicious implementation, potentially leading to a complete loss of funds or system control. (7.3 Access Control, 7.5 Governance, 7.8 Operations)
FixMigrate the proxy admin to a robust multi-signature wallet (e.g., Gnosis Safe) requiring multiple trusted parties to approve any administrative action. This significantly reduces the risk associated with a single private key compromise.
StatusUnresolved
Medium

Potential Storage Collisions in Implementation Contract

M-01While the TransparentUpgradeableProxy itself is secure, the implementation contract it points to must be carefully designed to avoid storage collisions with the proxy's reserved storage slots (e.g., for implementation address, admin address). If the implementation contract declares state variables at the same storage slots used by the proxy, it can lead to unexpected behavior, data corruption, or critical vulnerabilities upon upgrade. (7.1 Architecture, 7.2 Code Security)
IssueWhile the TransparentUpgradeableProxy itself is secure, the implementation contract it points to must be carefully designed to avoid storage collisions with the proxy's reserved storage slots (e.g., for implementation address, admin address). If the implementation contract declares state variables at the same storage slots used by the proxy, it can lead to unexpected behavior, data corruption, or critical vulnerabilities upon upgrade. (7.1 Architecture, 7.2 Code Security)
FixEnsure that all implementation contracts adhere strictly to the UUPS or Transparent proxy storage layout guidelines. Use tools like `hardhat-upgrades` or `truffle-upgrades` to automatically check for storage collisions during development and deployment. Conduct thorough audits of implementation contracts to verify storage compatibility.
StatusUnresolved
Low

Lack of Timelock for Upgrades

L-01The current upgrade mechanism allows the proxy admin to instantly upgrade the contract without any delay. While this provides flexibility, it removes a crucial security layer. In the event of a compromised admin key or a malicious upgrade, users have no time to react, withdraw funds, or migrate. (7.7 Upgrades, 7.8 Operations)
IssueThe current upgrade mechanism allows the proxy admin to instantly upgrade the contract without any delay. While this provides flexibility, it removes a crucial security layer. In the event of a compromised admin key or a malicious upgrade, users have no time to react, withdraw funds, or migrate. (7.7 Upgrades, 7.8 Operations)
FixImplement a timelock mechanism for all critical administrative actions, especially upgrades. This would introduce a mandatory delay between the initiation and execution of an upgrade, providing a window for scrutiny and user response. Consider using OpenZeppelin's `TimelockController`.
StatusUnresolved
Info

Standardized OpenZeppelin Implementation

I-01The contract utilizes OpenZeppelin's TransparentUpgradeableProxy, ERC1967Proxy, ERC1967Upgrade, and Ownable contracts. These are widely used, community-vetted, and regularly audited libraries, which significantly reduces the risk of undiscovered vulnerabilities within the proxy's core logic. (7.2 Code Security)
IssueThe contract utilizes OpenZeppelin's TransparentUpgradeableProxy, ERC1967Proxy, ERC1967Upgrade, and Ownable contracts. These are widely used, community-vetted, and regularly audited libraries, which significantly reduces the risk of undiscovered vulnerabilities within the proxy's core logic. (7.2 Code Security)
FixContinue to rely on well-established and audited libraries for core infrastructure components. Regularly monitor OpenZeppelin's security advisories and update dependencies as recommended.
StatusResolved
Info

Transparent Proxy Admin Segregation

I-02The TransparentUpgradeableProxy pattern effectively segregates calls made by the admin from calls made by regular users. Admin-specific functions (like `upgradeTo`, `changeAdmin`) are handled by the proxy itself, preventing accidental calls to the implementation contract's functions with the same selector. This mitigates a common class of vulnerabilities known as function selector clashes. (7.2 Code Security)
IssueThe TransparentUpgradeableProxy pattern effectively segregates calls made by the admin from calls made by regular users. Admin-specific functions (like `upgradeTo`, `changeAdmin`) are handled by the proxy itself, preventing accidental calls to the implementation contract's functions with the same selector. This mitigates a common class of vulnerabilities known as function selector clashes. (7.2 Code Security)
FixMaintain this standard proxy pattern. Ensure that any custom proxy logic or modifications do not inadvertently reintroduce function selector clash vulnerabilities.
StatusResolved

Category Ratings

TechnicalMedium4/10

The contract utilizes OpenZeppelin's TransparentUpgradeableProxy, a widely adopted and audited standard (7.1 Architecture). Its core strength lies in the segregation of admin and user calls, preventing function selector clashes (7.2 Code Security). However, the proxy's security is heavily dependent on the implementation contract's design, specifically regarding storage slot collisions (7.2 Code Security). The current configuration uses an EOA as the proxy admin, which is a critical single point of failure (7.3 Access Control).

GovernanceHigh1/10

The economic and governance security of the system is critically dependent on the security of the proxy admin address (7.4 Economic, 7.5 Governance). With an EOA as the admin, the entire system is vulnerable to a single private key compromise. This centralization of control means a malicious or compromised admin can instantly upgrade the contract to arbitrary malicious logic, potentially draining funds or altering system behavior without warning (7.3 Access Control).

UpgradesHigh1/10

The proxy provides robust upgradeability through the `upgradeTo` and `upgradeToAndCall` functions (7.7 Upgrades). The admin has full control over these upgrades. A significant risk is the lack of a timelock mechanism for upgrades, allowing immediate changes without community review or user reaction time (7.7 Upgrades). This, combined with the EOA admin, makes the upgrade process highly centralized and instantaneous, increasing the risk of undetected malicious upgrades.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint Function?
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationUnverified source
Upgrades (30d)0 · stable

Holder Composition

80.2% in top 10
76.5% in wallets3.7% in contracts
Effective Concentration78.0%

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

$5.67M across 4 pairs
Uniswap v3USDTanalysed$2.58M45.5%Uniswap v3USDC$2.41M42.6%Uniswap v3WETH$671.6K11.8%Uniswap v4ETH$1.2K0.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 Holder96.3%
Top-3 Unlocked100.0%

Key Addresses

8 addresses
Deployer
0x772d…6af0
Unlocked LP Held By
0x8ae5…4c670x8000…ca290xfb66…55d50x0f7f…043e0xaa1b…927c0x397f…bebd0xac34…39fb

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

What Raised This Score

12 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mint capability UNKNOWN (implementation ABI unreadable)
  • Proxy contract (upgradeable — admin can replace logic)
  • OZ ProxyAdmin -> Admin is EOA (single key controls upgrades)
  • Implementation source NOT verified (opaque code)
  • Top-10 concentration > 70% (80.2% total → 78.0% effective; 76.5% in EOAs, 3.7% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.3% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 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

Related Audits

6 more on the record
SpaceX xStock (SPCXX)Critical RiskBananaCritical RiskPonsCritical RiskGoldfish (GGBR)Critical RiskAUSDCritical RiskNVIDIA (Ondo Tokenized) (NVDAON)Critical Risk

Would You Like a More Detailed Audit of Rollbit Coin?

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

Get Detailed Audit