Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[Protocol3] New fee model and examples #197
New Fee Model Design
This fee is proportionally applied on every token transfer part of the trade. The protocol fee can be lowered by staking LRC. A different protocol fee can be used for maker orders and taker orders.
Different treatment of maker and taker orders
The ring-matcher chooses which order is the maker and which order is the taker.
Removal of the fee token
No more fee token/fee amount. The protocol fee is applied on the amount traded. A possible negative caused by this is that it's not possible to do fee payments in security tokens, NFTs, ... but we don't support these yet in protocol 3 anyway. Can be added back in a future version of the protocol when it makes sense.
Paid in the tokenB of the order. These are not taxed or do not have any other disadvantage. The order owner pays the fee to the ring-matcher respecting
feeBips's max value is 0.63% in steps of 0.01% (1 bips).
Users can decide if they want to buy a fixed number of tokens (a buy order) of if they want to sell a fixed number of tokens (a sell order). A buy order contains the maximum price the user wants to spend (by increasing amountS), a sell order contains the minimum price the users wants to get (by decreasing amountB). This allows us to do market orders. It only matters if an order is a buy or a sell order when the order is used as the taker order, the price for the maker order is always the price defined in the order.
So if there is a positive spread between the taker and the maker order we either use the spread to buy more tokens (sell order) for the taker, or let the taker keep the spread (buy order).
The ring-matcher can choose to give an order a rebate. This is a percentage of amountB.
rebateBips's max value is 0.63% in steps of 0.01% (1 bips).
Ring-matcher pays all actual costs for a trade
The ring-matcher is in the best position to decide if a trade is profitable (and if not, he can still choose to do the trade for other reasons):
So it makes sense to also let the ring-matcher pay:
By letting the ring-matcher pay the protocol fees for the orders we decouple this from the fee paid by the order owners. This is useful because the
Note that the ring-matcher normally receives fees from both orders which he can use to pay the protocol fees and/or rebates.
But if the ring-matcher pays the protocol fee, why have different protocol fee rates? You could argue that a 0.05% taker fee and a 0.01% maker fee is the same as a fixed 0.03% rate because the same entity pays the fee. That is true, but in general the ring-matcher will get a larger fee for the taker order than for the maker order so he will receive more tokens in
The order contains the maximum fee paid by the order owner.
The ring contains the actual fee paid by the order owner (which needs to be
Token Transfers for a single ring
The order we do the transfers in is important. The ring-matcher can directly pay his fees using the fees he gets from the orders.
There is little point in minimizing the number of 'token transfers' in the circuit. That's not expensive. The number of accounts and balances that need to be updated is the expensive part.
Fee Model Examples
Buy taker order
Sell taker order
Here are some of my feedback and questions regarding New Fee Model:
I think we should always use the maker's price, instead of the taker's price. This is how it works on CEXes.
But from a user's perspective, what he get in a trade should always satisfy the order's price, regardless if the spread is negative or positive.
This is an interesting approach. Basically if a ring is signed by the matcher, the matcher is forced to subside whatever amount needed to make the settlement price satisfy both order's prices, given the matcher still have enough balance. We may need to apply some kind of cap on the amount though. For example, 10% of the order'size, etc.
One possible challange for this appoach is that the ring-matcher may not have so many altcoins to pay feesl for all rings he built. We'll proabaly need to deduct protocol fees from trading fees the ring-matcher make out of the both orders first, if the trading fees < protocol fees, then we deduct from matcher's account balance, and if the fund is insufficient, we reject the settlement request.
If we do enforce ring-matcher to pay protocol fee, should we force them to pay in LRC instead of any token? And the protocol fee can be paid in fix amount instead of a percentage of the trading volume as well.
Regarding 3. Exchange protocol fee reduction staking (Per exchange)
I guess the idea is to let the exchange owner figure out how to reward people who stake LRC for his/her exchange, from the protocol level, we treat those staked tokens as a whole, is it?
This type of stakes is different from type-2 staking (2. Exchange owner staking (Per exchange)) in that the weight is 50% and the tokens can be withdrawn at any time without restrictions. Correct me if I'm wrong.
I think that's fine, because 2 order rings are symmetrical there should be no problem with making the first order the taker and the second order the maker, it should still be the same ring.
That's right, it reduces the number of constraints and makes the protocol fees/spread a lot easier because we only have to deal with 2 tokens. If we do a protocol fee on the amount traded we would also have to do that on the fee that is paid in fee token and so on...
Unless I made a mistake it's actually very simple to do. All fees are calculated as if the trade happens at the rate specified in the order. The only difference is that the second order receives tokens from not just the first order, but also the ring-matcher. Because the ring-matcher also pays the protocol fee for both orders there is no difference in who needs to pay the protocol fee on the complete
Yes, that's how it would work. It does not matter for the order owners either way. They will get their tokens at the rate specified in the order.
I though about this, and I'm not against a cap, but I think leaving this uncapped is not really dangerous. The ring-matcher needs to know what he's doing when matching orders. There's a lot of ways to lose money if you use the system incorrectly (like paying a huge fee to the operator for the settlement).
That's how it would work. If the ring-matcher balance is insufficient the settlement cannot be included in a block.
There's actually no need to do any checks like 'trading fees < protocol fees' etc in the circuit... the balance is just updated for every 'token transfer' and every 'transfer' ensures that
But in most normal cases the ring-matcher can pay everything using the fees he gets.
I think it makes sense to use percentages. Trading fees are percentages and people are okay with that. Otherwise the fixed protocol fee is either extremely low or makes the protocol unattractive for small trades. I think making it a very low percentage is better than making it a fixed fee, but that's just my opinion, I don't know if that's the smartest thing to do. A fixed fee in LRC will be a bit cheaper in the circuit. Doing both is also an option I guess: very low percentage + fixed fee in LRC.
When we support simple token transfers we'll probably have to do the protocol fee in a percentage because users will have to pay it directly.
If we use percentages that kind of rules out using LRC as the only payment because we don't know the price of LRC in tokenS/tokenB. Well, we could try and get the price in the circuits some way, but even if that is possible it would be pretty expensive to do it that way.
Correct. Just the reduction in protocol fee could be reason enough for ring-matchers/wallets/etc... to stake for the exchange. But the exchange owner can give extra rewards if he wants.
That's the idea. 3. staking is a lot more flexible in that the LRC can be withdrawn at any time (from the protocol's perspective, the exchange owner contract can impose more restrictions). 2. stake is stuck until shutdown so is riskier for the staker, but better for the users so this staking is incentivized by giving it a larger weight for the protocol fee reduction.
Is there a way that you can allow for the exchange to reimburse the maker to bring their effective fee down to 0%?
How is there a loophole also? Can you explain please?
Thanks for the feedback @coreycaplan3 !
Yes, the protocol fee is not paid by the order owner itself, it's completely paid by the ring-matcher. The protocol fee is not paid by the order owner by using a part of the fee. The protocol fee percentage and fee percentage are completely unrelated. If the fee is 0% the order owner will not pay any fees at all, the ring-matcher will have to pay the protocol fee.
It's also very likely it will be possible for the maker fee to be reduced to 0%.
My current thinking is that there isn't any realistic loophole. My biggest fear is/was the asymmetry. You could create a ring that matches an order selling $100 worth of tokens with an order selling $0 worth of tokens, the protocol doesn't know (and should not care) about this. The ring-matcher can then decide to only pay the protocol fees for the order worth $0, effectively evading the protocol fees.
The question remains how this asymmetry could be exploited. I can't think of any that are problematic but some examples:
But it's of course possible I'm missing a case that's actually a problem. :)
Great explanation! I think one thing to keep in mind is that most exchanges operate like regular trading platforms. The idea that Dolomite could settle a trade worth $0 to avoid fees with a $100 trade is far fetched when you think about how businesses like Dolomite operate.
I definitely see what you're saying but even still I don't think it's reasonably possible to setup a taker trade for effectively $0 if it's being matched logically.
So does this mean that, similar to v2 of Loopring, Dolomite needs to effectively reimburse itself via the trading fees?
Last recommendation: Protocol pool staking (Global)
Thanks for all of the answers. Everything seems logical otherwise :)
Oh I definitely agree. But because the protocol fee can still be a significant loss of revenue for exchanges it may be worthwhile for them to exploit far fetched things like this.
I'm not sure what you mean with that. The ring-matcher can pay the protocol fees using his own funds. But because of the order we do the token transfers in (the ring-matcher receives the trading fees/margin first, afterwards he pays the protocol fees), he can use the trading fees he receives to do so if possible. Does that answer your question?
There are 3 possible sources of income:
As a DEX you can choose to be the wallet, ring-matcher and operator all at the same time, which makes the operator fee redundant.
The exact mechanism for this still needs to worked out. But this seems reasonable, though I think the penality should be rather high if we would do this. It's a risk/reward exercise for the users, nobody is forcing you to lock up LRC for a long time. :)
Yes this answers my question! I was wondering at what point in the settlement process does that occur. This makes sense. Considering DEXs (like Dolomite) can effectively cover the protocol fee for market makers and (presumably) issue rebates then too to them in "real-time".
This makes sense.
What's your thoughts on this scenario: I say I'm going to lock my LRC for 12 months. After the 6 month tranche goes by, I decide I want to withdraw, which is in-line with the other people who were going to withdraw in 6 months, but it still breaks my "agreement" of staking for 12 months. What's your thoughts on situations like this and how we should penalize the withdrawal? The same way as withdrawing at a random time?
The only way to do rebates is by negative spreads. This was actually something I discussed with Matthew and Daniel today and may be a source of confusion (see the 'Negative fees for market makers (rebates)' part in the issue). Matt will ask market makers if they are okay with this.
Having actual rebate payments for orders has the strange side effect of the same order having multiple representations that behave differently if you implement it in a straightforward way. Having the market maker simply set a higher price (combination of his expected price + rebate) is more flexible, though perhaps less traditional. If this is too confusing we will add a rebate parameter to the order, but it will simply be used to set the price higher in the protocol. I will be making some examples showcasing how the fee model works in different cases (probably tomorrow).
I would say the same as at a random time, because you're still withdrawing earlier than expected. Users are expecting the LRC to remain locked up for another 6 months and they may have made a decision to buy/lock-up LRC as a result of that. Though Matt actually came with an idea for this that may render this discussion moot (locked up LRC could be 'used' in a different way). Lots of different possibilities!
Maybe I misunderstood what was originally written but there are circumstances in which negative fees would be given out organically and not just for negative spreads. Dolomite is using it as an incentive mechanism, no matter what the order books look like. Simply put, it's an incentive mechanism for all market makers. The way you described the rebates and the way I understood them lend them to being "conditional" on negative spreads, whereas the way Dolomite would like to use them is not conditional on anything - if you are a maker, you get the company-specified rebate. Can you elaborate if I misunderstood?
Very interesting, looking forward to learning more and I agree with the result so far.
I added some examples in the issue how it would work. If you want to do rebates you have to use negative spreads. But I think the confusion is probably how this is currently exposed in the protocol/order. Even though not needed for the protocol, it makes sense to add a
Updated the main post:
This can actually be done by using a contract as the owner of the operator account. The funds are withdrawn to this account and can be split between the operator and the proving service using any logic.
Great, then this will be like an extension to the protocol. The same approach can be used to make sure matching fees can also be split between multiple parties including the operator and wallets (therefore the protocol does not need to support a percentage operator fee).