"Commit" vs "Force-close" vs "Non-collaborative settlement"

[thomaseizinger]

We have a bit of a mixture of names around "Non-collaborative settlement". Here is a proposal for resolving this:

1. "Commit" should only refer to the commit transaction.
2. The action of publishing the commit transaction is force closing a CFD.
3. "Non-collaborative settlement" should be removed from the codebase as it is the same as "force closing".

Input appreciated.

[klochowicz]

I'd like to pitch one more idea, that would also solve this issue:

• "settle" instead of "close" (that would imply the fact that it's a collab settlement, and you actually need the other party, because you need to settle with someone)
• "close" to denote that you are actually closing the Cfd with the oracle attestation event at the time agreed when you opened.

then we could have "settling" and "closing" cfd, two short verbs, that could be rolled out it the codebase.

@thomaseizinger what do you think of it?

Going back to your original proposal, I agree that force-close is better than non-collaborative settlement. 👍

[klochowicz]

Ok, makes sense. It could be in the interest of the maker to settle collaboratively though because it reduces on-chain transaction fees.

exactly, thus it would be in each maker's interest to allow short positions.

[bonomat]

I see that offering shorts has the positive side effect of letting people collab settle their longs but I'm not sure this is the right way.
Imho we should try to separate these two things.

[thomaseizinger]

Here is another take:

Just because a maker sends out an offer, doesn't mean they have to accept every order that is coming in. A maker could easily accept orders that nullify positions with a taker (that is our current collab settlement protocol) but reject orders that would result in more short positions.

[bonomat]

I think this is a bit weird and adds an additional meaning into the offers.
How would a taker distinguish offers from makers they are willing to take and offers they are only willing to take if it nullifies their position?

[thomaseizinger]

I think this is a bit weird and adds an additional meaning into the offers.

Does it really? Or does it only appear this way because we have a special handling of closing at the moment? It seems to be the same on a domain level. Why should be special case this in the software?

How would a taker distinguish offers from makers they are willing to take and offers they are only willing to take if it nullifies their position?

You don't really and I also think there is no need to. We already have an accept/reject functionality so we have to deal with the case of an order being rejected. We also established recently that we actually want this accept/reject step. Why not leverage that?

[thomaseizinger]

Regarding the terminology of "force-close": Perhaps we should avoid that. https://www.investopedia.com/terms/c/closeposition.asp talks about a concept of "force-closing" under the heading "Special considerations".

[klochowicz]

I think you can still interpret our "force-closing" in similar way the link posted above understands it. The way I read it it means that they are closed by one side, without other's consent in certain situations- our lack of cooperation by the other party follows that understanding.

[thomaseizinger]

Good argument!