Is MetaSoilVerseProtocol (MSVP) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Complex Inline Assembly in `Math.mulDiv`

H-01The `mulDiv` function in the `Math` library utilizes complex inline assembly for critical arithmetic operations. While assembly can offer performance benefits and precise control, it is significantly more difficult to audit, verify, and maintain compared to high-level Solidity. Subtle errors in assembly can lead to incorrect calculations, unexpected behavior, or even critical vulnerabilities that are hard to detect. The current implementation involves intricate bitwise operations and `mulmod` calls.

IssueThe `mulDiv` function in the `Math` library utilizes complex inline assembly for critical arithmetic operations. While assembly can offer performance benefits and precise control, it is significantly more difficult to audit, verify, and maintain compared to high-level Solidity. Subtle errors in assembly can lead to incorrect calculations, unexpected behavior, or even critical vulnerabilities that are hard to detect. The current implementation involves intricate bitwise operations and `mulmod` calls.

FixThoroughly review and formally verify the `mulDiv` assembly code to ensure its correctness across all possible input ranges. Consider adding extensive unit tests specifically for `mulDiv` covering edge cases, large numbers, and zero values. If possible, provide detailed comments explaining each step of the assembly logic. Alternatively, consider using a well-vetted and simpler `mulDiv` implementation if the performance gains from this specific assembly are not strictly necessary.

StatusUnresolved

Medium

Extensive Use of `unchecked` Blocks Without Contextual Validation

M-01Several functions within the `Math` and `SignedMath` libraries, such as `abs`, `sqrt`, `log2`, `log10`, and `log256`, employ `unchecked` blocks. While `unchecked` is a valid optimization in Solidity 0.8.0+ to prevent automatic overflow/underflow checks, it shifts the responsibility of ensuring arithmetic safety to the caller. Without the context of the `MSVP` contract, it's unclear if all inputs to these `unchecked` operations are guaranteed to prevent overflows or underflows, potentially leading to incorrect state changes or unexpected behavior if not properly validated by the consuming contract.

IssueSeveral functions within the `Math` and `SignedMath` libraries, such as `abs`, `sqrt`, `log2`, `log10`, and `log256`, employ `unchecked` blocks. While `unchecked` is a valid optimization in Solidity 0.8.0+ to prevent automatic overflow/underflow checks, it shifts the responsibility of ensuring arithmetic safety to the caller. Without the context of the `MSVP` contract, it's unclear if all inputs to these `unchecked` operations are guaranteed to prevent overflows or underflows, potentially leading to incorrect state changes or unexpected behavior if not properly validated by the consuming contract.

FixEnsure that any contract utilizing these `unchecked` functions performs rigorous input validation or has strong invariants that guarantee arithmetic safety. Document the assumptions made about input ranges for each `unchecked` block. When integrating these libraries into `MSVP`, verify that all calls to these functions are safe from overflow/underflow based on the specific application logic.

StatusUnresolved

Low

Potential for Precision Loss in `mulDiv` with Default Rounding

L-01The `mulDiv` function, when called without a `Rounding` parameter or with `Rounding.Zero`, truncates the result, effectively rounding down. While this behavior is often desired, if not explicitly accounted for in economic calculations, repeated truncations can lead to a cumulative loss of precision. This could result in minor discrepancies over time, potentially affecting token balances or reward distributions if not properly managed.

IssueThe `mulDiv` function, when called without a `Rounding` parameter or with `Rounding.Zero`, truncates the result, effectively rounding down. While this behavior is often desired, if not explicitly accounted for in economic calculations, repeated truncations can lead to a cumulative loss of precision. This could result in minor discrepancies over time, potentially affecting token balances or reward distributions if not properly managed.

FixEnsure that the consuming `MSVP` contract explicitly considers the rounding behavior of `mulDiv`. For sensitive economic calculations where precision is paramount, evaluate if `Rounding.Up` or a custom rounding logic is more appropriate. Document the chosen rounding strategy for all critical calculations to prevent misunderstandings and ensure consistent behavior.

StatusUnresolved

Info

Missing Core Contract Logic (`MSVP`)

I-01The provided source code only includes utility libraries (`Context`, `IERC165`, `SignedMath`, `Math`, `ERC165`, `Strings`). The main `MSVP` contract, which would integrate these libraries and define the core business logic, state variables, and user interactions of the protocol, was not supplied for review. This significantly limits the scope of the audit, as the overall security posture, economic model, access control, and upgradeability of the actual protocol cannot be assessed.

IssueThe provided source code only includes utility libraries (`Context`, `IERC165`, `SignedMath`, `Math`, `ERC165`, `Strings`). The main `MSVP` contract, which would integrate these libraries and define the core business logic, state variables, and user interactions of the protocol, was not supplied for review. This significantly limits the scope of the audit, as the overall security posture, economic model, access control, and upgradeability of the actual protocol cannot be assessed.

FixProvide the complete source code for the `MSVP` contract and any other relevant contracts that comprise the protocol. A full audit requires access to all interconnected components to thoroughly evaluate potential vulnerabilities, interactions, and overall system design.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture consists of well-defined utility libraries for mathematical operations and string conversions (7.1 Architecture). The `Math` library provides advanced functions like `mulDiv` and `sqrt`, which are crucial for precise calculations. However, the `mulDiv` function utilizes complex inline assembly, which increases the risk of subtle bugs and makes verification challenging (7.2 Code Security). Additionally, several functions employ `unchecked` blocks, shifting the responsibility for overflow/underflow prevention to the caller, which could lead to issues if not handled carefully (7.2 Code Security). Access control (7.3) is not applicable as these are pure utility libraries.

GovernanceHigh3/10

The provided contracts are utility libraries and do not contain any economic mechanisms (7.4 Economic) or governance structures (7.5 Governance). Therefore, economic and governance risks cannot be assessed based on this code alone. There are no external interactions (7.6) defined within these libraries.

UpgradesLow8/10

The provided code consists of standalone utility libraries and abstract contracts, which are not designed to be upgradeable themselves (7.7 Upgrades). The prefill data indicates `is_proxy: false`, confirming that these are not proxy contracts. Operational aspects (7.8) are not directly applicable to these pure utility components.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

65.9% in top 10

58.9% in wallets7.0% in contracts

Effective Concentration61.7%

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

$11.9K across 2 pairs

Pancakeswap v3USDTanalysed$11.9K Pancakeswap v2USDT$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

7 addresses

Deployer

0xf697…95aa

Unlocked LP Held By

0x05cc…5f120x4403…776b0x622b…d22d0x0596…24740xd286…d32f0xe90d…1e95

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

What Raised This Score

8 factors

Top-10 concentration > 50% (65.9% total → 61.7% effective; 58.9% in EOAs, 7.0% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($11,919 across 2 pairs — thin market)
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
1 High finding(s) from audit
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 MetaSoilVerseProtocol Safe?

Security Findings

Complex Inline Assembly in `Math.mulDiv`

Extensive Use of `unchecked` Blocks Without Contextual Validation

Potential for Precision Loss in `mulDiv` with Default Rounding

Missing Core Contract Logic (`MSVP`)

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of MetaSoilVerseProtocol?