Better perpetuals

[da-kami]

After a discussion with @thomaseizinger and @klochowicz about #1066 we came to the conclusion that our current implementation of auto-rollover + funding-rate is not very user friendly.

At the moment we trigger a rollover every hour. This means, if a user initially paid for 24h (which we would have to charge based on the expiry of the CFD), the user would have additional costs after one hour again. This is not "wrong", because after that one hour the user has 24h (i.e. the CFD extended by one hour) again, but it is weird.
I as a user, would expect that, if I pay for an initial 24h I get charged after 24h. Not after one hour.

A solution to this problem is, to align the settlement interval with the funding round.
Instead of rolling over every hour, we would rollover in the last hour before the expiry. So, upon opening a position, the user would be charged for 24h and the next round would be set to 23h from now. Once the last hour is hit rollover is triggered, and another 24h us charged.
On top of that we could timelock the new (rolled over) transactions to be only usable after the oracle event.

This leads to the "problem", that a user has to come online in exactly the last hour to be able to roll over.
One solution to overcome this, could be to pre-compute future rollovers at the time of opening the CFD. Since everything builds on the initial lock transaction, and we know all the fees that will incur we can actually pre-compute and store X rollovers directly (or even during) opening a position.
This would allow the taker to be offline for longer, and still have a perpetual position.

[thomaseizinger]

This leads to the "problem", that a user has to come online in exactly the last hour to be able to roll over.
One solution to overcome this, could be to pre-compute future rollovers at the time of opening the CFD. Since everything builds on the initial lock transaction, and we know all the fees that will incur we can actually pre-compute and store X rollovers directly (or even during) opening a position.
This would allow the taker to be offline for longer, and still have a perpetual position.

To add to this: I think we can use Bitcoin's nLocktime to enforce that a commit transaction doesn't go on-chain prior to the previous funding period ending. This should allow us to pre-compute as many commit transactions as we want with them being stacked in regards to their locktime. We can do this silently in the background whilst the user is online (or while we are waiting for lock to be confirmed for example).

[thomaseizinger]

Pre-computing future rollovers might be tricky with a change in funding rate because that one is decided when the TX is created.

[da-kami]

Not totally related, but I thought I'll mention it.
I just read up on margin trading again, and a the maintenance margin:

There is also a restriction called the maintenance margin, which is the minimum account balance you must maintain before your broker will force you to deposit more funds or sell stock to pay down your loan. When this happens, it's known as a margin call. A margin call is effectively a demand from your brokerage for you to add money to your account or close out positions to bring your account back to the required level. If you do not meet the margin call, your brokerage firm can close out any open positions in order to bring the account back up to the minimum value. Your brokerage firm can do this without your approval and can choose which position(s) to liquidate.

source: https://www.investopedia.com/terms/m/margin.asp

I was thinking if we could achieve a setup where instead of deducting the recurring interest from an open position we could opt for adding "fresh" money in interest payments to keep the position open. I guess this it not possible, because we cannot add additional UTXOs to lock once it is there, and since lock is basically our contract on chain, we cannot add fresh money without spending from lock (which is to be avoided for rolling over).
I wonder if we will be able to achieve this at some point in the future.

[thomaseizinger]

I'd like to discuss the idea of rollover being triggered by the maker instead of the taker. We need to charge a funding rate on every rollover. The interval doesn't matter but with rolling over, we are extending the user's contract so we need to charge them for this service.

The maker decides the funding rate. I think from that we conclude that the maker also has an opinion on when to charge this funding rate which means, they should decide when rollover happens.

By default, our taker implementation should always follow through with rollover. At some point, we might add controls to the user interface for the user to set a maximum funding rate they are willing to pay. With such controls in place, a maker initiated rollover might fail in which case, the maker would force-close the position.

Similarly, if the taker is not online, the position will be force-closed. As an optimization, we might later add the pre-computation of rollovers IF the maker can afford locking in a funding rate ahead of time. That is effectively a risk evaluation against the market and depends on the maker's trading / hedging policy.

@da-kami @bonomat @klochowicz Input welcome.

[bonomat]

I'd like to discuss the idea of rollover being triggered by the maker instead of the taker. We need to charge a funding rate on every rollover. The interval doesn't matter but with rolling over, we are extending the user's contract so we need to charge them for this service.

Ideally the funding rate is not controlled by the maker but by the market. The problem is if the maker can control it, he can trick takers into opening a position with him with a low funding rate only to increase it after the first rollover.

By default, our taker implementation should always follow through with rollover. At some point, we might add controls to the user interface for the user to set a maximum funding rate they are willing to pay. With such controls in place, a maker initiated rollover might fail in which case, the maker would force-close the position.

I think some control is needed by the taker. Otherwise a greedy maker could bump the funding rate and the taker has no chance to say no.

In regards to who triggers it: from my perspective the goal is to give a lot of control to the user (I always consider the taker as the user as he is a manual one. The maker in my eyes is always an automated app.) If triggering means control, then the taker should do it.

[thomaseizinger]

I'd like to discuss the idea of rollover being triggered by the maker instead of the taker. We need to charge a funding rate on every rollover. The interval doesn't matter but with rolling over, we are extending the user's contract so we need to charge them for this service.

Ideally the funding rate is not controlled by the maker but by the market. The problem is if the maker can control it, he can trick takers into opening a position with him with a low funding rate only to increase it after the first rollover.

That is a fair point. What we could do is have both parties go into the rollover with an expectation for the funding rate by already signing their transactions with that rate in mind. If verification fails once they've exchanged their signatures, then there is apparently a disagreement on what the funding rate for the next round should be.

Currently we don't have a market so assuming we have a stream of funding rates from the maker to the taker, the current implementation could use that as the input, effectively always following the maker's funding rate but keeping at least the protocol agnostic as to where it is coming from.

What this solution lacks is an easy way of determining, why the protocol failed. Alternatively, we could do a message handshake upfront. That would make a disagreement on the funding rate more obvious but is actually less resilient when you look at it in detail. A rouge peer (or a buggy peer), could use one funding rate in the handshake message but compute the CETs during the rollover using a different one.

What counts in the end is what is in the transactions because that is what is going to happen on-chain. Hence, I think the protocol design can rely on this verification to determine success. To provide clear error messages on what went wrong, we would need to introspect the exchanged messages and transactions. That is a bit more work but in the context of a rouge or buggy peer it is required anyway so we might as well omit the handshake message upfront and instead write code that diagnoses the actual problem at hand.

Another benefit of this is that we can build it in iterations by omitting this diagnostic code at first and add it in later.

By default, our taker implementation should always follow through with rollover. At some point, we might add controls to the user interface for the user to set a maximum funding rate they are willing to pay. With such controls in place, a maker initiated rollover might fail in which case, the maker would force-close the position.

I think some control is needed by the taker. Otherwise a greedy maker could bump the funding rate and the taker has no chance to say no.

In regards to who triggers it: from my perspective the goal is to give a lot of control to the user (I always consider the taker as the user as he is a manual one. The maker in my eyes is always an automated app.) If triggering means control, then the taker should do it.

I agree that the (wire) protocol should give control to the user by design. Also, for reasons of deterministic software design, it would be good if there is an unambiguous kick-off event for the protocol.

A->B: Rollover(OrderId)
A->B: Msg0
B->A: Msg0
// etc

Once we have multiplexing (for example through #1126), this is not going to change fundamentally, it can just happen concurrently now and the individual messages do not need to carry the OrderId identifier.

A->B: NewStream(`/itchysats/rollover/1.0.0`)
A->B: Rollover(OrderId)
A->B: Msg0
B->A: Msg0
// etc

The only question that remains is figuring out, who takes role A and who takes role B. My suggestion would be:

The dialer of the underlying, physical connection takes role A, the listener takes role B. In our case, this means taker is role A and maker is role B. Once we scale to a p2p network, that reasoning will still work so the actual protocol itself doesn't need to change.

[thomaseizinger]

I'll draft up an ADR that summarizes the protocol changes.