Quantum Audit Logo

Is ResearchCoin Safe?

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

ResearchCoin RSC
0xfbb7…f7e1
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Medium2 Informational
Volume 24h
$20.5K
Liquidity
$80.4K
Price
$0.06264
Token Age
1y
Top 10 Holders
56.7%

Security Findings

1 Med2 Info
Medium

Critical Dependency on Bridge Contract Security

M-01The `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).
IssueThe `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).
FixWhile 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.
StatusUnresolved
Info

Inclusion of Legacy Interface Functions

I-01The 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).
IssueThe 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).
FixEnsure 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.
StatusUnresolved
Info

Non-Upgradeable Contract Design

I-02The `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.
IssueThe `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.
FixAcknowledge 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/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 `onlyBridge` modifier, ensuring only the designated bridge can modify token supply (7.3 Access Control). However, the contract's technical integrity is fundamentally tied to the security of the external `BRIDGE` contract, representing a significant external dependency risk (7.6 External).

GovernanceHigh1/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 governance or operational failures within the bridge mechanism could directly impact the value and trust in this token (7.5 Governance, 7.8 Operations).

UpgradesHigh3/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 collisions). However, it implies that any future bug fixes or feature enhancements would require a complete redeployment and migration of assets, which can be a complex and costly process.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

56.7% in top 10
53.1% in wallets3.6% in contracts
Effective Concentration54.5%

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

$143.1K across 3 pairs
AerodromeWETHanalysed$80.4K56.1%AerodromeWETH$44.9K31.4%Uniswap v3WETH$17.9K12.5%

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 Holder88.1%
Top-3 Unlocked98.9%

Key Addresses

8 addresses
Deployer
0xafdb…e860
Unlocked LP Held By
0xc37a…ab210xe75c…f0fe0xa181…9f1e0xa3fb…50d90x1a4a…4e5a0xafa7…e6550x6ae1…c017

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 NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (56.7% total → 54.5% effective; 53.1% in EOAs, 3.6% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 88.1% (independent LP — depth risk, pool = 56% of DEX liquidity)
  • LP top3 unlocked holders = 98.9% (independent LP — depth risk, pool = 56% 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

Related Audits

6 more on the record
Fren PetHigh RiskVoice of the Gods by Virtuals (ADM)High Riskether.fi governance token (ETHFI)High RiskCluster Protocol (CP)High RiskMetronome Synth USD (MSUSD)High RiskCoW Protocol Token (COW)High Risk

Would You Like a More Detailed Audit of ResearchCoin?

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

Get Detailed Audit