Think about position expiry

[bonomat]

#973 will add a position to the maker.
Given we need combined positions, we will need to rethink how expiries are being handled, i.e.

1. maker and taker_a open position X_1 which expires at Y_1
2. taker_b comes after T and opens position X_2 which expires at Y_2

Y_1 != Y_2

What expiry does the maker's position have?

[bonomat]

I assume the answer is simple: we have global expiries, e.g. every day at 23:59:59 UTC, or Sundays at 23:59:59 UTC.
We need to ensure that each position is always open for at least X (e.g. 24h, 7 days).

For example:

• position duration: min 24h
• global expiry: every day at 23:59:59 UTC

Trade between maker and taker_a:

• position open at 14.08.2023 08:00 UTC
• maker position expires at 15.08.2023 23:59:59 UTC
• trader a position expires at 15.08.2023 23:59:59 UTC

Trade between maker and taker_b:

• position open at 14.08.2023 19:00 UTC
• maker position expires at 15.08.2023 23:59:59 UTC
• trader a position expires at 15.08.2023 23:59:59 UTC
• trader b position expires at 15.08.2023 23:59:59 UTC

Trade between maker and taker_c:

• position open at 15.08.2023 08:00 UTC
• maker position expires at 16.08.2023 23:59:59 UTC --> we need to extend the makers position
• trader a position expires at 15.08.2023 23:59:59 UTC
• trader b position expires at 15.08.2023 23:59:59 UTC
• trader c position expires at 16.08.2023 23:59:59 UTC

[luckysori]

I think what we need to ensure (as much as possible) is that the coordinator can unilaterally settle the same amount of long contracts and short contracts at the same time. This would ensure that the coordinator remains balanced. I think that's why global expiries would be helpful: because they make it easier to ensure that X long contracts and X short contracts expire at time T.

But things still get complicated as positions are rolled over! Rollovers could easily unbalance our expiries. Do we also need to ensure that positions our only rolled over as the counter positions are rolled over too?

---

On a related note, another aspect that needs to be taken into account to minimise coordinator risk is that the coordinator must not have to pay for on-chain transaction fees when force-closing. Otherwise the coordinator isn't really balanced in case of needing to force-close certain contracts.

[bonomat]

But things still get complicated as positions are rolled over! Rollovers could easily unbalance our expiries. Do we also need to ensure that positions our only rolled over as the counter positions are rolled over too?

Yes, I came to the same conclusion: rollovers should always go to the same next global expiry.

On a related note, another aspect that needs to be taken into account to minimise coordinator risk is that the coordinator must not have to pay for on-chain transaction fees when force-closing. Otherwise the coordinator isn't really balanced in case of needing to force-close certain contracts.

Agreed, @holzeis and me talked about that in the past: best would be if we put these fees all on the user. Note thought that this has an effect on the trust, i..e. the user kinda trusts us to not missuse the cheap force-closures.

[jooray]

The force-closes are asymmetric. If the coordinator needs to force-close, they should pay the fees, if the counterparty force-closes, they should pay their fees. The risk of paying fees should be included in coordinator fees, I would not introduce another complication. Coordinator should be profitable long-term from the fees and occassional force-close should be included in the business case.

How does the roll-over currently work? Do I need to regurarly open the app?

[bonomat]

How does the roll-over currently work? Do I need to regurarly open the app?

Yes, we decided on a "rollover weekend", i.e. your position expires on Sunday 15:00 GMT and if you come online (open the app) between Friday, 15:00 GMT and Sunday, 15:00 GMT you will extend your position by another week.

We are playing around with push notifications which can trigger a background task, that way you don't have to "open" the app, but your phone needs to be online in this time period.

If the coordinator needs to force-close, they should pay the fees, if the counterparty force-closes, they should pay their fees.

We came to the conclusion that it's not that easy to apply this mechanism. One problem we are facing is that the coordinator is "attackable". The trader might now always have an incentive to collab-close a channel or to come back online because he lost some money, in that case, we will have to force-close the channel leaving the coordinator with potentially high fees.
To overcome this we were thinking of treating these fees as a form of a bond/security deposit: the user gets it back if he comes back online and collaboratively close the channel with the coordinator. It is true though that this introduces some level of trust, i.e. that the coordiantor does not force close on the user unnecessarily.

[jooray]

What is the incentive? They will lose money anyway, force-close will not give them money, so there is no incentive to chicken out, only to "punish" the counterparty. This looks like extra complexity that might become problematic. But yeah, it is a design choice.