BSIP81: Simple Maker-Taker Market Fees

[abitmore]

BSIP: 0081
Title: Simple Maker-Taker Market Fees
Author: Abit More <https://github.com/abitmore>
Status: Draft
Type: Protocol
Created: 2019-10-02
Discussion: https://github.com/bitshares/bsips/issues/229
Worker: TBD

Abstract

BSIP67 proposed a mechanism which has maker-taker fees in consideration, but it's relatively complex.

This BSIP proposes a protocol change to enable asset owners to specify different market fee rate for maker orders and taker orders.

Motivation

Asset owners need tools to incentivize trading of their assets.

Rationale

Maker-taker fee model is adopted widely in centralized exchanges and helped them to attract trading activities.

Specification

There is already a flag market_fee_percent in asset options.

Add a new flag taker_fee_percent into asset options, assign market_fee_percent to taker_fee_percentage at the consensus upgrade time for existing assets. The new flag can only be set or updated by asset owners after the consensus upgrade.

Before the consensus upgrade, when an order buying that asset got filled, the amount bought_amount * market_fee_percent will go to the asset's accumulated fees.

After the consensus upgrade, when an order buying the asset got filled,

• if the order is a maker, the amount bought_amount * market_fee_percent will go to the asset's accumulated fees;
• otherwise (if the order is a taker), the amount bought_amount * taker_fee_percent will go to the asset's accumulated fees.

Copyright

This document is placed in the public domain.

[abitmore]

@ryanRfox please assign a BSIP number. Thanks.

[froooze]

This BSIP doesn't include the flat BTS market fee?
Can margin positions be excluded from taker fee?

[pmconrad]

This BSIP doesn't include the flat BTS market fee?

No.

Can margin positions be excluded from taker fee?

Margin positions do not pay market fees (neither maker nor taker). This BSIP does not propose to change that.

[bangzi1001]

Is that possible to allow Negative market_fee_percent such as -0.02% for maker? This allow asset owners provide incentive for market makers and decrease Bid Ask Spread.

[froooze]

@abitmore
Can you add a new variable to this BSIP ?

TAKE ORDER fee next to our PLACE ORDER ?

[abitmore]

-0.02% for maker

Technically, who will pay this? For example, in the GDEX.BTC : BTS market, GDEX.BTC is the asset that enabled market fee, where will the additional 0.02% come from?

[abitmore]

TAKE ORDER fee next to our PLACE ORDER ?

Doesn't it exactly this BSIP? You mean the 0.01 cent flat fee?

[froooze]

Doesn't it exactly this BSIP?

@pmconrad and I don't think so!

You mean the 0.01 cent flat fee?

Yes

[abitmore]

Can you add a new variable to this BSIP ?
TAKE ORDER fee next to our PLACE ORDER ?

You mean the 0.01 cent flat fee?

Yes

It does make some sense, but technically it's a totally different thing, I think it's best to create a new BSIP for it.

[sschiessl-bcp]

-0.02% for maker

Technically, who will pay this? For example, in the GDEX.BTC : BTS market, GDEX.BTC is the asset that enabled market fee, where will the additional 0.02% come from?

I like this. The restriction should be that the maker fee (reward) can be completely paid by the taker fee. And then of course, the maker reward is paid by taker fee.

[abitmore]

I like this. The restriction should be that the maker fee (reward) can be completely paid by the taker fee. And then of course, the maker reward is paid by taker fee.

You didn't understand the question. Maker fee is in asset A but taker fee is in asset B. Asset A's owner may have no right to set fee rates of asset B, nor increasing asset B's supply from nowhere.

[sschiessl-bcp]

I like this. The restriction should be that the maker fee (reward) can be completely paid by the taker fee. And then of course, the maker reward is paid by taker fee.

You didn't understand the question. Maker fee is in asset A but taker fee is in asset B. Asset A's owner may have no right to set fee rates of asset B, nor increasing asset B's supply from nowhere.

Ah, yes I did not have that in mind...

An implicit conversion makes no sense. The fee pool could be used (at the mercy of the asset owner certainly).

Define a maker/taker market fee, allow negative values. Negative values only mean "up to X", and are paid from fee pool, if balance is available. If not, it falls back to 0% market fee.

[abitmore]

paid from fee pool

A malicious user can wash trade to empty the pool with zero cost.

[sschiessl-bcp]

paid from fee pool

A malicious user can wash trade to empty the pool with zero cost.

Only if the maker fee (negative) is greater than the taker fee (positive).

[pmconrad]

If market_fee_percent < 0 && taker_fee_percent >= -market_fee_percent then it is possible to view the trade as two trades:

1. Trade happens as usual, possibly with slightly lower volume. Maker receives market fee in units of the other asset (the one sold by the maker).
2. Maker trades the newly earned fee for the other asset (the one bought by the maker), against the same taker order.

Combining this into one trade complicates things a little. Currently, database::match(limit_order_object, limit_order_object, price) distinguishes two cases by taker.amount_for_sale <= maker.amount_for_sale * match_price (i. e. if true taker will be filled completely, otherwise only maker will be filled completely). It then goes on to compute how much each side receives, and finally deducts the fee in database::fill_limit_order.

If market_fee_percent < 0, we must check taker.amount_for_sale <= maker.amount_for_sale * match_price * (1 - market_fee_percent). If so, the nominal trade volume must be adjusted to allow for the additional fee exchange. Finally, the fee exchange is part of the trade volume on the taker side, but not on the maker side.

Pseudocode (only for market_fee_percent < 0):

if( taker.amount_for_sale <= maker.amount_for_sale * match_price * (1 - market_fee_percent) )
{
taker_pays = taker.amount_for_sale;
taker_receives = taker.amount_for_sale * match_price;
taker_fee = taker_receives * taker_fee_percent;
maker_receives = taker.amount_for_sale / (1 - market_fee_percent);
maker_fee = taker_pays - maker_receives;
maker_fee_original = maker_fee * match_price;
ASSERT( maker_fee_original <= taker_fee );
maker_pays = taker_receives - maker_fee_original;
ASSERT(maker_pays <= maker.amount_for_sale);
taker_fee -= maker_fee_original;
}
else
{
maker_pays = maker.amount_for_sale;
maker_receives = maker_pays * match_price;
maker_fee = maker_receives * (-market_fee_percent);
maker_fee_original = maker_fee * match_price;
taker_pays = maker_receives + maker_fee;
ASSERT(taker_pays <= taker.amount_for_sale);
taker_receives = maker_pays + maker_fee_original;
taker_fee = taker_receives * taker_fee_percent;
}

In each case, the maker account is credited with maker_receives + maker_fee and the taker account is credited with taker_receives - taker_fee.

[abitmore]

paid from fee pool

A malicious user can wash trade to empty the pool with zero cost.

Only if the maker fee (negative) is greater than the taker fee (positive).

@sschiessl-bcp please reread/rethink:

Maker fee is in asset A but taker fee is in asset B.

That said, B can be any other asset (E.G. BTS who has a zero market fee). If A's maker fee is negative, an attacker can put up an order to buy an amount of A with an amount of BTS, then dump the same amount of A onto the order, then he as the maker will get more A asset than he originally owned, by paying nothing (note: for simplification the order creation fee is ignored here).

Because currently the market engine is not working like you imagined. Currently the market fees are deducted after the orders got filled but not before, a.k.a. receiver pays the fee. Of course it can be changed (with greater efforts and worth a new BSIP), E.G. when an order is placed, pre-deduct the market fees first if the fee rate is positive, then use the remaining amount to match and fill, a.k.a. payer pays the fee. With this, a portion of that fee can go to the other side as a compensation or incentive, which is effectively a negative fee rate. In addition, the receiver can still pay another fee.

Essentially, as Peter described, a negative fee is a shift on match price, which muddy the waters.

[sschiessl-bcp]

Thanks for the detailed explanations!

I like the notion of "paying" makers implicitly through the trade. What do you think of allowing the asset owner to define similar to market fee sharing, but it's called maker reward, which is handled in the same way?

If the maker pays the market fee itself, it's a reduction of market making costs, if the taker pays the market fee, it's "income" for the maker. This favors one market direction though.

[abitmore]

@sschiessl-bcp I'm not sure if you've understood it -- the fee is in one asset. By the way you can take a look at this post about negative fees: https://bitsharestalk.org/index.php?topic=20482.msg265142#msg265142 .

[sschiessl-bcp]

@sschiessl-bcp I'm not sure if you've understood it -- the fee is in one asset. By the way you can take a look at this post about negative fees: https://bitsharestalk.org/index.php?topic=20482.msg265142#msg265142 .

My last suggestion accounts does not assume the fee is present in different assets. A fixed cut of market fee can be set which goes to the makers, just like market fee sharing. Asset owner can already decide to reward referrers, and with this suggestion also makers in his markets.

[abitmore]

Also read this: https://bitsharestalk.org/index.php/topic,20376.msg262560.html#msg262560

[abitmore]

Draft merged in #231. Closing the issue.