Maker taker fees
In the context of liquidity and marketplaces, maker and taker fees are charges imposed by the exchange or trading platform on users who engage in buying and selling assets.
Maker: A maker is a user who places an order on the marketplace that does not get executed immediately but instead rests on the order book, waiting for another user to take the other side of the trade. Makers add liquidity to the market by creating orders that can be executed in the future. Typically, maker fees are lower than taker fees. This is done to encourage users to contribute to the liquidity of the market by placing orders that remain on the order book.
Taker: A taker is a user who places an order that instantly matches with an existing order on the order book, effectively "taking" liquidity from the market. Takers are charged higher fees compared to makers because they execute orders immediately, thereby reducing the available liquidity in the market.
Maker and taker fees serve multiple purposes. They are a common revenue-generation mechanism for exchanges, helping to cover operational costs and generate profits. Additionally, these fee structures incentivize users to act in ways that promote market liquidity, increase trading volume, and maintain a healthy and active marketplace.
This fee structure helps to promote market efficiency by incentivizing users to add liquidity to the market, which can help to reduce spreads and increase trading volume. It also ensures that buyers are only paying for the service they are actually receiving, which helps to increase transparency and build trust between users and their marketplaces.
Maker taker fees in the orders API v3:
Marketplaces charge maker or taker fees to cover their operational costs and generate revenue for providing a service.
The fee charged by the maker's marketplace for adding liquidity will be a maker type fee.
The fee charged by the taker's marketplace for removing liquidity will be a taker type fee.
Maker taker fees information and breakdowns on order are now available as their own separate fields in the new getOrder(s) v3 endpoints.
Marketplaces have the flexibility to tailor the user journey for their clients in a way that they believe offers the best experience. Specifically, for traditional sell orders, marketplaces can provide two distinct user experiences:
Maker Sets Price They Will Receive (Recommended): In this approach, the maker (seller) specifies the price they anticipate receiving for the asset. To account for maker fees, the base price of the order is set higher than the seller's entered price. This option prioritizes the seller's experience by allowing them to receive their specified price. However, it's worth noting that the total transaction price for the buyer may result in an odd decimal when all fees are considered (e.g., 0.0205 ETH).
If this user journey is adopted the marketplace should do the following - see example 1 below:
- Seller's entered price should be used in the field
maker_fees.quantity_with_fees - Marketplace should calculate the base listing price as
buy.quantity=maker_fees.quantity_with_fees+maker_fees.amount
Maker Sets the Base Price: Here, the maker (seller) sets the base price of the order, which is the price they expect to receive after subtracting the maker fee. The total transaction price will be higher than the base price, potentially resulting in an odd decimal for the buyer when all fees are factored in (e.g., 0.0205 ETH).
If this user journey is adopted the marketplace should do the following - see example 2 below:
- Seller's entered price should be used in the field
buy.quantity - Marketplace should calculate the price the seller will receive as
maker_fees.quantity_with_fees=buy.quantity-maker_fees.amount
The final transaction price will be higher than the base price as it will include the taker and protocol fee.
Immutable's platform supports these user experiences, and others, provided the fees calculated on the marketplace front end and entered into Immutable's orderbook correctly with the below script.
Please be advised that all fees and quantities within our system are denoted in the smallest unit of the respective currency, and decimal representations are not supported.
For instance, IMX, which has 18 decimal places, will have a fee of 0.000000000000000001 IMX represented as "1".
Similarly, 1 IMX is represented as "1000000000000000000" in our system.
Example 1: Maker Sets Price They Will Receive - 1 ETH
{
...,
"sell": {
"type": "ERC721",
"data": {
"quantity": "1",
// DEPRECATED "quantity_with_fees": "",
...
}
},
"buy": {
"type": "ETH",
"data": {
"token_address": "ETH",
"quantity": "10100000000", // This is the base price, for regular listings the maker will receive less than this, for bids the maker pays more than this
// DEPRECATED "quantity_with_fees": "",
...
}
},
// DEPRECATED "fees": [],
"maker_taker_type": "maker",
"maker_fees": {
"quantity_with_fees": "10000000000", // This is the maker's entered price, they will receive this amount
"token_type": "ETH",
"decimals": 18,
"symbol": "ETH",
"fees": [] // array of fees, e.g. seller marketplace fee
},
"taker_fees": {
"quantity_with_fees": "10500000000",
"token_type": "ETH",
"decimals": 18,
"symbol": "ETH",
"fees": [ // array of fees, e.g. protocol, royalty, and buyer marketplace fees
{
"type": "maker",
"address": "0x123",
"token": {
"type": "ETH",
"data": {
"decimals": 18
}
},
"amount": "100000000"
},
{
"type": "protocol",
"address": "0x123",
"token": {
"type": "ETH",
"data": {
"decimals": 18
}
},
"amount": "200000000"
},
{
"type": "royalty",
"address": "0x123",
"token": {
"type": "ETH",
"data": {
"decimals": 18
}
},
"amount": "100000000"
},
{
"type": "taker",
"address": "0x123",
"token": {
"type": "ETH",
"data": {
"decimals": 18
}
},
"amount": "100000000"
}
]
}
}
Example 2: Maker Sets the Base Price - 1 ETH
{
...,
"sell": {
"type": "ERC721",
"data": {
"quantity": "1",
// DEPRECATED "quantity_with_fees": "",
...
}
},
"buy": {
"type": "ETH",
"data": {
"token_address": "ETH",
"quantity": "10000000000", // This is the maker's entered price (i.e. the base price), for regular listings the maker will receive less than this, for bids the maker pays more than this
// DEPRECATED "quantity_with_fees": "",
...
}
},
// DEPRECATED "fees": [],
"maker_taker_type": "maker",
"maker_fees": {
"quantity_with_fees": "9900000000", // For regular listings the maker will receive this amount, for bids the taker will receive this amount
"token_type": "ETH",
"decimals": 18,
"symbol": "ETH",
"fees": [ // array of fees, e.g. seller marketplace fee
{
"type": "maker",
"address": "0x123",
"token": {
"type": "ETH",
"data": {
"decimals": 18
}
},
"amount": "100000000"
}
]
},
"taker_fees": {
"quantity_with_fees": "10400000000", // This is the total transaction price, for regular listings the maker will receive less than this, for bids the maker will pay this amount
"token_type": "ETH",
"decimals": 18,
"symbol": "ETH",
"fees": [ // array of fees, e.g. protocol, royalty, and buyer marketplace fees
{
"type": "protocol",
"address": "0x123",
"token": {
"type": "ETH",
"data": {
"decimals": 18
}
},
"amount": "200000000"
},
{
"type": "royalty",
"address": "0x123",
"token": {
"type": "ETH",
"data": {
"decimals": 18
}
},
"amount": "100000000"
},
{
"type": "taker",
"address": "0x123",
"token": {
"type": "ETH",
"data": {
"decimals": 18
}
},
"amount": "100000000"
}
]
}
}
New maker taker fields and the deprecation of quantity_with_fees in buy and sell
The maker_taker_type, buy.type and sell.type fields can be used to determine if the order is a listing (i.e. trader selling an asset) or a bid (i.e. trader requesting to buy an asset)
If maker_taker_type= maker and sell.type=ERC721 the order represents a trader selling an NFT (listing).
If maker_taker_type= maker and buy.type=ERC721 the order represents a trader requesting to buy an NFT (bid).
Depending on whether an order is a listing or a bid, price can be calculated with the below formulas:
listing_price = taker_fees.quantity_with_fees of maker_sell_order
bid_amount = maker_fees.quantity_with_fees of maker_buy_order
Immutable strongly recommends marketplaces break down the associated fees to promote transparency in the ecosystem.
Please be advised that all fees and quantities within our system are denoted in the smallest unit of the respective currency, and decimal representations are not supported.
For instance, IMX, which has 18 decimal places, will have a fee of 0.000000000000000001 IMX represented as "1".
Similarly, 1 IMX is represented as "1000000000000000000" in our system.
For traditional listings (i.e. Sell Orders)
- Marketplaces will use
taker_fees.quantity_with_feesto display their total listing prices for traditional listings (i.e. sell orders). This is what the taker (buyer) would pay for the listed asset. maker_fees.quantity_with_feesrepresents the amount the maker (seller) would receive when the trade is executed (including fees). This is usually quoted in a ERC20 token (e.g. IMX) or ETH.
For bid listings (i.e. Buy Orders)
- Marketplaces will use
maker_fees.quantity_with_feesto display their total price for bids (i.e. buy orders). This is what the maker (buyer) would pay for the requested asset. taker_fees.quantity_with_feesrepresents the amount the taker would receive when the trade is executed (including fees). This is usually quoted in a ERC20 token (e.g. IMX) or ETH.
Example of calculating a listing price from an API response:
{
"sell":{
"type":"ERC721",
"data":{
"quantity": "1",
...
}
},
"buy":{
"type":"ERC20",
"data":{
"quantity": "500000000000000000",
...
}
},
"maker_taker_type": "maker",
"maker_fees":{
"quantity_with_fees":"495000000000000000",
"token_type":"ETH",
"decimals":18,
"symbol":"ETH",
"fees":[
{
"type":"maker",
"address":"0x1111",
"token":{
"type":"ETH",
"data":{
"decimals":18
}
},
"amount":"5000000000000000"
}
]
},
"taker_fees":{
"quantity_with_fees":"520000000000000000",
"token_type":"ETH",
"decimals":18,
"symbol":"ETH",
"fees":[
{
"type":"taker",
"address":"0x2222",
"token":{
"type":"ETH",
"data":{
"decimals":18
}
},
"amount":"5000000000000000"
},
{
"type":"royalty",
"address":"0x2222",
"token":{
"type":"ETH",
"data":{
"decimals":18
}
},
"amount":"5000000000000000"
},
{
"type":"protocol",
"address":"0x2222",
"token":{
"type":"ETH",
"data":{
"decimals":18
}
},
"amount":"10000000000000000"
}
]
}
}
So, the listing price can be broken down into:
base_price = 0.5 Eth
# (2% protocol, 1% royalty and 1% taker marketplace fee)
taker_fees = 0.01 Eth + 0.005 Eth + 0.005 Eth = 0.02 Eth
# taker_fees.quantity_with_fees of the sell order
listing_price = base_price + taker_fees = 0.5 Eth + 0.02 Eth = 0.52 Eth
However, the amount that the seller would receive is 0.495 Eth (0.5 Eth - 1% maker marketplace fee) which is what is displayed under taker_fees.quantity_with_fees.
Example of calculating a bid amount from an API response:
{
"sell":{
"type":"ERC20",
"data":{
"quantity": "500000000000000000",
...
}
},
"buy":{
"type":"ERC721",
"data":{
"quantity": "1",
...
}
},
"maker_taker_type": "maker",
"taker_fees":{
"quantity_with_fees":"495000000000000000",
"token_type":"ETH",
"decimals":18,
"symbol":"ETH",
"fees":[
{
"type":"taker",
"address":"0x1111",
"token":{
"type":"ETH",
"data":{
"decimals":18
}
},
"amount":"5000000000000000"
}
]
},
"maker_fees":{
"quantity_with_fees":"520000000000000000",
"token_type":"ETH",
"decimals":18,
"symbol":"ETH",
"fees":[
{
"type":"maker",
"address":"0x2222",
"token":{
"type":"ETH",
"data":{
"decimals":18
}
},
"amount":"5000000000000000"
},
{
"type":"royalty",
"address":"0x2222",
"token":{
"type":"ETH",
"data":{
"decimals":18
}
},
"amount":"5000000000000000"
},
{
"type":"protocol",
"address":"0x2222",
"token":{
"type":"ETH",
"data":{
"decimals":18
}
},
"amount":"10000000000000000"
}
]
}
}
In conjunction, the bid amount can be broken down into:
base_price = 0.5 Eth
# (2% protocol, 1% royalty and 1% maker marketplace fee)
maker_fees = 0.01 Eth + 0.005 Eth + 0.005 Eth = 0.02 Eth
# maker_fees.quantity_with_fees of this buy order
bid_amount = base_price + maker_fees = 0.5 Eth + 0.02 Eth = 0.52 Eth