Closed abitmore closed 4 years ago
@ryanRfox please assign a BSIP number. Thanks.
This BSIP doesn't include the flat BTS market fee? Can margin positions be excluded from taker fee?
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.
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.
@abitmore Can you add a new variable to this BSIP ?
TAKE ORDER
fee next to our PLACE ORDER
?
-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?
TAKE ORDER
fee next to ourPLACE ORDER
?
Doesn't it exactly this BSIP? You mean the 0.01 cent flat fee?
Doesn't it exactly this BSIP?
@pmconrad and I don't think so!
You mean the 0.01 cent flat fee?
Yes
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.
-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 additional0.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.
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.
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.
paid from fee pool
A malicious user can wash trade to empty the pool with zero cost.
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).
If market_fee_percent < 0 && taker_fee_percent >= -market_fee_percent
then it is possible to view the trade as two trades:
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
.
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.
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.
@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 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.
Draft merged in https://github.com/bitshares/bsips/pull/231. Closing the issue.
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, assignmarket_fee_percent
totaker_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,
bought_amount * market_fee_percent
will go to the asset's accumulated fees;bought_amount * taker_fee_percent
will go to the asset's accumulated fees.Copyright
This document is placed in the public domain.