Is ResearchCoin (RSC) Safe? Smart Contract Security Analysis

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2341Jul 2355

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The OptimismMintableERC20 contract serves as a standard ERC20 token designed for cross-chain bridging within the Optimism ecosystem. It correctly implements restricted minting and burning capabilities via a designated bridge contract. The contract leverages well-audited OpenZeppelin libraries and immutable variables for core addresses. The primary risk identified is the inherent dependency on the security and integrity of the external bridge contract, which controls the token's supply.

Final Recommendation: Ensure the `BRIDGE` contract, which has exclusive control over minting and burning, undergoes rigorous security audits and maintains robust operational security. Given the non-upgradeable nature of this token, any identified vulnerabilities in the future would necessitate a new deployment and asset migration, emphasizing the importance of thorough initial review. Consider documenting the implications of the non-upgradeable design for long-term maintenance and potential future changes.

Category Ratings

TechnicalLow

8/10

The contract exhibits good technical quality, inheriting from OpenZeppelin's robust ERC20 implementation and utilizing Solidity 0.8.15 for built-in overflow/underflow protection (7.2 Code Security). Access control for critical minting and burning functions is correctly enforced via an `onlyBrid

GovernanceHigh

3/10

The economic model of the OptimismMintableERC20 token is straightforward: it functions as a bridged representation of a token on another chain. Its economic security and peg stability are entirely dependent on the integrity and operational security of the `BRIDGE` contract (7.4 Economic). Any govern

UpgradesHigh

3/10

The OptimismMintableERC20 contract is designed as an immutable, non-upgradeable contract, with key addresses set in the constructor (7.7 Upgrades). This design choice simplifies its security model by eliminating risks associated with upgrade mechanisms (e.g., proxy vulnerabilities, storage collision

LP Distribution

Top-1 Unlocked Holder47.5%

Top-3 Unlocked90.0%

What Raised This Score

6 factors

Ownership NOT renounced (admin/mint authority retained)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (56.0% total → 49.1% effective; 44.4% in EOAs, 11.5% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top3 unlocked holders = 90.0% (independent LP — depth risk, pool = 51% of DEX liquidity)
1 Medium 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

Security Findings

3 total

1 Medium 2 Info

M-01MediumUnresolved

Critical Dependency on Bridge Contract Security

The `OptimismMintableERC20` contract's core functionality, specifically the ability to `mint` and `burn` tokens, is exclusively controlled by the `BRIDGE` contract. This makes the token's supply mechanism and overall economic integrity entirely dependent on the security and operational robustness of the external `BRIDGE` contract. A compromise or malfunction of the `BRIDGE` contract would directly lead to unauthorized token issuance or destruction, severely impacting the token's peg and trust (7.6 External).

Recommendation: While this dependency is inherent to the bridged token design, it is crucial to ensure the `BRIDGE` contract itself is subject to the highest security standards, including comprehensive audits, formal verification, and robust operational controls. Implement continuous monitoring for the `BRIDGE` contract's activities.

I-01InformationalUnresolved

Inclusion of Legacy Interface Functions

The contract includes several legacy getter functions (`l1Token`, `l2Bridge`, `remoteToken`, `bridge`) for backward compatibility with older interfaces. While these functions do not introduce direct vulnerabilities, they add to the contract's bytecode size and interface complexity, potentially making the contract harder to reason about for new integrations (7.1 Architecture).

Recommendation: Ensure that documentation clearly distinguishes between current and legacy functions. For future iterations, consider whether the maintenance of extensive legacy interfaces is necessary, or if a cleaner, more streamlined interface could be adopted.

I-02InformationalUnresolved

Non-Upgradeable Contract Design

The `OptimismMintableERC20` contract is designed as an immutable contract, with key parameters like `REMOTE_TOKEN` and `BRIDGE` set as `immutable` in the constructor. This means the contract cannot be upgraded or modified after deployment (7.7 Upgrades). While this simplifies the security model by removing upgrade-related risks, it implies that any discovered vulnerabilities or desired feature changes would necessitate a new deployment and a potentially complex migration process for token holders.

Recommendation: Acknowledge the implications of a non-upgradeable design. Ensure that the initial deployment is exceptionally robust due to the inability to patch. Plan for potential future migration strategies in case a critical issue or necessary feature update arises.

Is ResearchCoin Safe? RSC