Maker-taker fees and VIP tiers: how a crypto exchange builds its fee schedule

A crypto exchange's fee schedule is a published table: for each VIP level, a maker rate for orders that rest on the book and a usually higher taker rate for orders that fill at once. A customer's level is set by their trading volume over the last 30 days, recalculated as they trade, and the right rate is applied to every fill without anyone typing it in. In a well-run exchange, two controls sit behind it: every schedule has a version number, and a new one goes live only after a second person approves it.

This guide covers how the schedule is built and applied. How fees fit into an exchange's revenue, next to spreads, withdrawals and other lines, is in the guide to how crypto exchanges make money. All rates and thresholds below are illustrative, chosen to show the mechanism, not market rates or any exchange's prices.

Maker or taker: why the two are priced differently

Every trade on an order book has two sides. The maker placed an order that rested on the book, waiting at its price. The taker sent an order that matched it straight away. The matching engine knows which was which at the moment of the fill, because the resting order was there first.

Exchanges usually charge makers less. Resting orders are what give the book depth and a tight spread, and that is what brings takers in. Takers pay for immediacy: they get filled now, at a price someone else offered.

One order can be both. A limit order to buy at a price that is already on offer fills at once against the resting sellers, as a taker, and whatever is left rests on the book and later fills as a maker. A market order is almost always a taker. So the fee is decided per fill, not per order.

The fee schedule: one table, with a version number

The schedule is data, not code. In its simplest form it is a list of levels, each with a volume threshold and two rates. An illustrative one:

Some exchanges write each level as a discount off a market's own maker and taker rate instead, so one schedule works across markets with different base rates. Either way, the levels go up in volume, and a customer sits at the highest level whose threshold they have reached.

Each published schedule gets a version number, and old versions are kept, never edited. That matters later: a fee charged in March can be explained by the version in force in March, even after the rates have changed twice. A schedule that can be overwritten in place leaves no answer to the question "why was this customer charged that?".

VIP levels from 30-day rolling volume

A customer's fee tier comes from how much they traded over the last 30 days. The window rolls: each day, the oldest day drops out and the newest comes in, so a level is earned continuously and can be lost the same way. A customer who traded heavily in one week and then stopped slides back down as those days leave the window.

The design questions are concrete:

• What counts. Usually both sides of each trade the customer was part of, maker or taker, valued in one currency so that a bitcoin trade and an ether trade add up.

• When it updates. After every trade, so a customer who crosses a threshold gets the better rate on their next order, not next month.

• What to leave out. Trades a customer makes against their own orders add volume without risk. Counting them would reward wash trading, so operators decide how such trades are treated in the volume and flag them to surveillance.

How the right rate reaches each order

Nobody looks up a rate by hand. In a typical design, the flow runs like this:

1. The level is ready. A fees service keeps each customer's 30-day volume and current level, and the published schedule.

2. The order is placed. The trading service reads the customer's level and records the maker and taker rates that apply onto the order itself.

3. Each fill is charged. When the order matches, the fill's role picks the rate: maker or taker. The fee is calculated on the fill's value and booked on the ledger with the trade.

4. The volume moves. The trade adds to the customer's 30-day volume, and if a threshold is crossed, the next order is priced at the new level.

Fixing the rates on the order when it is placed means a resting order is charged what the customer was shown, even if the level changes before it fills. A sensible default also matters: if the level cannot be read, the order goes through at the standard rate rather than being blocked, because a discount is a courtesy, not a control.

A worked example, with the illustrative schedule above. A customer has traded €480,000 in the last 30 days, which puts them at VIP 1: 0.10% maker, 0.17% taker. They place a limit order to buy €30,000 of bitcoin at a price that is partly on offer.

• €12,000 fills at once, against resting sellers, as a taker: 0.17% is €20.40.

• €18,000 rests on the book and fills later, as a maker: 0.10% is €18.00.

• The fee in total is €38.40, and nobody typed a rate.

• Their volume is now €510,000, past the €500,000 line, so their next order is priced at VIP 2.

You can see this in Marengo, our exchange: its fee schedule is published and versioned, a customer's 30-day rolling volume sets a maker and taker discount, and each order is priced at the discounted rate automatically.

Two people before a new schedule goes live

A fee change touches every customer at once, so it is made like a payment above a limit: one person prepares it, a second approves it. This is often called maker-checker (the "maker" here is the person who proposes, nothing to do with maker fees).

1. Propose. A staff member drafts the new schedule against the current version, with a reason.

2. Check. A different staff member reviews it and approves or rejects it, with their own note. The system refuses an approval from the person who proposed it.

3. Publish. Only the approval publishes the schedule, as the next version, and every step is kept in the audit trail.

4. Guard against races. If the schedule changed while a proposal waited, the old proposal cannot be approved over it; it has to be redone against the new version.

The point is not distrust. It stops a mistyped rate reaching every order book at once, and it gives the operator a record of who changed pricing, when and why, which is what a compliance lead or an auditor asks for first. The admin backoffice is where both steps happen. In Marengo, a new schedule goes live only after a second staff member approves it, and customers see the result on a "Fees and VIP levels" page.

What customers see

The schedule only works if customers can find it and check it against what they paid. Three places carry it:

• A fees page. Every level with its threshold and rates, the customer's own 30-day volume and level, and how far they are from the next one.

• The order ticket. Before an order is sent, the maker and taker rates that will apply. On a limit order the ticket cannot know which part will fill as which, so it shows both, or an estimate.

• The receipt. After each fill, the fee actually charged, in which currency, and whether that fill was a maker or a taker.

When a customer asks why their fee changed, those three should answer it without a support ticket: the level they were at, the version in force, and the role of each fill.

Publishing fees under MiCA

In the EU, the Markets in Crypto-Assets Regulation (MiCA) makes publishing the schedule a legal duty, not a courtesy. This is general information, not legal advice. Every crypto-asset service provider (CASP) must "make their policies on pricing, costs and fees publicly available, in a prominent place on their website" (Article 66(4)), and the information it gives clients must be fair, clear and not misleading (Article 66(2)).

For an exchange that runs an order book, MiCA adds a rule on the shape of the fees themselves. Fee structures must be "transparent, fair and non-discriminatory" and must not create incentives to place, modify or cancel orders, or to trade, in a way that contributes to disorderly trading or market abuse (Article 76(13)).

A published, versioned schedule fits both: the same levels for everyone who reaches the same volume, no side deals, and a record of every change. How volume is counted belongs in the same review, because a tier that counts self-trades is exactly the kind of incentive Article 76(13) is about. The MiCA checklist for a crypto exchange puts this next to the rest of the authorisation file.

Frequently asked questions

Can an order pay both a maker and a taker fee? Yes, on different parts. The part that fills at once is charged as a taker; the part that rests and fills later is charged as a maker. Each fill carries its own fee.

Does reaching a new VIP level change the fee on orders already resting on the book? In many designs, no. The rates are fixed on the order when it is placed, so a resting order is charged what the customer saw. The new level applies to the next order.

Why a rolling 30 days rather than a calendar month? A rolling window has no cliff on the first of the month. A customer's level reflects the last 30 days at any moment, and it falls gradually when they trade less, rather than all at once.

Can a large client be given a private rate? In the EU, an order book exchange's fee structures must be non-discriminatory, which is why operators tend to put large clients on published levels rather than on individual deals.

See it working

A fee schedule is easiest to judge from both sides: the customer's page and the staff member's approval queue. Open Marengo at marengo.paynoramic.com to see Lite and Pro, or read how our white-label crypto exchange is built and handed over to the licensed operator who runs it.