Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Protocol3] New fee model and examples #197

Closed
Brechtpd opened this issue May 17, 2019 · 19 comments

Comments

3 participants
@Brechtpd
Copy link
Contributor

commented May 17, 2019

New Fee Model Design

@Brechtpd Staking has been moved to #208.

Protocol Fee

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.
A protocol fee value is stored in a single byte in bips/10. This allows us to set the protocol fee up to 0.255% in steps of 0.001% (0.1 bips).

Different treatment of maker and taker orders

The ring-matcher chooses which order is the maker and which order is the taker.
The first order in the ring is always the taker order, the second order is always the maker order. We always use the rate of the second order for the trade.

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.

Fee payments

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. These values are calculated on the complete amount bought, the protocol fee does not change this in any way.

private calculateFees(
    fillB: BN,
    protocolFeeBips: number,
    feeBips: number,
    rebateBips: number
{
    const protocolFee = fillB.mul(new BN(protocolFeeBips)).div(new BN(100000));
    const fee = fillB.mul(new BN(feeBips)).div(new BN(10000));
    const rebate = fillB.mul(new BN(rebateBips)).div(new BN(10000));
    return [fee, protocolFee, rebate];
  }

feeBips's max value is 0.63% in steps of 0.01% (1 bips).

Buy/Sell orders

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).

Rebates

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):

  • The ring-matcher receives fees from both orders
  • The ring-matcher pays the operator for settlement on-chain
  • The ring-matcher actively monitors the side-chain/main-chain and cost for settlement

So it makes sense to also let the ring-matcher pay:

  • The protocol fee for both orders
  • The rebates

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 order.feeBips can be lower than the protocol fee. Otherwise this could give issues when the protocol fee changes or when the order is used as maker/taker and different protocol fees apply.

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 takerOrder.amountB than in makerOrder.amountB. By having different rates it's more likely that the ring-matcher can pay the complete protocol fee just by using the tokens he receives as fee.

Data

Order

Order {
  exchangeID (32bit)
  orderID (20bit)
  accountID (20bit)
  dualAuthPublicKeyX (254bit)
  dualAuthPublicKeyY (254bit)
  tokenS (8bit)
  tokenB (8bit)
  amountS (96bit)
  amountB (96bit)
  allOrNone (1bit)
  validSince (32bit)
  validUntil (32bit)
  maxFeeBips (6bit)
  buy (1bit)
}

The order contains the maximum fee paid by the order owner.

Ring

Ring {
  orderA_hash (254bit)
  orderB_hash (254bit)
  orderA_feeBips (6bit)
  orderB_feeBips (6bit)
  orderA_rebateBips (6bit)
  orderB_rebateBips (6bit)
  accountID (20bit)
  tokenID (8bit)
  fee (96bit)
  nonce (32bit)
}

The ring contains the actual fee paid by the order owner (which needs to be <= order.maxFeeBips). This allows, for example, for DEXs to temporarily/permanently lower the fees on their DEX without having users recreate their orders so they can get the lower fee. This also allows the same order to get the taker fee and the maker fee, because the same order could be used as both.

feeBips and rebateBips cannot both be non-zero for an order.

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.

// Actual trade
orderA.tokenS.transferFrom(accountA, accountB, fillAmountSA)
orderB.tokenS.transferFrom(accountB, accountA, fillAmountSB)
// Fees
orderA.tokenB.transferFrom(accountA, ringMatcher, feeA)
orderB.tokenB.transferFrom(accountB, ringMatcher, feeB)
// Rebates
orderA.tokenB.transferFrom(ringMatcher, accountA, rebateA)
orderB.tokenB.transferFrom(ringMatcher, accountB, rebateB)
// Protocol fees
orderA.tokenB.transferFrom(ringMatcher, protocolFeePool, protocolFeeA)
orderB.tokenB.transferFrom(ringMatcher, protocolFeePool, protocolFeeB)
// Operator fee
ring.feeToken.transferFrom(ringMatcher, operator, ring.fee)

Fee Model Examples

Buy taker order

Protocol fees:

  • Taker: 0.05%
  • Maker: 0.025%

Taker order:

  • Buy order
  • Sell: 10.1ETH
  • Buy: 10,000LRC
  • Fee: 0.2%
    -> Pays: 10.0ETH (less than the 10.1ETH specified in the order)
    -> Receives: 10,000LRC - 20LRC (fee)
    -> Trading fee: 20LRC
    -> Protocol fee: 5LRC

Maker order:

  • Buy/Sell order (doesn't matter for the maker order)
  • Sell: 20,000LRC
  • Buy: 20ETH
  • Fee: 0.1%
    -> Pays: 10,000LRC
    -> Receives: 10ETH - 0.01ETH (fee)
    -> Trading fee: 0.01ETH
    -> Protocol fee: 0.0025ETH

Sell taker order

Protocol fees:

  • Taker: 0.05%
  • Maker: 0.025%

Taker order:

  • Sell order
  • Sell: 10.1ETH
  • Buy: 10,000LRC
  • Fee: 0.2%
    -> Pays: 10.1ETH
    -> Receives: 10,100LRC (more than the 10,000LRC specified in the order) - 20.2LRC (fee)
    -> Trading fee: 20.2LRC
    -> Protocol fee: 5.05LRC

Maker order:

  • Buy/Sell order (doesn't matter for the maker order)
  • Sell: 20,000LRC
  • Buy: 20ETH
  • Rebate: 0.1%
    -> Pays: 10,100LRC
    -> Receives: 10.1ETH + 0.0101ETH (rebate)
    -> Rebate: 0.0101ETH
    -> Protocol fee: 0.002525ETH

@dong77 dong77 pinned this issue May 18, 2019

@dong77

This comment has been minimized.

Copy link
Contributor

commented May 18, 2019

Here are some of my feedback and questions regarding New Fee Model:

  • regarding Different treatment of maker and taker orders:

The first order in the ring is always the maker order, the second order is always the taker order. We always use the rate of the second order for the trade.

I think we should always use the maker's price, instead of the taker's price. This is how it works on CEXes.

  • regarding Removal of the fee token
    The reason to remove fee-token is to reduce the number of constraints in the circuits, is it?

  • regarding Allow matching orders regardless of price
    I actually had this idea a while ago but never push this forward (one reason is that we have to do the math right, ant the calculation will be more complex). It seems to me the ring-matcher, wallet, and DEX operator subside the taker together to make the trade happen. When we settle a trade, we do need to consider fees before-hand, instead of simply deducting fees afterward. I'm not sure if it is too complex to do the math in circuits.

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.

  • regarding Ring-matcher pays all actual costs for a trade

The ring-matcher receives the spread if spread > 0 (we called this the margin) but the ring-matcher needs to pay the spread if spread < 0.

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.

@dong77

This comment has been minimized.

Copy link
Contributor

commented May 18, 2019

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.

@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented May 18, 2019

Different treatment of maker and taker orders:

The first order in the ring is always the maker order, the second order is always the taker order. We always use the rate of the second order for the trade.

I think we should always use the maker's price, instead of the taker's price. This is how it works on CEXes.

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.

Removal of the fee token:
The reason to remove fee-token is to reduce the number of constraints in the circuits, is it?

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...

regarding Allow matching orders regardless of price:
I actually had this idea a while ago but never push this forward (one reason is that we have to do the math right, ant the calculation will be more complex). It seems to me the ring-matcher, wallet, and DEX operator subside the taker together to make the trade happen. When we settle a trade, we do need to consider fees before-hand, instead of simply deducting fees afterward. I'm not sure if it is too complex to do the math in circuits.

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 fillB of the second order. If you check the sequence in which the token transfers are done you will see that the first order pays the second order at the start before all fees are paid, so the number of tokens received here can still be < fillB, but should still be more than enough to pay the wallet/ring-matcher fee in tokenB (max fee is currently 2.55%, so the spread would have to be > 97% for this to fail!).

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.

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.

The ring-matcher receives the spread if spread > 0 (we called this the margin) but the ring-matcher needs to pay the spread if spread < 0.

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.

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).

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.

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 balance >= 0. This is different then in solidity where you can save gas by not having to check balances and minimizing the number of token transfers you have to do. In the circuits the cost is just the balance in the leaf that needs to be updated, and this leaf needs to be updated anyway, all other calculation are insignificant so can be kept as simple as possible.

But in most normal cases the ring-matcher can pay everything using the fees he gets.

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.

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.

@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented May 18, 2019

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?

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.
And all this staked LRC is seen as a single amount for the protocol.

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.

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.

@dong77

This comment has been minimized.

Copy link
Contributor

commented May 19, 2019

I feel comfortable moving forward.

@coreycaplan3

This comment has been minimized.

Copy link

commented May 24, 2019

Regarding:

Maker: 0.025% -> 0.010% (0.0% most likely creates a loophole)
Can you explain how going to 0% creates a loophole?

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?

@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2019

Thanks for the feedback @coreycaplan3 !

Maker: 0.025% -> 0.010% (0.0% most likely creates a loophole)
Can you explain how going to 0% creates a loophole?

Is there a way that you can allow for the exchange to reimburse the maker to bring their effective fee down to 0%?

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%.

How is there a loophole also? Can you explain please?

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:

  • You could try to do the trade in multiple rings, exploiting this with dummy orders not worth anything but which are used to pay the protocol fees on. Even if this works in some way I think it's highly unlikely you could still do the trade trustless (e.g. using an intermediate account or by colluding with the ring-matcher or something like that).
  • You could use it to transfer tokens between accounts without paying the protocol fee. This is actually fine because we don't want to charge users a protocol fee on the amount transferred for doing token transfers, the user will just pay a fixed fee for the transfer like he would expect from doing on-chain transfers (and this fixed fee to the operator could perhaps be subject to a protocol fee).

But it's of course possible I'm missing a case that's actually a problem. :)

@coreycaplan3

This comment has been minimized.

Copy link

commented May 24, 2019

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.

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.

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)
I think having the flexibility to withdraw your stake before the time period you specify, (IE 6 months) is pretty important. Users should be able to withdraw while facing some small penalty for doing so early. I'm not sure what the penalty should be, but this should be considered at least and I'm happy to discuss it.

Thanks for all of the answers. Everything seems logical otherwise :)

@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2019

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.

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.

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.

So does this mean that, similar to v2 of Loopring, Dolomite needs to effectively reimburse itself via the trading fees?

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:

  • The trading fees (paid by the order owners to the wallet/ring-matcher)
  • The positive spread (aka the margin paid to the ring-matcher)
  • The operator fee (paid by the ring-matcher to the operator)

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.

Last recommendation: Protocol pool staking (Global)
I think having the flexibility to withdraw your stake before the time period you specify, (IE 6 months) is pretty important. Users should be able to withdraw while facing some small penalty for doing so early. I'm not sure what the penalty should be, but this should be considered at least and I'm happy to discuss it.

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. :)

Thanks for all of the answers. Everything seems logical otherwise :)

Thank you!

@coreycaplan3

This comment has been minimized.

Copy link

commented May 25, 2019

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?

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".

There are 3 possible sources of income:

This makes sense.

It's a risk/reward exercise for the users, nobody is forcing you to lock up LRC for a long time.
Definitely in agreement with you but sometimes people like the flexibility of paying a (large) penalty. Clearly we're in agreement here though.

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?

@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented May 25, 2019

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".

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).

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?

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!

@coreycaplan3

This comment has been minimized.

Copy link

commented May 25, 2019

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.

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?

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!

Very interesting, looking forward to learning more and I agree with the result so far.

@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented May 25, 2019

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.

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?

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 rebate parameter to the order to make this more clear for users using traditional order books.

@coreycaplan3

This comment has been minimized.

Copy link

commented May 27, 2019

Even though not needed for the protocol, it makes sense to add a rebate parameter to the order to make this more clear for users using traditional order books.

Yes that's a great idea and will make it clearer!

@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2019

Updated the main post:

  • Removed a lot of implementation details. Should be easier to understand for everyone!
  • Removed the wallet address from orders! And all things related to the fees paid to the wallet (walletSplitPercentage). Fees go completely to the ring-matcher. A fee sharing scheme can be done outside the protocol. This makes the protocol more efficient.
  • The margin is not paid to the ring-matcher, the order owner keeps the margin. This is done to support 'market orders'. We still use the margin value to correctly update the trading history for the order though.
  • Added a rebate field to the Ring data. The rebate is specified in bips of amountB and is paid to the order owner in tokenB.
  • To support a proving service we need to be able to split the operator fee with the account of that service. Because this service generates the proof this account is baked into the proof itself, so the operator cannot simply change it or remove it. (Though this payment could also be done outside the protocol?)
@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2019

To support a proving service we need to be able to split the operator fee with the account of that service. Because this service generates the proof this account is baked into the proof itself, so the operator cannot simply change it or remove it. (Though this payment could also be done outside the protocol?)

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.

@dong77

This comment has been minimized.

Copy link
Contributor

commented May 31, 2019

To support a proving service we need to be able to split the operator fee with the account of that service. Because this service generates the proof this account is baked into the proof itself, so the operator cannot simply change it or remove it. (Though this payment could also be done outside the protocol?)

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).

@Brechtpd

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2019

Updated the main post:

  • Added buy/sell orders to support market orders
  • Updated examples
@dong77

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

@Brechtpd Staking has been moved to #208.

The fee-model is implemented by #199.

@dong77 dong77 changed the title [Protocol3] New fee model and staking system [Protocol3] New fee model and examples Jun 6, 2019

@dong77 dong77 added core_feature and removed next_release labels Jun 6, 2019

@dong77 dong77 unpinned this issue Jun 6, 2019

@Brechtpd Brechtpd closed this Jun 7, 2019

Loopring Protocol 3 automation moved this from To do to Done Jun 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.