Propose a solution for the funding rate

[luckysori]

I decided to write an ADR because I came to the conclusion that the original solution reflected in #1069 does not work.

Because none of the solutions discussed in the document are ideal, I want to use this PR as an opportunity to reach consensus before actually implementing a solution to #1069.

[bonomat]

Thanks for writing this up, I would go with Adjust the CET payouts depending on the funding fee

[bonomat]

If this is the case the user (A) was basically liquidated.

[luckysori]

This is true. But that does not mean that the funding fees were paid.

Basic example:

• 1st rollover makes A pay to B. The "A gets liquidated" CET cannot get adjusted because the output already pays everything to B.
• At the updated expiry the oracle implicitly unlocks the "A gets liquidated" CET. B should have earned the full DLC payout plus the funding fee, but they only get the DLC payout.

In a more extreme scenario, if the contract is rolled over 20 times and the funding fee is paid 15 times from A to B, if A gets liquidated with the CET at the boundary of the curve, B misses out on 15 - 5 = 10 trading fees.

Obviously this only needs to apply to contracts that are closed on-chain. If I were keeping track of the funding fees outside of the CETs I would want to do the accounting without capping gains/losses based on the collateral. But this would mean there would be a discrepancy between on-chain and off-chain settlement.

[bonomat]

Imho this is a good design: the longer the position is open, the earlier the user gets liquidated because its margin is being reduced by the funding rate.

Expressed differently:

• Alice has margin m_A
• Bob has margin m_B
• Funding rate is f.

After the first rollover, e.g. after 8h, we have

• Alice margin m_A - f
• Bob margin m_B + f

The liquidation for the party going long is calculated as:
= (price_opening * leverage)/(leverage+1)

Now, the important thing is that the leverage is only constant at the beginning when the position was opened, later the leverage is a function of the margin and the price, i.e.

• initially we had: margin = quantity / (price_opening * leverage)
• after the opening we have leverage = quantity / (price_opening * margin)

Which means, the liquidation price will change but each party will always get the funding rate until either of the party gets liquidated, i.e. does not have enough money to pay for the funding rate.

[luckysori]

There are a couple of reasons why I don't like this idea so much:

• Makes liquidation more likely, which is the worst case scenario for traders and is expensive and cumbersome to enforce.
• Traders can miss out on funding fees (see comment above).

[bonomat]

Makes liquidation more likely, which is the worst case scenario for traders and is expensive and cumbersome to enforce.

Yes, but I don't think it's that much more likely, e.g. current funding rate on BitMEX is 0.01% for 8h, meaning, his margin gets reduced by 0.01% and it's 0.01% more likely that you get liquidated. That's like nothing :D

[bonomat]

One important thing we should consider is that funding rate is charged retrospectively and not in advance, e.g.

• the funding rate should be charged every 8h (00:00, 8:00, 16:00 - aka funding event)
• a position which is open at these times should require a funding rate to remain open
• the funding is paid at the funding event
• a position which was only opened between two funding events, may not be charged, e.g. a position open between 00:01 and 07:59
  • this is ok, because you can't close a position, you can only sell it to someone else in the market who then has the position open past the next funding event.

The problem I want to solve is the following:

• you might have multiple positions before a funding event, but only one during the funding event, e.g. a user who constantly buys and sells opened and closed his position multiple times.
  • If we were to charge the user the funding rate of 8h in advance, we would need to charge him for each trade,
  • while if we charge him retrospectively at the funding event, we only charge him once

[luckysori]

the funding rate should be charged every 8h

I was thinking about this yesterday and this means the user needs to come online every 8 hours. I guess this might be solved by our work on background tasks though. Long expiries (currently set to 7 days, although pretty arbitrary) might not work well with funding rates.

Updating the expiry and charging the funding rate have to happen together because the funding rate is paid precisely to have the right to keep the position open.

The problem I want to solve is the following:

• you might have multiple positions before a funding event, but only one during the funding event, e.g. a user who constantly buys and sells opened and closed his position multiple times.
  • If we were to charge the user the funding rate of 8h in advance, we would need to charge him for each trade,
  • while if we charge him retrospectively at the funding event, we only charge him once

I think the proposed solution does respect this, but we cannot ensure atomicity (for now) if something goes awry.

[luckysori]

After investigating the differences between (1) adapting the margin and (2) adapting the payouts, I have concluded that the effect is equivalent. (1) is obviously much simpler so I think we can merge this ADR in its current state as discussed offline.