> 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/api/api-reference/liquidity-rewards.md). # Liquidity Rewards (Enterprise) > **Early access.** The rewards engine is rolling out to Enterprise design partners. Email to run a program. The API surface below is the target shape and may change before general availability. Run a liquidity mining program on your own builder code — without building the measurement, anti-abuse, or payout layer yourself. You fund a reward pool in USDC and define the campaign (which markets, which dates, how the pool splits). mute computes the scoring from the chain itself, keyed to fills that carry **your builder attribution**, filters out wash and self-match activity, publishes a live leaderboard your app can render, and produces the per-wallet payout file each cycle. ## Why builders run one Reward programs are the proven way to bootstrap a market: subsidized liquidity tightens the book, tighter books attract takers, and taker flow through your front-end is what earns your builder fee. Because HIP-4 charges the builder fee when positions are **sold**, rewarding entry-side liquidity doesn't cannibalize your fee revenue — it manufactures the positions whose eventual exits pay it. The catch has always been operations: measuring "useful" liquidity honestly, catching wash trading, and paying out correctly, per wallet, per day. That's the part mute runs. ## How a campaign is structured A campaign is a budget applied over a set of markets and a time window, split across two reward legs: | Leg | What it rewards | Default share | | ---------------------- | ------------------------------------------------------------------------ | ------------- | | **Maker fill rewards** | Resting orders that get filled — realized, not just displayed, liquidity | 50% | | **Taker fill rewards** | Market participation — the flow that makes makers quote | 50% | Within each leg, rewards distribute pro-rata by score per payout cycle (daily, or per event window for sports markets — e.g. kickoff through final whistle). Scoring levers you configure per campaign: * **Eligible price band** — fills outside a probability band (e.g. 1¢–99¢) score zero, so nobody farms rewards on decided markets. * **Two-sided multiplier** — wallets whose maker flow is balanced across bid and ask earn a multiplier over one-sided quoting (up to 3×). * **Live multiplier** — for sports markets, weight fills during active play (mute knows the match state — see [Sports](/mute.sh/api/api-reference/sports.md)). * **Minimum notional** — a floor below which activity doesn't score, to keep dust farming out. ## What mute enforces Every score is computed from the canonical fill stream, with the plumbing your users never see: * **Builder-code gating** — only fills attributed to your builder count. Attribution comes from the chain, not self-reporting. * **Real trades only** — AMM mechanics (`Negate Outcome`, `Split Outcome`, `Merge`, settlement legs) are excluded from scoring automatically. * **Wash and self-match exclusion** — both sides of a self-match are detected and zeroed, and related-wallet clusters are flagged for review before payout. * **Market-maker classification** — you decide whether professional MM flow shares the same pool as retail or gets its own. ## The API surface (early access) Campaigns expose a read API under your Enterprise key, designed to be rendered directly in your app: * `GET /v1/rewards/campaigns` — your campaigns and their status * `GET /v1/rewards/campaigns/:id/leaderboard` — live per-wallet scores and projected pool share for the current cycle * `GET /v1/rewards/campaigns/:id/wallet/:address` — one wallet's score breakdown (maker/taker legs, multipliers applied, excluded fills) * `GET /v1/rewards/campaigns/:id/payouts` — finalized per-cycle payout files Webhook events (`reward.cycle.finalized`, `reward.leaderboard.updated`) ride the same delivery infrastructure as the rest of [Webhooks](/mute.sh/api/api-reference/webhooks-telegram-and-account.md) — signed, logged, replayable. ## Running a program 1. **Scope** — you pick markets, dates, budget, and scoring levers with us; we sanity-check the economics against live volume in those markets. 2. **Launch** — leaderboard endpoints go live under your key; you point your rewards page at them. 3. **Pay out** — each cycle you receive the finalized payout file; you settle in USDC on Hyperliquid (or we can operate payouts as a managed service). Pricing is a program fee scoped to campaign size — email with the markets you want to incentivize and a rough budget, and a founder will reply within one business day. --- # 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/api/api-reference/liquidity-rewards.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.