CFD expiry and auto-close

[bonomat]

I wasn't sure where to post it so I thought I'd create a discussion here.

In the mocks we have decided to have fixed length CFDs, i.e. a CFD always has an expiry.

This is not easily achievable: the CFD position is on layer 2 and cannot automatically be closed into the channel. Closing the CFD position would mean we close the channel which is a bad experience.

What's the best way to deal with this?

[bonomat]

Maybe it's not that a hard problem:

One approach could be to treat the position as closed at expiry. The oracle attested to the price, meaning, we would know which CET becomes valid and how much money each party would get.

If the taker is online, we can collaboratively remove the CETs and settle into the channel, however, if the taker is not online, the maker will need to force close the channel after some time to get his money.

[da-kami]

[snip]
In the mocks we have decided to have fixed length CFDs, i.e. a CFD always has an expiry.

I am a bit confused by this statement: In ItchySats the CFD also always has an expiry, but that expiry changes whenever a rollover succeeded. For me this is still the same in what is mocked - or do you think this changes?

As you pointed out above, the only thing we would have to add for a good "force close" experience on layer two, is to add the possibility to collaboratively close in a force-close scenario. This is a feature we had thought off before, but we never added it to ItchySats.

1. We have an attestation
2. Maker2Taker: Let's close with the attestation price
   1. Taker accepts: Close in channel
   2. Taker does not accept: Maker has to force close, closing the channel

That's what you have in mind, correct?

[bonomat]

I am a bit confused by this statement: In ItchySats the CFD also always has an expiry, but that expiry changes whenever a rollover succeeded. For me this is still the same in what is mocked - or do you think this changes?

Yes, afaik that changed: we do not go for perpetual CFDs for now but for fixed-length CFDs.

[snip]
As you pointed out above, the only thing we would have to add for a good "force close" experience on layer two, is to add the possibility to collaboratively close in a force-close scenario. This is a feature we had thought off before, but we never added it to ItchySats.

1. We have an attestation
2. Maker2Taker: Let's close with the attestation price
   1. Taker accepts: Close in channel
   2. Taker does not accept: Maker has to force close, closing the channel

That's what you have in mind, correct?

Yes, that's what I had in mind.

[luckysori]

For me ideally the CFD would always be collaboratively settled into the channel if both parties are online.

We obviously cannot ensure that both parties are always available to collaboratively settle the CFD, but I wonder if we can wait a while longer after the oracle attests. Maybe this is achievable by setting the refund timelock far enough in the future. Because I think you're only incentivised to perform a non-collaborative settlement if:

1. The CFD will be refundable soon (and that makes you lose money compared to the winning CET).
2. You want to claim your coins ASAP and you don't trust the counterparty to be online or collaborate.

An auto-settle mechanism that by default works collaboratively makes sense to me. I wonder if this could even be done without user confirmation.

And if that doesn't work we could fall back to auto-settling non-collaboratively a few hours before the refund timelock expires.