Is SoSoValue (SOSO) Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Low2 Info

Medium

Critical Dependency on External Bridge Contract Security

M-01The 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).

IssueThe 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).

FixEnsure 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.

StatusUnresolved

Low

Interface Mismatch for `bridge()` Function View Mutability

L-01The `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).

IssueThe `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).

FixUpdate 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);`.

StatusUnresolved

Info

Effective Use of OpenZeppelin Libraries

I-01The 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).

IssueThe 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).

FixContinue 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.

StatusResolved

Info

Immutable Critical Parameters

I-02The `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).

IssueThe `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).

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

StatusResolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh2/10

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).

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

97.8% in top 10

9.5% in wallets88.3% in contracts

Effective Concentration44.8%

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

$281.6K across 3 pairs

Uniswap v3USDCanalysed$219.8K Uniswap v4USDC$61.8K PancakeswapWETH$12

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

0xf137…22c2

Unlocked LP Held By

0x7134…c902

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

What Raised This Score

8 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

Is SoSoValue Safe?