> For the complete documentation index, see [llms.txt](https://mute-sh.gitbook.io/mute.sh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mute-sh.gitbook.io/mute.sh/integration-guides/liquidity-vault.md). # Liquidity Vault **The Liquidity Vault is the pooled market maker on the Parlay venue — the house book, owned by its depositors.** Anyone can deposit USDC into one shared pool. The pool is the counterparty on the parlays it backs: it posts the maker-side collateral on every fill it wins, collects the pot when a parlay loses, and pays out when one wins. The pricing edge embedded in every quote accrues to the pool, so depositors earn the house margin without running any market-making infrastructure themselves. Your deposit is represented by **mpMV**, a standard, transferable vault-share token (ERC-4626). Its value tracks the pool's net asset value: as losing parlays pay the pool, the USDC value of each share rises. Live at [**parlay.mute.sh/vault**](https://parlay.mute.sh/vault) — deposit, observe the book, redeem. Fully gasless, exactly like the taker side of the venue. {% hint style="warning" %} **Testnet only.** The vault is deployed on HyperEVM testnet (chainId `998`) at `0x802b6aFf1B498E9Cd88C3E3a1c84395cd1ab0B1f`, plugged into the production v2 escrow. Mainnet is not yet live. Always read the current address from `GET /v1/vault` rather than hardcoding it. {% endhint %} *** ## The idea Every parlay needs a counterparty — someone who wins the taker's stake when any leg loses, and pays the full payout when every leg hits. On this venue that counterparty is normally a market maker competing in the RFQ auction. The vault turns that role into a shared pool: instead of each maker running a private book, one pool of depositor USDC backs parlays directly, and the house's automated pricing quotes on the pool's behalf. Each quote embeds a pricing edge — the gap between the true combined probability of the legs and the odds offered. Any single parlay is a coin flip for the pool, but across many parlays that edge is the pool's expected return, and it compounds into the share price. Depositors are, quite literally, taking the house side of the book. The vault participates in the **same competitive auction as any other maker**: it wins a trade only when its quote gives the taker the best payout. Today it is the venue's primary maker, but nothing about the venue is exclusive to it. *** ## How it works ![Liquidity Vault lifecycle](/files/CqmT3eKnGHo1swqnvHRh) Step by step, from the pool's point of view: 1. **You deposit.** You sign a USDC permit; the relay submits it and the pool mints mpMV shares to your address at the current share price. You are buying into the existing book at fair value — a pro-rata claim on the pool's idle cash *and* its live positions. 2. **The pool quotes.** The house runs automated pricing that responds to every RFQ on the venue in the pool's name. The escrow only accepts quotes carrying the signature of the pool's **on-chain registered quoting key** — a single authorized signer with a bounded, renewable expiry that the pool's owner can rotate or revoke at any time. Nobody else, including the relay, can bind the pool to a price. 3. **A taker accepts → the fill.** This is the only moment pool funds ever move toward a trade. At the instant of the fill, the pool posts the maker collateral straight into the escrow — and the same transaction enforces the pool's risk caps (per-parlay size, total risk budget, live-position count). Between fills, the escrow has no standing access to pool funds at all. 4. **Settlement.** Legs resolve via the venue's oracle pipeline (Chainlink CRE), each behind its own dispute window: * **Any leg loses** → the pool collects the entire pot: its own collateral back plus the taker's stake. A lost leg pays the pool even if a sibling leg was voided. * **Every leg wins** → the taker collects the pot; the pool's posted collateral is the payout. * **A leg is voided with no leg lost** (market cancelled, oracle never resolved) → both sides are refunded their escrowed stake — no gain, no loss. * **Timeout safety valve** — a parlay whose oracle never fully resolves can be force-voided after a deadline, so pool collateral can never be stuck forever. 5. **Proceeds flow back automatically.** Settlement credits land in the escrow's claim ledger and are swept back into the pool's cash as part of normal operation — the venue's keepers sweep on every settlement, and any deposit, redemption, or new fill sweeps first. Depositors never need to do anything. 6. **You redeem.** Burn mpMV, receive USDC at the current share price. Redemptions come out of the pool's idle cash — see [Deposits & redemptions](#deposits--redemptions) below. *** ## Where the yield comes from — a worked example Say a taker stakes **$100** on a three-leg parlay and the pool's winning quote pays **5.0×**. The pot is $500, so the pool locks **$400** of collateral next to the taker's $100. | Outcome | Pool cash flow | Pool P\&L | | --------------- | --------------------------- | --------------------------------- | | Any leg loses | Pool collects the $500 pot | **+$100** (the taker's stake) | | All legs win | Taker collects the $500 pot | **−$400** (the posted collateral) | | Voided, no loss | Both sides refunded | $0 | If the true probability of all three legs hitting is 18%, the fair payout would be \~5.55×. Quoting 5.0× instead gives the pool an expected value of `0.82 × $100 − 0.18 × $400 = +$10` per such parlay — that is the edge. Individual parlays swing the pool up or down by far more than the edge; the edge is what remains on average, and it is what the share price compounds. *** ## Share price and pool value The pool's value (NAV) counts three things at all times: **idle USDC** sitting in the pool, **collateral locked** behind live parlays (carried at cost), and any **settled winnings not yet swept back**. Share price = pool value ÷ shares outstanding. Two properties worth understanding: * **NAV steps at settlement — it is not marked to market.** A live parlay is carried at exactly the collateral locked behind it, regardless of how its legs are trending. When the parlay settles, the pool's value steps up (taker lost) or down (taker won) in one move. Between settlements the share price only drifts up slightly as sweeps bring in settled credits. * **Deposits and redemptions are always at NAV.** Depositing during a hot streak or redeeming before a pending settlement neither dilutes nor rewards anyone unfairly — you enter and exit at the pool's current accounted value. The one sharp edge is that an outcome can be *publicly known* shortly before the escrow records it (dispute windows); the vault carries an optional exit fee (below) as the lever against timing games around that window. mpMV has 12 decimals (USDC has 6). The construction makes the classic "first depositor" share-price manipulation attack economically dead by design. *** ## Risk limits The pool never risks everything at once. Three caps are enforced on-chain, atomically with every fill: | Limit | Current setting | Meaning | | -------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------- | | Risk budget | **80% of pool value** | Total collateral locked across live parlays can never exceed this; at least 20% always remains as a solvency buffer. | | Per-parlay cap | **$50,000** | The most collateral a single parlay can lock. | | Live positions | **64** | Maximum number of parlays the pool backs concurrently. | These are house-tunable parameters — read the live values from `GET /v1/vault` (`max_utilization_bps`, `per_parlay_cap_e6`). When the pool reaches its risk budget it simply **stops bidding**: no mechanism can force it past its caps; capacity re-opens as parlays settle or deposits grow. The `/vault` page shows this as the *Backing capacity* bar. *** ## Deposits & redemptions **Both are gasless.** You sign an EIP-2612 permit — a USDC permit to deposit, a permit on the mpMV share token itself to redeem — and the relay submits the transaction and pays the gas. The funds are pinned to the signer on-chain: deposits mint shares only to the permit signer, redemptions pay USDC only to the share owner. The relay can redirect nothing; the worst a malicious relay could do is decline to submit. * **Deposit any amount, any time** (deposits pause only if the house pauses new exposure entirely). * **Redemptions are limited to idle liquidity.** Collateral locked behind live parlays cannot leave mid-parlay — that is the escrow's guarantee to takers. You can always redeem up to the pool's idle portion immediately (shown as *Available* on the vault page and `idle_e6` in the API) and the remainder as positions settle. **Redemptions never pause**, even when the vault is paused — a pause stops new exposure, it can never trap depositors. * **Exit fee: currently 0%.** The contract carries an optional anti-timing exit fee, hard-capped at 5%, which — if ever enabled — is *retained by the pool* (it accrues to remaining depositors, never to the operator). Its purpose is to make deposit-just-before-a-win / exit-just-before-a-loss round-trips unprofitable on deployments with long dispute windows. *** ## What you trust, and what you don't have to **Enforced by contract — no trust required:** * Pool funds can only leave through two paths: posting collateral inside a capped, taker-countersigned fill, or paying a redemption to the share owner. **There is no admin withdrawal, rescue, or upgrade path for pool USDC.** * Every quote must be signed by the pool's registered quoting key and is verified by the escrow on-chain; the registration has a bounded expiry and is rotatable/revocable, and individual outstanding quotes can be cancelled. * Risk caps are checked in the same transaction as the fill — a mispriced or malicious quote is bounded per-parlay and in aggregate by the caps. * Settlement is enforced by the escrow against the venue's pinned oracle pipeline; a parlay that never resolves is refundable after a timeout. * A pause can stop new fills and deposits, but never redemptions or the sweeping of settled credits. **What depositors do trust:** * **The house's pricing edge.** The owner and its quoting infrastructure set the odds. If the house systematically misprices, the pool loses money within its caps — depositing is a bet on the operator's pricing discipline, exactly like backing any book. * **A narrow operational window on settled credits.** Winnings sit briefly in the escrow's claim ledger before being swept into pool cash. The quoting key has the technical ability to redirect credits sitting in that ledger (a property of the underlying escrow, visible on-chain). The venue minimizes the window by sweeping on every settlement, and cash already in the pool is entirely out of the quoting key's reach. Everything above is verifiable on-chain against the addresses below — the same *verify, don't trust the relay* principle as the rest of the venue. *** ## Risks * **Variance and drawdowns.** The edge is an expectation, not a guarantee. A run of winning takers — especially on large, long-odds parlays — produces real drawdowns; a single max-size parlay hitting can move the pool by up to the per-parlay cap. * **Pricing risk.** The pool's return depends on the house quoting accurately. Sharp takers exploiting stale or wide pricing erode the edge. * **Liquidity timing.** During high utilization, most of the pool is locked; a large redemption may need to wait for settlements. Funds are never stuck (timeout voids guarantee eventual release), but exit timing is not always instant. * **Contract and oracle risk.** Standard smart-contract risk, plus the venue's resolution pipeline (dispute windows, void semantics) sits upstream of every settlement. * **Testnet.** The current deployment is on HyperEVM testnet with test USDC — it is a live, functional system, but not yet a mainnet product. *** ## Reading and using the pool programmatically The vault page is a thin client over three public relay endpoints. All USDC amounts are 6-decimal integers (`_e6`); share amounts (`shares_raw`) are 12-decimal integers. ### `GET /v1/vault` — pool stats Optional `?address=0x…` adds your position and wallet context. Response: | Field | Meaning | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | | `vault`, `escrow`, `usdc`, `chain_id` | Live contract addresses — treat these as authoritative | | `stats.total_assets_e6` | Pool value (NAV) | | `stats.idle_e6` | Idle USDC — redeemable right now | | `stats.locked_e6` | Collateral locked behind live parlays | | `stats.utilization_bps` | Locked share of NAV, in bps | | `stats.available_to_back_e6` | Max collateral the *next single* parlay could lock | | `stats.share_price_e6` | USDC value of one whole mpMV share | | `stats.live_parlays` | Number of live positions the pool is backing | | `stats.max_utilization_bps`, `stats.per_parlay_cap_e6` | Current risk-limit settings | | `stats.total_supply_raw`, `stats.share_decimals` | mpMV supply (12dp) | | `position` | (with `?address=`) your `shares_raw`, `value_e6`, `max_withdraw_e6`, `pool_share_bps`, `share_nonce` | | `wallet` | (with `?address=`) your `usdc_e6` balance and `usdc_nonce` | | `domains` | The two EIP-712 permit domains (`usdcPermit`, `sharePermit`) to sign against | ### `POST /v1/vault/deposit` — gasless deposit ```json { "assets_e6": "1000000000", "owner": "0xYou…", "permit": { "deadline": "…", "v": 27, "r": "0x…", "s": "0x…" } } ``` The permit is a USDC EIP-2612 approval (spender = the vault, value = exactly `assets_e6`) signed against `domains.usdcPermit`. Returns `{ "tx_hash" }`; shares are minted to `owner`. ### `POST /v1/vault/redeem` — gasless redemption ```json { "shares_raw": "1000000000000", "owner": "0xYou…", "permit": { "deadline": "…", "v": 28, "r": "0x…", "s": "0x…" } } ``` The permit is signed on the **mpMV share token itself** (spender = the vault) against `domains.sharePermit`. Returns `{ "tx_hash" }`; USDC is paid to `owner`. Both write endpoints are simulated before submission (a doomed request returns a descriptive error instead of a failed transaction) and rate-limited to **10 actions per address per 10 minutes**. Since mpMV is a standard ERC-4626 vault share, direct on-chain deposits/redemptions with your own gas work too — the relay endpoints are a convenience, not a gate. *** ## Addresses | Contract | Address | Network | | ------------------------------------------- | -------------------------------------------- | ---------------------- | | Liquidity Vault (`mpMV`) | `0x802b6aFf1B498E9Cd88C3E3a1c84395cd1ab0B1f` | HyperEVM Testnet (998) | | ParlayEscrow v2 (the escrow the pool backs) | `0x551D4A7EdB71583C7C12900128727D857e308925` | HyperEVM Testnet (998) | | USDC (EIP-2612, testnet) | `0x75b69d0E8fA3CdB644b0f069E4e876B85A76E137` | HyperEVM Testnet (998) | {% hint style="info" %} Addresses can rotate on testnet redeploys — `GET /v1/vault` always returns the current set. If the endpoint returns `{ "enabled": false }`, the venue is running without a pooled maker. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://mute-sh.gitbook.io/mute.sh/integration-guides/liquidity-vault.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.