Is Rainbow (RNBW) Safe? Smart Contract Security Analysis

Security Findings

1 Low2 Info

Low

Dependency on External Bridge Security

L-01The `OptimismMintableERC20` token's security is highly dependent on the security of the `BRIDGE` contract, which has exclusive control over minting and burning via the `onlyBridge` modifier. A compromise of the `BRIDGE` would directly impact the token's integrity by allowing unauthorized supply manipulation. This is an inherent design characteristic of a bridged token, not a flaw in this specific contract, but it represents a significant external risk (7.6 External).

IssueThe `OptimismMintableERC20` token's security is highly dependent on the security of the `BRIDGE` contract, which has exclusive control over minting and burning via the `onlyBridge` modifier. A compromise of the `BRIDGE` would directly impact the token's integrity by allowing unauthorized supply manipulation. This is an inherent design characteristic of a bridged token, not a flaw in this specific contract, but it represents a significant external risk (7.6 External).

FixEnsure the `BRIDGE` contract undergoes rigorous security audits and maintains robust operational security. Implement comprehensive monitoring for the `BRIDGE` contract's activities and consider multi-signature or time-lock mechanisms for critical operations.

StatusUnresolved

Info

Immutable Critical Parameters

I-01Key parameters such as `REMOTE_TOKEN`, `BRIDGE`, and `DECIMALS` are declared as `immutable` and set during construction. This prevents any post-deployment modification, enhancing the contract's security and predictability (7.1 Architecture).

IssueKey parameters such as `REMOTE_TOKEN`, `BRIDGE`, and `DECIMALS` are declared as `immutable` and set during construction. This prevents any post-deployment modification, enhancing the contract's security and predictability (7.1 Architecture).

FixNo action required; this is a good security practice already implemented.

StatusResolved

Info

Adherence to Standards and Best Practices

I-02The contract correctly implements ERC20 and ERC165 standards, including the `supportsInterface` function, ensuring compatibility within the ecosystem. It also utilizes battle-tested OpenZeppelin libraries for core ERC20 functionality, reducing the likelihood of common vulnerabilities (7.2 Code Security).

IssueThe contract correctly implements ERC20 and ERC165 standards, including the `supportsInterface` function, ensuring compatibility within the ecosystem. It also utilizes battle-tested OpenZeppelin libraries for core ERC20 functionality, reducing the likelihood of common vulnerabilities (7.2 Code Security).

FixNo action required; this is a good security practice already implemented.

StatusResolved

Category Ratings

TechnicalLow8/10

The technical implementation of the OptimismMintableERC20 contract is robust. It leverages battle-tested OpenZeppelin libraries for ERC20 functionality and Solidity 0.8.15, mitigating common vulnerabilities like integer overflows. Critical parameters such as `BRIDGE` and `REMOTE_TOKEN` are immutable, preventing unauthorized changes (7.1 Architecture). Access control for `mint` and `burn` functions is strictly enforced via the `onlyBridge` modifier, ensuring only the designated bridge can modify token supply (7.3 Access Control).

GovernanceHigh2/10

The economic security of the OptimismMintableERC20 token is primarily dependent on the security and operational integrity of the external `BRIDGE` contract. The `BRIDGE` contract holds exclusive power to mint and burn tokens, making it a central point of control (7.4 Economic). While this design is inherent to cross-chain bridged tokens, a compromise of the `BRIDGE` could lead to unauthorized token supply manipulation. There is no on-chain governance mechanism within this specific contract (7.5 Governance).

UpgradesHigh3/10

The OptimismMintableERC20 contract is not designed to be upgradeable. It does not implement any proxy patterns (e.g., UUPS, Transparent) or upgradeability mechanisms (7.7 Upgrades). This eliminates risks associated with upgradeability, such as proxy storage collisions or faulty upgrade logic.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

88.5% in top 10

6.5% in wallets82.0% in contracts

Effective Concentration39.3%

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

$122.7K across 15 pairs

Uniswap v4USDCanalysed$114.6K AerodromeUSDC$5.6K Uniswap v4USDC$1.7K Uniswap v4ETH$350 Uniswap v3USDC$216 Uniswap v4ETH$149

Show 4 more pairsShow less

AerodromeAERO$12 Uniswap v3WETH$9 Uniswap v4ETH$1 Uniswap v4ETH$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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0xa151…c975

Unlocked LP Held By

0x729d…9f35

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)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (88.5% total → 39.3% effective; 6.5% in EOAs, 82.0% 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 = 93% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 93% of DEX liquidity)
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

Is Rainbow Safe?