2/2
wrapped.bet
🧮 ELI-Vitalik
Construction. For an unordered pair {A, B}, the wrapped share is an SPL Token-2022 mint at PDA(["lp_mint", sort(A,B), token_program]) — deliberately independent of the source AMM, so all venues’ LPs for the pair collapse to one fungible claim. Authority is a program PDA; metadata (Token-2022 MetadataPointer → self TokenMetadata) is set by the creator. A 1 bp TransferFeeConfig is native on the mint.
Verification (the trust model). Wrap takes the candidate AMM pool account and:
1.AmmKind::from_program_id(pool.owner) — the pool must be owned by an allow-listed AMM program (Raydium v4/CPMM, PumpSwap, Meteora). The owning program is the trust anchor; you cannot fabricate a pool because only that program can author its bytes.
2.pool.lp_mint == supplied_lp_mint (reject LpMintMismatch).
3.sort(pool.mintA, pool.mintB) == sort(pair) (reject PairMismatch).
4.Escrow is the canonical ATA(authority, lp_mint, lp_token_program); the LP token program is read from the mint’s owner, not assumed.
The byte offsets for each AMM’s pool layout were validated against live mainnet pools.
Accounting. ERC-4626-style shares, but enforced on-chain and decimal-aware: LP amounts from heterogeneous mints are normalized to a common scale before summing reserves; redemptions denormalize back. shares = deposit·supply/reserves, assets = shares·reserves/supply, both floored. Crucially, reserves are summed only over an AMM-verified LP registry stored in PairConfig — so a donation of a worthless token into an authority-owned ATA can’t inflate NAV; only LPs that passed pool verification count.
Fee invariant. Each mint/burn applies three 1 bp legs. The NAV leg is burned (Δsupply < 0, Δreserves = 0); creator/deployer legs are paid in shares. Combined with permissionless donations (Δreserves > 0, Δsupply = 0), d(reserves/supply) ≥ 0 holds across all protocol operations — NAV per share is monotonically non-decreasing by construction. The only “loss” vector is external (impermanent loss in the underlying pool itself), which is orthogonal to the wrapper.
Composition (the zap). Because mint/burn amounts are path-dependent on realized swap/deposit outputs, the zap is a sequenced multi-tx flow rather than one atomic instruction: wrap-SOL ∥ Jupiter(SOL→leg) → AMM.addLiquidity → Wrap. It’s signed in one signAllTransactions and submitted via rapid-fire sendRawTransaction through a staked (Helius) path, polling status per leg — empirically more reliable than the public Jito bundle endpoint, though a Jito atomic path remains available behind JITO_BE. Exit is the mirror: Unwrap → AMM.removeLiquidity → Jupiter(leg→SOL).
The result is a venue-agnostic, fee-compounding index token over a pair’s aggregate on-chain liquidity, with verifiable accounting and a single-asset (SOL) entry/exit.