> 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/readme.md).

# Overview

**Parlay** is a privacy-preserving, multi-leg OTC trading system for HIP-4 prediction market outcomes on HyperEVM. Takers submit a bundle of outcome positions and receive competing, cryptographically signed quotes from registered Market Makers. Funds are escrowed trustlessly on-chain at fill, and payouts are enforced on-chain at settlement — the relay never touches user funds.

{% hint style="warning" %}
**Testnet only.** All contracts are deployed on HyperEVM testnet (chainId `998`). Mainnet is not yet live.
{% endhint %}

***

## How It Works

![RFQ lifecycle — from RFQ to on-chain fill](/files/5OyUrGAeufnJfgmg5x25)

The Relay is a **neutral WebSocket broker** — it never signs a quote, never sets a price, and never holds funds. All pricing comes from competing MMs; settlement is enforced on-chain.

**Last look** applies only when the winning MM opted into it at auth time — it is a per-MM setting, not a protocol-wide guarantee. If the winner does not have last look enabled, the trade proceeds straight to signing.

**Fill and settlement are two different, non-adjacent events.** Fill/execution (the `createParlayWithPermit` call above) happens immediately once a quote is accepted, and both sides are actively notified over their WebSocket connection. Settlement — when a leg's outcome resolves and the pot is actually paid out — happens later, gated by that outcome's own resolution plus a dispute window, which can be hours or longer after the fill. **There is currently no proactive push notification when a parlay settles.** The only settlement-adjacent push is scoped to the [cashout](/mute.sh/integration-guides/cashout.md) feature (a periodic refresh of a taker's live buyout offer); it is not a general settlement notification. To check whether a parlay has settled and what it paid, poll the positions endpoint or watch the escrow's settlement events on-chain directly — see the [Taker Guide](/mute.sh/integration-guides/taker-guide.md) for the exact endpoint.

***

## Where to Start

| I am a…                                                                                       | Start here                                                        |
| --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| **Market Maker** — I want to quote parlays and earn the spread                                | [Market Maker Guide](/mute.sh/integration-guides/maker-guide.md)  |
| **Taker** — I'm building a UI or bot that submits parlays                                     | [Taker Guide](/mute.sh/integration-guides/taker-guide.md)         |
| **Liquidity Provider** — I want to deposit into the pooled house book and earn the maker edge | [Liquidity Vault](/mute.sh/integration-guides/liquidity-vault.md) |
| **Builder** — I'm embedding Parlay and want protocol fee splits                               | [Builder Guide](/mute.sh/integration-guides/builder-guide.md)     |
| **Integrator** — I need the full WebSocket event schema                                       | [WebSocket Events](/mute.sh/reference/ws-events.md)               |
| **Market Maker (SDK)** — I want the exact, code-verified `/v2/ws/rfq` wire contract           | [Maker Protocol Spec](/mute.sh/reference/maker-protocol-spec.md)  |

***

## Key Concepts

**RFQ** — A Taker broadcasts a parlay spec to all registered Market Makers simultaneously. MMs are not obligated to respond; competition drives price improvement.

**ParlayQuote** — The EIP-712 typed-data structure an MM signs to commit to a quote. Contains ten fields: `maker`, `taker`, `legsHash`, `takerCollateral`, `makerCollateral`, `builder`, `protocolFeeBps`, `builderFeeBps`, `nonce`, and `deadline`. Verified on-chain before settlement.

**ParlayOrder** — The Taker's countersignature accepting a specific `ParlayQuote`. The escrow requires both signatures — neither alone can trigger a fill.

**legsHash** — A `keccak256` commitment over the ordered array of `ParlayLeg{outcomeId, sideIndex}` struct hashes. The RFQ, the quote, and the on-chain escrow all reference this hash as the canonical parlay identity.

**condition\_id** — The RFQ-side name for the same value as `legsHash`: before hashing, a combo's legs are canonicalized (sorted and de-duplicated) so that `condition_id` and the on-chain `legsHash` can never diverge for the same set of legs. The relay also rejects malformed or contradictory combos (e.g. betting both sides of the same outcome, two legs from the same market, or a dead/unrecognized leg) before any Market Maker ever sees the RFQ. See the [Maker Protocol Spec](/mute.sh/reference/maker-protocol-spec.md) for the full combo-identity and conflict-check rules.

**quoteHash** — The EIP-712 struct hash of the full `ParlayQuote`. The Taker signs `ParlayOrder.quoteHash` to commit to exactly that maker's terms. Neither relay nor taker can alter terms after signing.

**Standing allowance** — An EIP-2612 permit or pre-approved USDC allowance that lets the escrow pull Taker funds at settlement without a separate approval transaction.

**Last look** — A brief window (configurable per-MM) after a Taker accepts a quote during which the MM may withdraw. Protects MMs from latency arbitrage.

**Builder code** — A short identifier (e.g. `"mute"`) embedded in each ParlayQuote that routes protocol fee splits to a registered builder address.

**Liquidity Vault (mpMV)** — The pooled house book: deposit USDC into one shared pool that acts as a market maker on the venue, posting the maker collateral on parlays it backs. Losing parlays pay the pool and the pricing edge accrues to the mpMV share price. See the [Liquidity Vault](/mute.sh/integration-guides/liquidity-vault.md) guide.

***

## Contract Addresses

| Contract                                        | Address                                      | Network                |
| ----------------------------------------------- | -------------------------------------------- | ---------------------- |
| ParlayEscrow v2 (production)                    | `0x551D4A7EdB71583C7C12900128727D857e308925` | HyperEVM Testnet (998) |
| ParlayMakerVault — pooled LP maker, `mpMV`      | `0x802b6aFf1B498E9Cd88C3E3a1c84395cd1ab0B1f` | HyperEVM Testnet (998) |
| ResolutionRegistry                              | `0xD265d327c463B1e4268daE583aBeEc2934b80Ed8` | HyperEVM Testnet (998) |
| SignalConsensus (CRE receiver, workflow-pinned) | `0xB98dbcAC440FcEa04Bbd61487e39DE8daDbE3e99` | HyperEVM Testnet (998) |
| ResolutionRequester (CRE LogTrigger)            | `0xbC0DcFD00b1583f83160eb233D6CC2Ae93D1c1Bc` | HyperEVM Testnet (998) |
| ParlayEscrow (demo, multi-maker)                | `0xBCB080AE14b7AA9181456D9786d9AFCFF4a57669` | HyperEVM Testnet (998) |
| USDC (EIP-2612)                                 | `0x75b69d0E8fA3CdB644b0f069E4e876B85A76E137` | HyperEVM Testnet (998) |

{% hint style="info" %}
**v2 vs demo:** The production v2 relay at `parlay.mute.sh` uses the v2 escrow (`0x551D4A7E…`): owner-config `spreadBps`, trustless secondary-market cashout (novation — see [Cashout](/mute.sh/integration-guides/cashout.md)), and gasless claiming via EIP-712 `withdrawWithSig`. Resolutions are published EXCLUSIVELY by the pinned Chainlink CRE workflow (SignalConsensus → ResolutionRegistry). The demo escrow (`0xBCB0…`) is used in the local simulation only. The escrow address rotates on redeploys — always read the current address from the relay's `ready`/`prepare` payloads instead of hardcoding it. The live vault address is likewise served by `GET /v1/vault`.
{% endhint %}

***

## Running the Demo

{% hint style="info" %}
The demo is available to registered integration partners. Contact the mute.sh team to get access to the relay demo repo.
{% endhint %}

Once you have the repo, the v2 demo orchestrator spins up a local Relay, registers simulated MMs, and walks a full RFQ cycle over the taker WebSocket protocol — create → quotes stream in → best quote picked → prepared → signed → accepted:

```sh
# default: 5 simulated market makers, flow-shape only (no funding, no on-chain tx)
bun run demo:v2

# scale to 8 market makers to observe competitive quote selection
NUM_MMS=8 bun run demo:v2

# funded mode: mints testnet USDC and targets a real on-chain fill
E2E_FUND=1 RELAYER_PK=0x… bun run demo:v2
```

In flow-shape mode (the default), output shows each MM's signed quote, the winning selection, and the Taker countersignature, proving the auction reached the on-chain funding gate. In funded mode (`E2E_FUND=1`), it also shows the resulting on-chain transaction hash.

***

## External References

* [HyperLiquid Info API](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint) — market metadata, outcome prices, fill history
* [EIP-712](https://eips.ethereum.org/EIPS/eip-712) — typed structured data hashing and signing
* [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) — permit extension for ERC-20 (gasless standing allowance approvals)


---

# 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/readme.md?ask=<question>&goal=<endgoal>
```

`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.