Quantum Audit Logo
Launch App

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

Is SoSoValue Safe?

SOSOBase
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance2/10Upgrades3/10Checks passed2 of 5Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

The OptimismMintableERC20 contract serves as a standard ERC-20 token on an L2 (like Base), designed to be minted and burned exclusively by a designated bridge contract.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (97.8% total → 44.8% effective; 9.5% in EOAs, 88.3% 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 = 78% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 78% of DEX liquidity)
  • 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
88.3%Contracts9.5%Wallets2.2%
88.3%Contracts9.5%
ContractsWalletsEveryone elseBubble area = share of supply
97.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking88.3%
  • Walletsanonymous holders, free to sell9.5%
  • Everyone elsethe rest of the supply2.2%
Effective concentrationwhat the score reads44.8%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$281.6K across 3 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$219.8KShare of depth78.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x7134…c902

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

Security Findings

1 Medium1 Low2 Info
Medium

Critical Dependency on External Bridge Contract Security

The OptimismMintableERC20 token's entire supply mechanism relies on the BRIDGE address, which has exclusive permission to call the mint and burn functions. If the BRIDGE contract is compromised, an attacker could arbitrarily mint tokens, leading to hyperinflation and a complete loss of value for the token. This is an inherent design characteristic of a mintable bridged token, but it represents the single most significant risk to the system's economic integrity (7.4 Economic, 7.6 External).M-01

Issue

The OptimismMintableERC20 token's entire supply mechanism relies on the BRIDGE address, which has exclusive permission to call the mint and burn functions. If the BRIDGE contract is compromised, an attacker could arbitrarily mint tokens, leading to hyperinflation and a complete loss of value for the token. This is an inherent design characteristic of a mintable bridged token, but it represents the single most significant risk to the system's economic integrity (7.4 Economic, 7.6 External).

Fix

Ensure the BRIDGE contract is secured with the highest possible standards, including comprehensive audits, robust access control (e.g., multi-signature wallets, time-locks), and continuous monitoring. The security posture of the BRIDGE contract directly dictates the security of this token.

Status

Unresolved

Low

Interface Mismatch for bridge() Function View Mutability

The IOptimismMintableERC20 interface declares the bridge() function as external returns (address), omitting the view keyword. However, the OptimismMintableERC20 implementation correctly defines it as public view returns (address). While the implementation is more restrictive and correct, this minor inconsistency in the interface definition could lead to confusion or potential issues with static analysis tools expecting exact interface compliance (7.2 Code Security).L-01

Issue

The IOptimismMintableERC20 interface declares the bridge() function as external returns (address), omitting the view keyword. However, the OptimismMintableERC20 implementation correctly defines it as public view returns (address). While the implementation is more restrictive and correct, this minor inconsistency in the interface definition could lead to confusion or potential issues with static analysis tools expecting exact interface compliance (7.2 Code Security).

Fix

Update the IOptimismMintableERC20 interface to include the view keyword for the bridge() function to accurately reflect its mutability and ensure full consistency with the implementation: function bridge() external view returns (address);.

Status

Unresolved

Info

Effective Use of OpenZeppelin Libraries

The contract effectively utilizes battle-tested and audited OpenZeppelin contracts (ERC20, IERC165). This practice significantly reduces the risk of common vulnerabilities and improves the overall security posture of the contract by relying on widely accepted and secure implementations (7.2 Code Security).I-01

Issue

The contract effectively utilizes battle-tested and audited OpenZeppelin contracts (ERC20, IERC165). This practice significantly reduces the risk of common vulnerabilities and improves the overall security posture of the contract by relying on widely accepted and secure implementations (7.2 Code Security).

Fix

Continue to leverage well-vetted libraries like OpenZeppelin for standard functionalities. Ensure that the specific versions used are up-to-date and free from known vulnerabilities.

Status

Resolved

Info

Immutable Critical Parameters

The REMOTE_TOKEN, BRIDGE, and DECIMALS variables are declared as immutable and initialized in the constructor. This is a strong security practice as it ensures these critical parameters cannot be altered after deployment, preventing unauthorized changes to the token's fundamental configuration (7.2 Code Security, 7.3 Access Control).I-02

Issue

The REMOTE_TOKEN, BRIDGE, and DECIMALS variables are declared as immutable and initialized in the constructor. This is a strong security practice as it ensures these critical parameters cannot be altered after deployment, preventing unauthorized changes to the token's fundamental configuration (7.2 Code Security, 7.3 Access Control).

Fix

Maintain the use of immutable for all critical parameters that should not change post-deployment. This enhances security and predictability.

Status

Resolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The OptimismMintableERC20 contract serves as a standard ERC-20 token on an L2 (like Base), designed to be minted and burned exclusively by a designated bridge contract. The contract itself is well-structured, utilizes OpenZeppelin libraries, and implements robust access control for its core functionalities. The primary risk stems from its inherent dependency on the security and integrity of the external bridge contract, which controls the token's supply.

Technical8/10Low risk

The technical implementation of the OptimismMintableERC20 contract is robust (7.2 Code Security). It leverages battle-tested OpenZeppelin libraries for ERC-20 functionality, minimizing common vulnerabilities. Access control for minting and burning is strictly enforced via the onlyBridge modifier (7.3 Access Control), ensuring only the designated bridge can alter token supply. Critical parameters like REMOTE_TOKEN, BRIDGE, and DECIMALS are set as immutable in the constructor, preventing post-deployment modification. No reentrancy or integer overflow/underflow vulnerabilities were identified.

Governance2/10High risk

The economic security of this token is critically dependent on the external BRIDGE contract (7.4 Economic, 7.6 External). The BRIDGE address has the sole authority to mint and burn tokens, meaning any compromise of the bridge would directly impact the token's integrity and value. While this is an inherent design pattern for bridged tokens, it represents the single largest economic risk. The immutability of DECIMALS is a positive economic control, preventing unexpected changes to token divisibility. There are no direct governance mechanisms within this contract (7.5 Governance).

Upgrades3/10High risk

The OptimismMintableERC20 contract is not designed to be upgradeable (7.7 Upgrades). It is deployed as a standard implementation contract without proxy patterns. This eliminates upgrade-related risks such as proxy misconfigurations, storage collisions, or logic errors during upgrades. Any future changes would require a new deployment and migration, which is a clear and transparent process.

Final RecommendationWhat to do about this score

Prioritize the security of the BRIDGE contract, as it holds ultimate control over the token supply.

Ensure the bridge contract undergoes rigorous security audits and maintains robust operational security practices. Consider implementing multi-signature controls or time-locks for critical bridge operations if not already in place. Regularly review the REMOTE_TOKEN and BRIDGE addresses to confirm their integrity and prevent any unauthorized changes to the L1 token or L2 bridge.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age8mo
Contract0x624e…8831
Deployer0xf137…22c2
Badge for your website
SoSoValue security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 15, 202653Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
AUTONOMOPOLYAUTONO · Base53MediumSolanaSOL · Base53MediumTAOTBase53MediumCheckmateCHECK · Base53MediumSallyA1C · Base53MediumOFCBase53Medium

Would You Like a More Detailed Audit of SoSoValue?

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