Meson

Late-release loss mode: an LP can keep a passive user's funds — the promised penalty was never implemented

MesonSwap / MesonPools on the deployed implementation

What we demonstrated (fork of the live deployment, exact balance deltas)

• User postSwap 100 USDC on Ethereum with an honest LP.
• LP locks the equivalent on the target chain.
• LP withholds the release signature past LOCK_TIME_PERIOD (40 min per deployed bytecode — twice what process.md says).
• After the lock window the LP calls unlock() to recover its own collateral AND executeSwap() to take the user's 100 USDC. executeSwap has no authorization check and no expiry enforcement — anyone holding the release signature can call it, even after expireTs.
• The user's legitimate release() now reverts "Swap does not exist" — funds gone. Net: user −100 USDC, attacker +100 USDC, LP pool intact.

Why this rates Medium (not High)

The 40-minute window is raceable by the user themselves: the user signs the release signature, release() on the target chain is permissionless and valid until lock + 40 min, and executeSwap() on the source chain is permissionless. A user-side watcher can self-release and self-execute inside the window and complete the swap honestly — making the theft impossible. The loss therefore requires the user to stay passive for 40+ minutes after the target-side lock, exactly the scenario the docs' own "Release too late" red-severity warning describes. Aggravators kept: no cross-chain linkage on-chain, no contract recourse for passive app users, theft irreversible, per-swap loss capped at 100k (MAX_SWAP_AMOUNT), and the penalty promised in 2022 never shipped.

Evidence

• The loss replay was demonstrated on a fork of the live deployment with exact balance deltas: user −100 USDC, attacker +100 USDC, LP pool intact.
• executeSwap has no caller check and no expiry enforcement — demonstrated directly against the deployed bytecode, including after expireTs.
• The 40-minute window is real: release succeeds one second before the deadline and reverts one second after.
• Meson's own docs acknowledge the mode (docs.meson.fi protocol/security.md, "Release too late", red severity).
• SSLab 2022 found the economically equivalent mempool-delay variant, marked "Confirmed and Fixed" — the fix was the 100k per-swap amount cap, which bounds loss but does not close the window.

Recommendation

• Bind executeSwap to a commitment deadline: it must execute within LOCK_TIME_PERIOD of the release signature being witnessed on the target chain, independent of expireTs.
• Require the release signature to be witnessed on the target chain before executeSwap succeeds on the source chain.
• Add an on-chain per-swap state transition so the same encoding cannot be both unlocked and executed.
• Implement the LP penalty promised in the 2022 audit response.

Team response

2026-10-28, Meson Discord admin ("MrFish"): "some of the code may have deviated over time, that is expected as new features or code is pushed; the audit of such deviation will only be done at a later stage or when possible… I too am aware that some of the information in the docs are outdated. They will be updated at a later time." The same admin later called the report "a minor thing" that does not "warrant immediate attention." No technical dispute was received. Update, later the same day: after our follow-up, MrFish acknowledged the feedback and an engineering contact was established.

The dominant swap path pulls from user wallets — no escrow, no lock, no cancel

directSwap / directRelease / directExecuteSwap / simpleExecuteSwap on the deployed implementation

37 of the last 50 MESON-labelled Ethereum transactions run the direct flow (22× directRelease, 12× simpleExecuteSwap, 3× directExecuteSwap) versus only 2× executeSwap and 5× postSwap on the audited escrow path. The direct flow is a pull model absent from all four audits and from all documentation.

• directExecuteSwap(encoded, …) pulls `amount` from the initiator's wallet into a shared pool (index 1, owner 0x0014Eb…53C), gated only by the user's pre-signed release signature.
• No target-side proof, no lock, no 40-minute wait, no LP collateral.
• cancelSwap reverts ("Swap does not exist") — postedSwap == 0 on this path — so the user has zero on-chain recourse if the pool operator misbehaves.
• Funds land in the operator-custody pool; withdraw() is owner-gated. The pull is therefore not directly profitable for random outsiders — it is a custodial trust position: operator-drain risk plus a phishing vector for the pre-signed release. Fake-support accounts hunting exactly such signatures are active in Meson's own Discord (see User guidance).
• Fork-demonstrated: user −100 USDC exact. simpleExecuteSwap is benign — it self-pulls from msg.sender, not from the user.

Recommendation

• Document the direct flow's trust model prominently — users currently cannot see which trust model their swap uses.
• Add target-side proof before the source-side pull, and an on-chain cancel window.
• Consider per-operator caps on the pull path.

Team response

Same as F-1: no technical dispute. Update, 2026-10-28: an engineering contact was established; the deviation-audit question is now reviewed together with the team.

One EOA key controls the upgrade path on every EVM chain — and that surface is undocumented

ProxyToMeson (UUPS) / MesonConfig — admin surface

The deployment is a UUPS proxy whose implementation is unverified bytecode on every explorer. The admin surface, reconstructed from bytecode storage-slot analysis, event topics, and live probes:

• No timelock, no pause, no multisig, and no signature-invalidation capability exists in the 45-selector dispatch.
• The owner-gated set touches nothing in the posted-swap state — an owner cannot cancel swaps, but can replace the entire implementation at will.
• Single point of failure: the same canonical proxy address is deployed on every EVM chain. One compromised owner key = implementation replacement across all chains simultaneously.

Recommendation

• Move ownership to a multisig with a timelock; publish the admin-surface policy.
• Verify the implementation source on all explorers — it is currently unverified bytecode.
• Document the premiumManager role and the 7702 delegate's capabilities.
• Resolve and publish adjustToPool semantics.

Every swap under $0.50 fails to release on the target chain

MesonPools release()

releaseAmount = amount − lpFee − max(amount/2000, 500000) underflows whenever amount − lpFee < 1000 units ($0.50 in USDC-6 decimals): Solidity arithmetic panic 0x11. release() permanently reverts for that encoding. The relayer admits swaps down to $0.01, so sub-$0.50 target legs always fail to release; the user must wait for expiry + cancelSwap to recover funds. No fund loss — a liveness bug on a real user path.

• Evidence: the panic was reproduced on a fork for any sub-$0.50 encoding.
• Suggested fix: clamp releaseAmount to zero, or skip the service-fee floor when amount < 1000 units.

Re-posting a cancelled-then-expired swap panics instead of reverting gracefully

verifyEncodedSwap

Re-posting the encoding of a swap that was cancelled and then expired hits an arithmetic panic (0x11) instead of a clean revert — demonstrated on a fork. No value at risk; raw panics make failure harder to debug for integrators.

Deployed bytecode drifts from the audited sources — and the sources are now private

Deployed implementation vs audited commit 47836cbe…

17 of the 37 functions in the official SDK ABI (npm mesonfi-contract-abis@1.14.0) are absent from the audited 2022/2023 sources: directSwap, directRelease, directExecuteSwap, adjustToPool, withdrawServiceFee, transferPoolOwner, transferPremiumManager, addSupportToken, removeSupportToken, addMultipleSupportedTokens, simpleExecuteSwap, postSwapWithSignature, postSwapFromInitiator, postSwapFromContract, lockSwap, and the UUPS standard functions. The meson-contracts-solidity repo has been privatized, so no outsider can source-diff the deployed bytecode against the audited commit, and the docs' GitHub links are dead. We reconstructed the deployed interface (45 selectors, swap encoding layout, signature digest schemes) and shared it with the team, together with a fork-test suite, so they can audit the drift against their private repo.