Let users close expired positions at their leisure

[luckysori]

Here are some things I've observed:

• The coordinator expires positions every 24 hours (the expiry should match an event attestation published by the oracle).
• We automatically trigger the collaborative closure of the corresponding DLC as soon as the corresponding app user comes online.
• App users must remain online during DLC setup and closure. If they do not remain online, we can relatively easily end up in a position where it is not possible to proceed (or roll back).

I suggest that when the coordinator expires a position it should just mean that the closing price has been determined. If the counterparty comes online any time after expiry they are able to execute the closure of the position at the predetermined price.

Obviously the coordinator needs to deal with users that never execute the collaborative closure, but that is equivalent to users who never come back online as things stand. We need to introduce a policy of force-closure if a user does not execute the collaborative closure of the DLC channel either way.

This proposal aims to avoid situations where the app user closes the app whilst a collaborative closure is taking place. Currently the user is not told that this is happening. There are alternative approaches to deal with this problem, but I like giving the user explicit control because it provides greater guarantees that they will not navigate away from the app and it is more self-custodial.

[holzeis]

Depending on the user to trigger the close of expired user has several advantages

• the user is aware of what is happening (what will hopefully prevent unintended breaks in the protocol execution)
• the collab close is executed like any other (non-expired) position. That means that we will look for a match and can get rid of the "mocked" match in that scenarios.

We should though look at the following things:

• What if we can't find a match (do we keep the position, force close or simply collab close with the oracle attested price?)
• How to present the user that an action is required? @bonomat and I discussed a solution the other day where the user sees a blocking popup at startup informing that some initial steps need to be executed (e.g. closing an expired position) and that the app should not get closed. This way we would have the same benefits, but the user is not in control on when to close an expired position.

[holzeis]

Why? It should always be in the incentive to the user to keep the channel open. I would not expose force-close of a DLC as a feature.

Not giving the user a say or at least an information kind of defeats the purpose of self sovereignty. That might not be the goal here but for me this goes hand in hand with self custody.

Yes it should be the incentive of the user so why worry asking for confirmation? It gives the user more control, which is what we want right?

[holzeis]

I don't think the user has to action this.

Why?

[holzeis]

Is this even mathematically possible? E.g.

he opened a position with 100 contracts bought at 10k,
his position expired at 11k (he made some profit),
he comes online at 9k
How big is his position what was his entry price and what happened with the rest?

Why shouldn't it be mathematical possible to close and open the position for the same contracts, but a different price?

[bonomat]

Not giving the user a say or at least an information kind of defeats the purpose of self sovereignty. That might not be the goal here but for me this goes hand in hand with self custody.

Imnho you are not presenting him with a choice: you basically ask him: do you want to lose/win 10 sats now or do you want to lose/win 10 sats minus transaction fees?.

Yes it should be the incentive of the user so why worry asking for confirmation? It gives the user more control, which is what we want right?

No, I'm more in favor of abstracting the DLC completely away and don't present it to the user because it is too complex to understand and reason about.

I don't think the user has to action this.

Why?

see comment above.

Why shouldn't it be mathematical possible to close and open the position for the same contracts, but a different price?

Right, that we can do. I thought you want to display it to the user as the same position being extended.

[holzeis]

Imnho you are not presenting him with a choice: you basically ask him: do you want to lose/win 10 sats now or do you want to lose/win 10 sats minus transaction fees?.

Fair enough, I have to agree with that 🙂.

[luckysori]

How to present the user that an action is required? @bonomat and I discussed a solution the other day where the user sees a blocking popup at startup informing that some initial steps need to be executed (e.g. closing an expired position) and that the app should not get closed. This way we would have the same benefits, but the user is not in control on when to close an expired position.

I agree that the solution I propose will require some thought in terms of presentation. As would do the solution you guys discussed.

I'm not against the alternative solution, but I do think we need to block the UI and display a loud message when we close expired positions. I slightly prefer the solution I suggested because it's less intrusive and I think we're less likely to interrupt the closure if the user has given permission first. We could still nudge the user towards closing the position by sending a push notification or showing a pop-up on startup (like you guys suggest), but ultimately give control to the user.

[bonomat]

I thought this is actually a complex topic so I'll write a longer answer to ensure we are aligned :)
You can skip all this and jump ## Proposals.

Some concepts

Let's separate the concepts of

• closing a DLC, and
• closing a position

As long as we are focusing on perpetual futures, a position does not expire. Which means, it might only one party be interested in closing a position (or DLC) while the other party wants to keep it open.

Note: I'm aware that we haven't implemented perpetual futures yet, but it is the plan.

Let's specify things a bit more:

• A position is only local to a single user. It is not a shared construct between two users. Differently said, user Alice might have a position a and user Bob a position b. While those two parties may trade against each other, each position is an individual construct and only relevant to the corresponding user. This makes more sense if Bob trades against Alice and Claire at the same time.
• close position is a simplification of placing an order in the right direction, it is not the same as closing a DLC.

The above might not be that relevant for this discussion, but I thought I mention it again :)

A DLC expired, what do we do?

We identified that a (perpetual) position does not expire, only the DLC expires.
We can

1. collaboratively remove the DLC
2. go on-chain

The latter one should be avoided because of on-chain cost but is inevitable if a user never comes online again. The former one is the preferred action but it requires both parties to be online.

If a DLC has expired, both parties get the price what the oracle attests to. This may or may not be favorable for either of the parties.

_As of today, the coordinator proposes to collaboratively remove an expired DLC whenever its counterparty is online.
The OP mentioned that this is not ideal because the user might not be aware of the protocol being executed. _

How long can a user come online to collaboratively remove a DLC?

If a DLC has expired, any party should go on-chain asap as in the worst case the refund timelock might kick in and both parties can refund their initial collateral.
This would be bad for the coordinator because of obvious reasons.

As of today, the coordinator waits indefinitely for the other party to come online so that the DLC can be removed collaboratively.

What does this mean for the position?

The coordinator's goal is to stay net zero in regards to all of his positions. He does not want to take exchange risk and hedges his position by always having two matching positions open at all times.

Ideal case

In an ideal case, a user comes online before his DLC expires and triggers a counter trade, i.e. he closes his position.
In this case, he sends an (market/limit) order to the orderbook, and hopefully receives a match.
The coordinator is happy because he can find someone else for an otherwise unbalanced position.

The non-ideal case

If a DLC expired, the coordinator needs to find a new party asap or he runs in the danger of taking up exchange risk.

The ideal non-ideal case

Ideally, there is a suitable order waiting in the orderbook and the coordinator can just open a new position with another trader.
Suitable in this case means that the current index price (i.e. what the oracle will attest to) is close to an open order in the orderbook.

The non-ideal non-ideal case

If a DLC expires and there is no suitable order in the orderbook,

1. the coordinator could close another position to stay balanced
2. the coordinator could accept the risk
3. the coordinator could post a limit order himself hoping for someone to take it
4. the coordinator could hedge somewhere else

(1.) is not feasible because (i) it might not be in the interest of the counterparty, (ii) there might not be a single position which matches exactly the size he needs to close
(2.) is not ideal as he could lose a lot of money
(3.) is still risky as it could be that no match can be found ending up in (2.)
(4.) seems to be necessary to really remove any currency risk but it adds counterparty risk (unless there is another self-custodial DEX without counterparty risk).

---

Proposals

If a DLC expires:

0. The coordinator marks the position as closed at the price the oracle would attest to.
1. The coordinator checks if there is a suitable order in the orderbook
   1. If there is one, the coordinator engages with a new trader
   2. If there is none, the coordinator hedges his position elsewhere
2. Coordinator waits until T_1 (T_1<T where T is the refund timeout)
   1. If the user comes online within T_1, theuser's app triggers collaborative removal of the DLC using a blocking screen
   2. If the user does not come online within T_1, the coordinator needs to force-close the DLC on-chain.

[luckysori]

I agree with what has been stated here.

Given that the current DLC protocol only uses an absolute timelock, there is real time pressure for both parties to close the DLC channel if they want to avoid the refund path. As such, the simplest option is to "force" the user to close the position collaboratively.

If we could apply an additional relative timelock to the refund transaction then we would have more time to play with (at least until the publication of the buffer transaction), so we could do something like what I proposed above. We can discuss this with Tibo.

[bonomat]

We could also look into #1042 which may allow us to remove the expiry completely (or push it far away into the future).

[luckysori]

We all agreed with #1051 (comment).