Terminology

[thomaseizinger]

BitMex seems to call the "settlement interval" funding period and interest is called funding rate. Should we transition our codebase to these terms?

Another mess we should sort out is "orders" and "offers".

[luckysori]

I don't like https://github.com/itchysats/itchysats/blob/1441c8fd73ec5576ce941cda7e9d8bcb91c1972b/daemon/src/model/cfd.rs#L1455 for that struct. We don't use the term dlc in maia at all, because it is a similar but different protocol to what's understood as a DLC protocol.

I know the short name is appealing, but I would prefer something like PreparedCfd. Or just Cfd and then we can rename the current Cfd struct.

[thomaseizinger]

Hmm, why is Dlc not appropriate? The way I look at it is that Dlc is the blockchain/crypto(?) primitive that enables our Cfd. And this struct contains all the data related to that.

[luckysori]

It's probably too controversial at this stage but the Dlc struct holds information pertaining to a DLC and stuff that has to do with channels: commit transaction, revocation keys, publishing keys... If I were an external contributor/auditor I would be confused by the name.

[thomaseizinger]

Would you accept the view of this being one thing because we haven't separated out the channel implementation? Unless we decouple that more, I think this may be hard to resolve.

[luckysori]

I don't feel as strongly about this anymore. We could call it something like PerpetualDlc, but too many characters for a made-up concept.

[thomaseizinger]

Another topic is force-close, commit, non-collab settlement ...

Maybe collab-settlement should just be settlement? If we force-close, we are not really settling, are we?

[thomaseizinger]

A few thoughts on the whole offer / order / CFD mess:

1. The offer is what is sent out by the maker. An offer can be taken.
2. By taking an offer, the taker places an order with the maker.
3. Once an order has been filled, the taker has an open position with the maker. That is essentially what we are currently calling a Cfd. Setting up a contract is the process of filling the order.

For our model, I think the conclusion out of that is that a Cfd shouldn't exist up until we've set up the contract. Perhaps we should treat an Order as a dedicated aggregate with its own events?