How to deal with funding rates

[da-kami]

This is a collection of learnings we made and should serve as a base for discussions:

Funding Rates

For the actual discussion point, jump to the end.

Some recaps

How do CFDs work

A CFD is a Contract For Difference. Meaning, traders get the difference between opening and closing price.

If the trader goes long:

The trader who goes long borrows USD from the counterparty and buys BTC at the current rate.
He has to return said USD to the counterparty once the position is closed. At this point, he has to sell parts of the BTC to pay back the borrowed USD.

Example:

• TraderA goes 100 BTCUSD contracts long at $100/BTC with a leverage of 1
  • he borrows $100 to buy BTC at the current price

Contract closes at $200/BTC:

• TraderA has to return $100 to TraderB at the price of $200/BTC --> 100/200 = 0.5BTC
• TraderA gets 1 BTC (TraderA margin) + (1 BTC (borrwed at $100/BTC) - 0.5 BTC (paid back at $200/BTC) = 1.5 BTC
• TraderB gets the different, i.e. 2 BTC - 1.5 BTC = 0.5 BTC

Contract closes at $80/BTC:

• TraderA has to return $100 to TraderB at the price of $80/BTC --> 100/80 = 1.25BTC
• TraderA gets 1 BTC (TraderA margin) + (1 BTC (borrwed at $100/BTC) - 1.25 BTC (paid back at $200/BTC) = 0.75 BTC
• TraderB gets the difference, i.e. 2 BTC - 0.75 BTC = 1.25BTC

If the trader goes short:

The trader who goes short borrows BTC from the counterparty to sell at the current for USD.
He has to return BTC to the counterparty once the position is closed. At this point, he has to buy BTC to pay back.

Example:

• TraderA goes 100 BTCUSD contracts short at $100/BTC with a leverage of 1
  • he borrows 1 BTC to sell for $100 at the current price

Contract closes at $80/BTC:

• TraderA has to return 1 BTC to TraderB at the price of $80/BTC

• TraderA sold 1 BTC for $100 when opening the position. Now he only needs $80 to buy back said BTC. He can keep the difference $100-$80=$20. $20 at the closing price of $80/BTC are 20/80 = 0.25, i.e. he made 0.25 BTC profit.

• TraderA gets 1 BTC (TraderA margin) + (($100 - $80)/80) = 1.25 BTC

• TraderB gets the different, i.e. 2 BTC - 1.25 BTC = 0.75 BTC

Contract closes at $200/BTC:

• TraderA has to return 1 BTC to TraderB at the price of $200/BTC

• TraderA sold 1 BTC for $100 when opening the position. Now he needs $200 to buy back said BTC: $100-$200=$-100. $100 at the closing price of $200/BTC are -100/200 = -0.5, i.e. he made a loss of 0.5 BTC.

• TraderA gets 1 BTC (TraderA margin) + (($100 - $200)/200) = 0.5 BTC

• TraderB gets the difference, i.e. 2 BTC - (-0.5 BTC) = 1.5BTC

What is the funding rate

The funding rate is a periodic payment between taker and maker and can flow in either direction.
The funding rate can be positive or negative. If the funding rate is positive then there is a bullish sentiment in the market. At these times longs pay the shorts.
If the funding rate is negative, there is a bearish sentiment in the market. At these times the shorts pay the longs.

It might be hard to see, but there is an implicit lending involved when trading CFDs: the trader going long borrows USD and the trader going short borrows BTC.

Because of this implicit lending market, traders have to pay interest to each other:

Interest Quote Index = USD Lending Rate in the BitMEX Index (.USDBON)
Interest Base Index = XBT Lending Rate in the BitMEX Index (.XBTBON)

taken from ¹

For example:

Interest Quote Index = 1.00% per day
Interest Base Index = 0.25% per day

This means, the trader going long has to pay 1% per day and the trader going short has to pay 0.25% per day. Obviously, if they pay each other, one only gets the difference.

Hence, the funding rate is calculated as

Funding Rate = (1.00% - 0.25%) / 3 = 0.25%

_ 3 because bitmex has 8h intervals. 8h/24h=3_

Since it is positive, the trader going long has to pay the trader going short.

Calculations

TakerA bought 15k contracts at the price of $750/BTC

15,000 Contracts * 1 USD * 1/750 = 20 BTC`

The funding amount is calculated using the market value of the position:

Mark Value = Contracts / Spot price 
Funding Amount = Mark Value * Funding Rate 

=> 15k/750 = 20
=> 20 BTC * 0.25% = 0.05 BTC

Meaning, the taker has to pay 0.05 BTC in the next funding round.

If the price rises to $1500/BTC the market value of the position decreases and the funding amount decreases:

Mark Value = Contracts / Spot price 
Funding Amount = Mark Value * Funding Rate 

=> 15k/1500 = 10
=> 10 BTC * 0.25% = 0.025 BTC

Meaning, the funding amount changes with the value of the position.

Note: in contrast to what was said earlier, the funding amount is actually independent of the counterparty's margin. It just happens that in our case, the counterparty's margin has always a leverage of 1 and hence these values are equal.
For calculating the funding amount we should however take the market value (contracts/spot price).

Actual discussion

Where to subtract the funding amount?

In a discussion with @da-kami we had two ideas of where the funding amount should come from:

A. Should it be subtracted fromt he initial margin?
This would mean that the position gets riskier the longer the position is open as the usable margin decreases. If the usable margin decreases, the liquidation price should increase (the trader does not have enough funds to cover losses). Eventually, the position should close as not enough funds are available to pay for the funding.

B. Should both traders (taker and maker) provide an additional buffer for the interests
This would mean that both trader (taker and maker) would need to provide additional funds at the beginning. If we don't allow for dynamically adding funds, this would mean, both would need to know for how long they want to keep the position open.

Imho A) is the way to go as B) has the problem of dead liquidity: both have to put up additional funds for covering for the funding amounts. But, the actual funding amount does not take into account this amount. The trader only has to pay on the position value.

Where does the funding amount go to?

In both cases, the paid funding amounts should not change future funding rounds: since the funding amount is calculated based on the position value, not on the other party's margin.

For example, if a taker goes long and the maker goes short (our current scenario): if the price appreciates the taker has to pay the maker. Eventually the maker runs out of margin. Nevertheless, he received interest payments from the taker.
Imho, the maker should always receive these interest payments despite him losing (parts or all of) his margin.
That being said, the funding amount should not increase the margin.

Footnotes

1. https://www.bitmex.com/app/perpetualContractsGuideExamples ↩

[thomaseizinger]

If we don't allow for dynamically adding funds, this would mean, both would need to know for how long they want to keep the position open.

We will have a way of adding additional funds once we combine positions properly. How many funds to initially add is a trade-off decided by the user based on transaction fees per top-up really.

Imho A) is the way to go as B) has the problem of dead liquidity: both have to put up additional funds for covering for the funding amounts. But, the actual funding amount does not take into account this amount. The trader only has to pay on the position value.

tl:dr I think it is really hard to decide how severe this problem is which is why I think we should approach the solution finding process primarily from the angle of "What is the most correct solution?" first and only then consider, how much of a problem dead liquidity is.

In the following points, I try to make it obvious how hard it is to quantify the problem of dead liquidity. Given the choice of a hard to quantify problem that is less correct vs the correct one, I think we should favor the correct one.

1. You have to pay the fees one way or another

No matter where the funding rate comes from, you have to pay the fees one way or another. If the position ends up being closed because all my locked up money was eaten up by fees, I'd feel cheated: "What did I pay for?" "Where is my payout?" Of course, having to top up my fee balance 3 times with the result of spending the same amount of money as I am getting out of the contract is effectively the same but at least it is obvious that you need to continuously pay for this service.

2. The additional liquidity required is fairly small compared to the actual margin.

Taking the numbers from above, we have an effective interest payment of 0.75% per day. Meaning, you'd have to engage in a contract AND provide fees for ~ 133 days in advance to reach the point of locking up so much money in fees that you could open a position with the same value.

3. Dead liquidity only matters if you invest 100% of your money.

Dead liquidity is a problem no doubt. The problem only materializes if a user is investing 100% of their money though. If they have some funds sitting in their account, it is already dead so might as well use them for fee payments.

---

I think (3) shows that this is primarily a problem for the maker as they are more likely to optimize usage of the funds available. There is multiple ways of approaching this though:

• We could design it such that in case the maker has to pay a funding rate, it is deducted from the margin, i.e. the taker has a dedicated "fee account" but the maker doesn't.
• If the maker is in the short position, they are unlikely to pay a fee anyway, meaning the fee account could be much smaller, decreasing the problem of "dead liquidity" up to the point where it doesn't matter.

[thomaseizinger]

If the maker is in the short position, they are unlikely to pay a fee anyway, meaning the fee account could be much smaller, decreasing the problem of "dead liquidity" up to the point where it doesn't matter.

Why? Because we assume that there will always be a bull market?

Bitcoin can only go up, can't it? 😝

[thomaseizinger]

"What is the most correct solution?"

I think both solutions are "correct". The only thing that we would have to take into account when using the reduced/increased margin approach is, that we would have to adapt depending values (such as liquidation price) accordingly, otherwise we increase the risk. If the overall liquidation amount gets less than the initial margin then the party liquidating will get less upon liquidation. Given our model where the maker is x1 that risk would usually increase for the maker.

I guess we can make it mathematically correct by displaying the effective liquidation price etc.

It might be pretty confusing though. I am obviously biased in my opinion but as a user, I'd rather have my position gets force-closed because my fee account is drained rather than it being liquidated because the fees ate up my margin. If we adapt the liquidation price, we are introducing a requirement to constantly watch the market and have the user check back to see what their position is doing. If on the other hand, I know that I've provided fees for the next 4 days, I don't need to check back until then.

[bonomat]

I am obviously biased in my opinion but as a user, I'd rather have my position gets force-closed because my fee account is drained rather than it being liquidated because the fees ate up my margin. If we adapt the liquidation price, we are introducing a requirement to constantly watch the market and have the user check back to see what their position is doing.

I had a lengthy discussion with my trusted financial advisor who confirmed that a CFD is a day-trading tool, meaning it is essential that you check your position on a regular interval. It is not a long-term investment tool which you just buy and hold and don't check back.
That's an additional reason why CFDs are seen as a risky investment tool.

I understand your urge to not have to do this but this is not a core feature of CFDs. There are too many moving parts in your positions (e.g. the interest rates, your liquidation price) which require your attention - either active or by adding features automation on top.

There are features your can build on top, e.g. a margin call, which would you allow to use this tool differently, (an alert mechanism which tells you if you don't have enough margin in your account), or, a take profit/stop loss order which closes your position if the price crosses a certain value. But even then, your CFD position might need your attention to do something when you don't look.

The dead capital is an issue for both sides, the maker and the taker. Both have capital they want to invest and if it is stuck in a fee account then they can't invest it otherwise.

From a financial perspective using the margin is the way to go as confirmed from my financial expert. She never heard of an additional fee account on any financial product. A required feature is though to allow the user to top up the margin (e.g. if a margin call happens).

I double down on going with option A as it seems to be the correct one.

[thomaseizinger]

From a financial perspective using the margin is the way to go

It feels weird to me but if that is how other platforms work, sure.

She never heard of an additional fee account on any financial product.

Commbank has a feature called a direct investment account (CDIA): https://www.commbank.com.au/investing/commonwealth-direct-investment.html.
Also another bank I am with required me to open a dedicated account that is linked to my trading account. They use that account to debit fees, pay out dividends and it is also the account that gets debited if I place an order.

I see our lock transaction as the equivalent of such an account and your overall personal account is equivalent to your wallet. The amount in the lock transaction defines, how big the orders can be that you can place for example. Similarly, I can only place orders for up to the amount of what I have in my direct investment account. The lock transaction is an account. The commit transaction is the investment. Doesn't sound unreasonable to me to allow the user to not invest their entire account.

What I find weird about debiting the margin is that it would be equivalent to the bank automatically selling some of my shares to pay for the fees of the holding account.

I am no day-trader though so happy to build whatever is expected by our users.

[bonomat]

What I find weird about debiting the margin is that it would be equivalent to the bank automatically selling some of my shares to pay for the fees of the holding account.

This would indeed be weird. I'm not sure if we can compare these two things though as the margin is not really the asset you bought but a collateral you have to to hold to cover credit risk.

[da-kami]

Thanks for writing this up in so much detail @bonomat !

A few thoughts:

Eventually the maker runs out of margin. Nevertheless, he received interest payments from the taker.
Imho, the maker should always receive these interest payments despite him losing (parts or all of) his margin.
That being said, the funding amount should not increase the margin.

Just to make sure I understand this correctly:
So, when it gets increased the liquidation price would stay the same (because margin does not get increased...), but when it gets decreased the liquidation price has to be adapted?

---

Note: in contrast to what was said earlier, the funding amount is actually independent of the counterparty's margin. It just happens that in our case, the counterparty's margin has always a leverage of 1 and hence these values are equal.
For calculating the funding amount we should however take the market value (contracts/spot price).

I am not sure I can follow this completely. The counterparty's initial margin is constant, whereas contracts/spot price is not (given that the spot price is the current spot price), so I don't think these values can be equal. Irregardless of this statement we can use the market value, but if the market value is defined on the current spot price then the parties have to agree on the current spot price to be used for the calculations.

---

The funding amount is calculated using the market value of the position

That is what Bitmex does. I don't fully understand why though. The contracts do not reflect the leverage and thus don't reflect the amount that was borrowed / lent. Wouldn't it be more correct to use the initial counterparty margin?

---

Some thoughts on "increased risk":

If we assume a bull market then long pays interest to short. At the same time the long position has profits, so the long position in total has more BTC available. (same vice versa)
Do you think it could be possible that the profit made always outweighs the interest to be paid; i.e. the margin actually never has to be decreased because we can pay they fee out of the profits?

[bonomat]

@da-kami :

Eventually the maker runs out of margin. Nevertheless, he received interest payments from the taker.
Imho, the maker should always receive these interest payments despite him losing (parts or all of) his margin.
That being said, the funding amount should not increase the margin.

Just to make sure I understand this correctly: So, when it gets increased the liquidation price would stay the same (because margin does not get increased...), but when it gets decreased the liquidation price has to be adapted?

Yes, this is was I was proposing.

[..]I am not sure I can follow this completely. The counterparty's initial margin is constant, whereas contracts/spot price is not (given that the spot price is the current spot price), so I don't think these values can be equal. Irregardless of this statement we can use the market value, but if the market value is defined on the current spot price then the parties have to agree on the current spot price to be used for the calculations.

You are right. There is a mistake here. My initial statement was bogus.

The funding amount is calculated using the market value of the position

That is what Bitmex does. I don't fully understand why though. The contracts do not reflect the leverage and thus don't reflect the amount that was borrowed / lent. Wouldn't it be more correct to use the initial counterparty margin?

Yea, this is how Bitmex works. That's hw I understand i: You are borrowing from someone at Bitmex because you have the promise (not guaranty 😬) to get your profits. The platform will ensure that you can win this amount, which means you are borrowing from someone. As the price moves up, the amount you borrowed decreases (at the next funding interval) .... so actually, a new funding round is basically a new position? 🤯

Maybe it's worth to deviate from the Bitmex standard and always charge on the counterparty's margin because this is the amount which was locked up?

[da-kami]

Here is some more food for thought:

At the moment we calculate an initial funding fee that is based on the rate communicated in the offer, and calculated for 24h (i.e. the settlement interval).
To be clear: This is not the opening fee, but an initial funding fee. The opening fee is a static fee on top that is independent from the funding rate and always goes from taker to maker.

While I think an initial funding fee is not incorrect, I am not sure we should not make it configurable to the maker if / how it should be charged. It might make the product more attractive if we charge at the rear; i.e. if we charge for the current funding period when a funding event occurs, and not for the next period.

[klochowicz]

I believe that due to the nature of being on blockchain we can't charge "at the rear" - bitmex can do that as it literally gets the hold of your money, which is not the case in our non-custodial product :)

I believe if we decouple updates of the funding rates from the offer we could achieve greater flexibility in this (including changing less after opening etc)

[bonomat]

I think we can charge at the end, things might just get more complicated.

For example, if we have a funding interval of 24h , we should align our expiry with that, I.e. every Position expires at 00:00 every day unless rolled over. At this time, we charge the funding fee. We can fix the rate In advance and generate the DLC accordingly. If a user joins 10h in? He still pays the same funding rate.

If a user settles before hand, we should not charge a funding rate.

I haven’t thought through how to implement it but that’s how I think it should behave.

Regarding the opening fee: imho this is something completely different and can be charged on top of everything. I wouldn’t add another output though because that amount is likely quite low.

[thomaseizinger]

In a way, generating the commit transaction is charging retroactively because the money gets moved only if that transaction is used. It just that at the moment, the user doesn't have an alternative way out of the contract.

We could delay broadcasting commit after the attestation and thus, give the user a way of exiting with the previous funding round. Only once we've successfully rolled over (and exchanged the revocation keys) is the user bound to the next commit transaction and thus the next funding round.

[bonomat]

I agree, publishing the commit transaction is basically charging retroactively.
Once we rolled over and a new commit transaction was created, we can charge for this time.

Isn't the settlement a "way out" of the contract? In that case, the commit transaction is never broadcasted and we could void the pre-computed fees.

[thomaseizinger]

Isn't the settlement a "way out" of the contract? In that case, the commit transaction is never broadcasted and we could void the pre-computed fees.

It is but it requires trust and as such, we can't really advertise it as a protocol feature, can we?

In other words, if we decide that we want to charge retroactively, then I believe we should also allow for a unilateral way of doing that.

One way of doing that would be to make it legal to broadcast not just the current commit transaction but also the previous one. Assuming fixed funding rounds, that would allow the user to exit using the oracle attestation of the previous funding round.