Fee rebates
A published share of the fees you actually paid, returned on a stated schedule and traceable to the fills that paid it.
Activity
Loading rewards
Claim fee rebates backed by settled fill fees, share a referral code that is fixed at signup, and track campaigns whose entire winner cap is reserved before activation.
Sign in to let the server check your settled fills and show only rebates backed by fees you actually paid.
Sign in to check rewardsSign in for your stable referral link, canonical campaign progress, and ledger-backed claim receipts. Registration alone never creates a payout.
Sign in to view campaignsA rebate names the fills whose fees it returns. A referral campaign records the qualified invite and its first settled trade. A trading campaign records the fill that crossed its target. Every payout is a balanced ledger transfer with a stable idempotency key.
Progress appears only for a campaign whose complete cap has already moved from realised house fees into the rewards reserve. There is still no points token, projected yield, or signup bounty: those would be different promises and do not exist here.
Every reward programme anywhere is the same five stages in the same order: something happens, something records it, a published rule prices it, a job applies that rule over a window, and a transfer pays it. Naming the five turns “not built yet” into a measurement. A stream that stops at the rate and a stream that stops before anything is recorded are not in the same situation, and one page saying “coming soon” about both would hide the difference.
A published share of the fees you actually paid, returned on a stated schedule and traceable to the fills that paid it.
Activity
The three fills below are illustrative. Their fees and fee assets are produced at render time by planMatch and planSettlement; the 10% share and round-down precision come from the server’s live rebate policy. Change either source and this walkthrough changes with it.
The 10% input comes from the live server policy
REWARD_REBATE_POLICY supplies the same basis-point share and 18-decimal, round-down rule used by the database claim. The fill fees below still come from the matching and settlement engine, so the walkthrough fails visibly if either policy changes.
Two buys and a sell on BTC/USDT, at the spot taker rate of 10 bps.
| Fill | Price | Fee charged on | Fee at 10 bps |
|---|---|---|---|
| Buy 0.5 BTC, market | 64,660.00 | 0.5 BTC | 0.0005 BTC |
| Buy 0.12 BTC, limit — filled | 64,612.10 | 0.12 BTC | 0.00012 BTC |
Every mechanism below runs in production at a venue you have heard of, and every one of them is designed to change a habit. A ladder priced in 30-day volume pays you to trade more. A referral cut pays you to recruit. A campaign with an expiry pays you to show up inside someone else’s window. That is not a scandal — it is what the budget is for. It is worth knowing which habit is being bought before deciding a reward was free.
| Mechanism | What it quietly costs you | Here |
|---|---|---|
| Volume tiersA rolling 30-day volume figure, recomputed on a schedule. Cross a threshold and your maker and taker rates drop until you fall back under it. | The discount is a fraction of the extra fees you paid to reach it. A ladder priced in volume is an incentive to trade more than you meant to, and it decays the moment you stop — that is the mechanism working, not failing. | Buildable, unbuiltEvery fill records its notional and its fee against an account. A 30-day total is a query nobody has written. |
| Token-balance discountsHold the venue’s own token, or pay your fees in it, and the rate falls again. | You take price risk on an asset you did not want in order to reduce a fee — and the venue sets both the size of the discount and the supply of the thing that earns it. |
Every member has one stable code. A valid code is written as part of the referred account’s registration transaction, and a database constraint proves it belongs to the inviter recorded beside it. There is no later “apply code” path and no edit path.
Registration itself pays nothing. Referral campaigns count an invite only when that account settles its first fill, and only when that first fill falls inside the published UTC window. The inviter then claims one reserved campaign slot through the same double-entry ledger as every other balance movement.
This does not claim to solve identity farming. Device fingerprinting, household policy, and referral-ring detection are not implemented, so operators should keep referral targets and caps narrow. The safer structural choice is already enforced: no active, fully reserved campaign means no referral payout.
Controls enforced today
Fills against the live venue book
Record
Every fill stores its fee and asset
Rate
10% since 2026-08-09 UTC
Accrual
Unclaimed settled fills, exact decimals
Payout
reward_rebate ledger transfer
What runs today
planSettlement records the exact fee and asset on each fill. claimFeeRebate selects settled fills after the published start, rounds 10% down at ledger precision, debits the matching house fee account, and credits the member’s spot wallet. reward_rebate_item.fill_id is unique, so one fill cannot pay twice.
Boundary / not included
There is no automatic push schedule, tier ladder, token conversion, or projected USD amount. Claims are member-initiated and bounded to 100 fills so the evidence and ledger movement stay reviewable.
A capped campaign credit for bringing someone whose first settled fill lands inside the campaign window — not a bounty for making accounts.
Activity
Stable code accepted only at signup
Record
Immutable inviter → invitee edge
Rate
Per-campaign amount and winner cap
Accrual
First settled fill qualifies the invite
Payout
Funded campaign claim transfer
What runs today
Every member has one referral_code. referral_attribution is inserted in the invitee’s registration transaction, rejects self-referral, and cannot be updated or deleted. A referral campaign counts only invitees whose first settled fill falls in its UTC window; a unique campaign/user claim and idempotent ledger key prevent a second payout.
Boundary / not included
Device fingerprinting, household rules, disposable-email detection, and referral-ring analysis are not implemented. That is why the product offers narrow, funded campaigns rather than a permanent open-ended percentage of referred fees.
A one-off credit for settling a published number of fills inside a UTC window, checked against canonical fill history rather than self-reported.
Activity
Settled fills are canonical
Record
Campaign terms and fill receipts
Rate
Fixed amount × funded winner cap
Accrual
Server recomputes window progress
Payout
One claim per campaign and user
What runs today
reward_campaign stores the activity, target, reward, full budget, winner cap and UTC window. Progress reads settled fills with ledger transfer ids, capped at the target. A unique claim row records the completion fill and payout transfer; ending the campaign returns only unclaimed reservation to house fees.
Boundary / not included
Only settled-fill counts and qualified-referral counts are supported. Deposit bounties, quizzes, first-order tasks, maker-only tasks, and arbitrary order-event rules need their own evidence semantics before an operator can publish them.
| Sell 0.37 BTC, market | 64,102.37 | 23717.8769 USDT | 23.7178769 USDT |
| Traded in the windowThe figure a volume tier would key on. Nothing here computes one. | 63,801.33 USDT | ||
Three fills, and already the fees are in two currencies. A fee is charged in the asset received, so a window of trading does not produce a fee total — it produces one total per asset, and a rebate over it is a basket of credits rather than a dollar figure. Any venue charging this way has the same problem; most of them hide it by converting at a rate they choose.
{
tradingAccountId: null,
asset: 'BTC',
bucket: 'fees',
amount: '0.0005',
}That is the leg planSettlement emits for the first fill, printed exactly as the engine hands it over. It is one of five legs in a single transfer, and postTransfer refuses to write any of them unless they sum to zero in every asset they touch.
A null trading account is how this ledger addresses a system account — the same construction a deposit uses to debit external. The fee is genuinely there, in a house account, in BTC. A validated reward claim can debit it only beside an equal credit to the member’s spot wallet.
One leg per fee asset, because that is the shape the fees arrived in.
| Fee asset | Collected | 10% of it | Credited | Left behind |
|---|---|---|---|---|
| BTCrounds at 18 dp | 0.00062 | 0.000062 | 0.000062 | 0 |
| USDTrounds at 18 dp | 23.7178769 | 2.37178769 | 2.37178769 | 0 |
The credit rounds down, which is the opposite direction from the fee that produced it. A fee rounds up so the house never absorbs the remainder; a payout has to round down for the mirror-image reason — rounding a credit up pays out of a pot slightly more than the pot was ever given, and at volume that shortfall appears in no report, because every individual overpayment looks like a rounding error.
Both assets use the ledger’s published 18-decimal precision rather than a market lot size. The BTC leg credits 0.000062 and leaves 0 behind. The USDT leg uses the same 18decimals and leaves 0, which is nothing at all. Historical claim rows keep both the source fee and credited amount, so a later policy change cannot rewrite the receipt.
A fill charges its fee and the fee lands in a ledger account with no owner. The rebate service now selects settled, unclaimed fills, rounds 10% down at ledger precision, and pays in the original fee asset from that same house account.
Every fill can appear in one rebate item only. A bounded claim handles at most 100 fills, locks the matching fee account, and refuses the whole basket if its source is underfunded. Replaying the same claim receipt cannot credit a fill twice.
The ledger currently has 28 explicit transfer kinds, including separate kinds for fee rebates and each campaign funding, claim, and refund movement.
These are policy choices enforced by the live claim path, not copy pasted onto the page. The walkthrough and the database service import the same share and precision, while the ledger proves the source and destination of each payment.
Ten percent of each settled fill fee. Not ten percent of notional, deposits, registrations, or an estimated dollar value.
Settled fills created from 2026-08-09 UTC onward remain eligible until claimed. Each pull claim handles the oldest 100 eligible fills and reports when more remain.
The original fee asset, separately for each asset in the claim basket. There is no conversion rate or token price hidden in the payout.
Each fill’s ten-percent share rounds down at the ledger’s 18-decimal precision. The source fee and credited amount are copied into the immutable claim evidence.
The matching house fee account for that asset. The server locks it and refuses the complete multi-asset basket if any leg is underfunded; it never posts a partial claim.
| Maker rebatesA negative maker fee. Post resting liquidity, and above a share-of-volume threshold the venue pays you rather than charging you. | This is the honest one: it pays for work genuinely done. It is also the tier retail almost never reaches, because the ladders are keyed to a share of total venue maker volume rather than to effort. | Not possible hereEvery order here is a taker against the venue’s book — resting limits included. Nothing you place is liquidity anyone can trade against. |
| Referral cutsA share of the referred account’s fees, attributed at registration, sometimes split with the person who was referred. | It is funded out of the fees your friend pays, itemised to neither of you. And because a signup triggers it, most of the programme is fraud detection — device fingerprints, disposable-email checks, referral-ring analysis — rather than payout. | Live in bounded formImmutable signup attribution and first-trade-qualified, fully funded campaigns are live. A permanent percentage of referred fees is not. |
| Task campaignsComplete a listed action inside a window — a first trade, a deposit, a quiz — and receive a fixed reward. | The window is short, the reward capped, and unclaimed rewards expire. An expiry turns a reward into a deadline, which is a different product from the one advertised. | Live in bounded formSettled-fill-count campaigns are live with canonical progress, funded winner caps, and one claim per user. Arbitrary tasks are not. |
| Launchpool and learn-to-earnStake an asset into a pool for the length of a campaign and receive a new token pro-rata, distributed continuously. | The headline value prices that token at a listing which has not happened. You commit capital now and find out what it paid after the market opens. | Not possible hereDistributing a token means holding one. This exchange custodies nothing. |
Three of the six cannot be built here, and not for want of time. There is no binXbase token, and there is no order book of our own — which happen to be the two things most reward programmes are made of. Fee rebates and capped campaigns are the mechanisms this build can fund from value its own ledger actually collected.
Every fill records the fee it was charged and the asset it was charged in, and your trade history reads both back per fill. Fee-rebate claims read these same rows, preserve them as claim evidence, and return the published share in the original asset.
Your orders and fillsOne taker rate on spot, one on perpetuals, no tiers and no maker rebate. The schedule is short because there are no discounts to describe, and the page says which charge applies to every action in the product.
The fee scheduleThe live campaign engine supports settled-fill counts and first-trade-qualified referrals. It does not award registrations, deposits, quiz clicks, arbitrary order states, lifetime fee shares, points, or a venue token. Adding one of those is a new funded policy and evidence model, not a label change on an existing campaign.
How the ledger proves movementsCampaign budgets use a dedicated rewards reserve. Creation also leaves enough in house fees to cover every unclaimed 10% rebate already earned in the same asset.