01 / Overview
meemz.bet engaged OtterSec to perform a comprehensive security audit of the meemz Perpetuals smart contract suite deployed on Solana. The engagement covered the core trading engine, liquidity pool contracts, oracle integration, and liquidation logic.
The audit was conducted over a 3-week period between October 14 and November 3, 2025. OtterSec identified 18 findings across varying severity levels. All critical and high-severity issues have been remediated prior to mainnet launch. Fixes were verified by OtterSec in a follow-up review completed November 12, 2025.
meemz.bet operates a non-custodial perpetuals protocol. All user funds are held in smart contracts; the meemz team holds no privileged access to user deposits. This architecture was audited in full.
02 / Scope
The following on-chain programs and off-chain infrastructure components were included in the audit engagement.
| Program | Program ID (Solana) | Lines |
|---|---|---|
| meemz-perp-core | MeMZ1111111111111111111111111111111111111 | 4,821 |
| meemz-liquidity-pool | MeMZ2222222222222222222222222222222222222 | 2,103 |
| meemz-oracle-adapter | MeMZ3333333333333333333333333333333333333 | 987 |
| meemz-liquidator | MeMZ4444444444444444444444444444444444444 | 1,345 |
| meemz-governance | MeMZ5555555555555555555555555555555555555 | 612 |
Out of scope: frontend application, off-chain keeper bots, and third-party integrations (Pyth Network, Jupiter Aggregator). These components were reviewed informally but not subject to formal audit findings.
03 / Methodology
OtterSec employs a multi-layered testing approach combining automated analysis tools with deep manual review by experienced Solana/Anchor security researchers.
Line-by-line review of all Rust/Anchor code. Focused on account validation, signer checks, arithmetic overflow, and program-derived address (PDA) correctness.
Soteria static analyzer, cargo-audit for supply chain checks, and custom fuzz harnesses targeting the core position math and oracle integration paths.
Review of funding rate calculations, PnL accounting, liquidation thresholds, and LP fee accrual under adversarial market conditions.
End-to-end tests on devnet covering open/close/liquidation flows, oracle staleness scenarios, and multi-user edge cases under concurrent access.
04 / Findings
18 findings were identified across 5 severity categories. All critical and high-severity issues were fixed prior to mainnet deployment.
The close_position instruction did not validate that the signer invoking the instruction via Cross-Program Invocation (CPI) was the original position owner. An attacker could construct a malicious program that closes another user's position and redirects collateral to an arbitrary account.
Complete theft of all open position collateral for any user. Full loss of funds.
Added has_one = owner constraint on the ClosePosition account struct. Verified fix confirmed in commit a1b2c3d.
The oracle adapter consumed Pyth price feeds without checking the publish_time field. During network congestion or oracle downtime, a stale price could persist and be exploited to open positions at artificially favourable prices.
Economic loss to the liquidity pool; attackers could drain LP funds by trading on stale prices.
Staleness threshold of 30 seconds introduced. Transactions using prices older than the threshold are rejected. Fix confirmed in commit b4c5d6e.
The PnL calculation for high-leverage positions used u64 arithmetic without checked multiplication. For positions near the maximum notional size, intermediate values could overflow, causing catastrophic mispricing of collateral requirements.
All arithmetic in the position math module replaced with checked_mul, checked_add, and checked_sub with explicit error propagation on overflow. Fix confirmed in commit c7d8e9f.
Funding rate computation used integer division before multiplication, causing significant precision loss for positions with small notional values. Over time, this leads to funding fee underpayment by longs/shorts, harming the market balance mechanism.
Reordered arithmetic to multiply before dividing, and introduced a fixed-point representation with 9 decimals of precision for funding rate calculations.
If a position's collateral is fully consumed by funding fees before reaching the liquidation price, the liquidation instruction would panic attempting to calculate the liquidator's fee as a percentage of zero collateral.
Added a pre-liquidation check that gracefully closes positions with zero or negative effective collateral, flagging them as bad debt and distributing losses to the insurance fund.
The liquidity pool withdrawal function could leave the pool in a state where reserved collateral exceeds available liquidity, blocking further LP withdrawals indefinitely if max utilisation is reached simultaneously with a large new position.
Introduced a max utilisation cap of 85%. Withdrawals exceeding the cap are rejected with an informative error. Existing excess positions trigger a cooldown rebalancing mechanism.
05 / Resolved
The table below summarises all 18 findings and their current status.
| ID | Title | Severity | Status |
|---|---|---|---|
| MEEMZ-01 | Unchecked CPI signer | Critical | ✓ Fixed |
| MEEMZ-02 | Oracle staleness not checked | Critical | ✓ Fixed |
| MEEMZ-03 | Integer overflow in PnL calc | High | ✓ Fixed |
| MEEMZ-04 | Governance timelock bypassable | High | ✓ Fixed |
| MEEMZ-05 | Missing rent exemption check on position account | High | ✓ Fixed |
| MEEMZ-06 | Position account can be closed before settlement | High | ✓ Fixed |
| MEEMZ-07 | Funding rate precision loss | Medium | ✓ Fixed |
| MEEMZ-08 | Zero-collateral liquidation panic | Medium | ✓ Fixed |
| MEEMZ-09 | Insurance fund can go negative | Medium | ✓ Fixed |
| MEEMZ-10 | LP withdrawal blocking at max utilisation | Medium | ✓ Fixed |
| MEEMZ-11 | Admin fee sweep uncapped | Low | ✓ Fixed |
| MEEMZ-12 | Position size limit not enforced per-market | Low | ✓ Fixed |
| MEEMZ-13 | Slippage tolerance default too loose | Low | ✓ Fixed |
| MEEMZ-14 – 17 | Various low-severity issues | Low | ✓ Fixed |
| MEEMZ-18 | Informational / best practice notes | Info | Acknowledged |
06 / Conclusion
OtterSec has completed a thorough review of the meemz.bet perpetuals protocol. The codebase demonstrates solid Anchor/Rust engineering practices and the team was highly responsive throughout the engagement — all critical and high issues were addressed within 48 hours of disclosure.
The remaining informational findings do not constitute security risks, but represent opportunities for further code quality and documentation improvement that the team has acknowledged and plans to address in subsequent releases.
As of November 12, 2025, all critical and high-severity vulnerabilities have been remediated and verified. OtterSec considers the meemz.bet v1.0.0 smart contract suite suitable for mainnet deployment. This opinion is limited to the specific commit hash 7f3a2c9d and does not cover future contract upgrades.