On this page
Liquidity rewards and maker rebates are separate Polymarket programs. The liquidity-rewards methodology concerns qualifying resting orders and relative scoring. The maker-rebate program concerns liquidity that actually executes in eligible fee-enabled markets.
Checked October 6, 2026. This guide explains the distinction with invented examples and an offline sample score calculator. It does not fetch a wallet, place quotes, or predict your payment. These documents concern international Polymarket; check the exact product and account eligibility separately.
Identify the program before comparing earnings
| Program | Activity to inspect | Separate accounting question |
|---|---|---|
| Liquidity rewards | Qualifying resting orders | Which scores and period apply? |
| Maker rebates | Executed maker liquidity | What eligible fee value and pool apply? |
| Trading results | Acquired and sold positions | What profit or loss did those positions create? |
A maker order can contribute to different records over its life. Keep the program's calculation, the actual fill, and the resulting inventory separate. A displayed reward estimate is not a complete profit-and-loss statement.
Read current liquidity settings
Each incentivized market specifies qualifying size, spread and allocation. The methodology samples relative scores across a UTC-day epoch; it is not simply a payment for raw filled volume. The old August crypto-TWAP allocation is explicitly marked ended in the current documentation.
Save the exact market, settings, period and check time. A past pool announcement and a current configuration are different pieces of evidence. If a page lists an ended allocation, do not add it to an estimate of available rewards today.
Also distinguish a minimum qualifying order size from a minimum payment. One controls whether an order meets the program's criteria; the other controls whether an earned amount is disbursed. Inspect both in the current rules rather than substituting one threshold for the other.
Explore a scoring sample
The liquidity score calculator takes hypothetical, already-qualified side totals and other makers' combined scores. Its default example has side scores of 90 and 60, an adjusted midpoint of 0.50 and other makers totaling 180. The sample Q min is 60 and the normalized share is 60 ÷ (60 + 180) = 25%.
These are invented inputs, not a live order book. The tool does not decide whether a particular quote qualifies. It also does not turn one sample into a daily payment. Use it to understand a response to changed assumptions, then inspect the actual program records separately.
If competitors' combined score doubles from 180 to 360 while your sample score stays 60, the share becomes 60 ÷ 420, or about 14.29%. Posting the same quote does not establish a fixed share when the comparison set changes.
Maker rebates use their own calculation
The current rebate guide describes daily pUSD payments, a $1 accrued minimum, and a fee-curve-weighted share within each eligible market. Rebate funding and eligibility vary by market category. Read that program's current parameters before extrapolating from an older percentage.
Executed volume and fee value are not necessarily proportional. Two fills with the same unit count can occur at different prices and contribute differently under a price-dependent curve. Record the exact program, fill price, size and applicable fee parameters before comparing rebate estimates.
A reward can coexist with a trading loss
Suppose an invented account earns $12 of incentives but realizes a $20 inventory loss and pays $3 in other costs. The combined result is $12 − $20 − $3 = −$11. The incentive is positive while the overall result is negative.
Resting quotes can fill after new information arrives. A strategy may gain an incentive while taking unwanted directional exposure. Use the market-making guide for inventory, adverse-selection and order-management context; this article focuses on interpreting the incentive records.
Keep a useful evidence trail
- Market identifier and program name.
- Current qualifying parameters and period.
- Actual orders, fills and inventory changes.
- Estimated, accrued and paid amounts as separate states.
- Trading gains, losses and all other costs.
An app's estimate, a program statement and a credited wallet amount should reconcile before you call a number received income. Do not infer a missing payment's cause from an order count alone. Ask the provider which criterion or payout stage applies.
For the broader data model, read the Polymarket API guide. For entry-cost interpretation, read Polymarket fees. Alphascope provides independent research and these illustrative calculations; the venue's rules and records determine actual rewards.