Includes validating that the amount the other party commits to is the expected amount based on calculating the counterparty margin out of the CFD values.
Note: We could also remove the lock amount from the messages and use the calculation on both sides - that would simplify things.
Flattening the Cfd out in the internal mode has caused duplication and confusion.
This refactor puts the Order into the Cfd to make relations clearer.
Note that once we have multiple leverage the leverage and liquidation price will have to move into the Cfd because they depend on the user's choice then.
This should be trivial to do.
The buy margin is calculated from `initial_price`, `quantity` and `leverage`.
The sell margin is calculated from `initial_price` and `quantity` (no leverage trading for the seller at the moment).
Includes several refactors:
- Separate API interface for `Cfd` and `CfdOffer` when mapping `toSseEvent`. This allows internal modelling to be different than the exposed API.
- Remove the profit calculation internally, it is only relevant on the UI feed API level.
- Move code that is specific to taker/maker http API from `model` to the respective `routes` module.
- Some simplification of the calculation model of `Usd` (could be further improved by deriving calculation traits)
- Introduces `OfferOrigin` used to save the offer's origin as `mine` and `others` in the database. This is used to properly derive the CFD position from the offer.
- Add wallet to maker and taker.
For now we have different, static descriptors with a hardcoded DB
path. We also only operate on testnet and use sled as a database.
- Associate each CET with a unique nonce_pk
Eventually a set of `(message, nonce_pk)`.
- Share transactions with maker
- Add serialisation support to adaptor signature
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
Co-authored-by: Lucas Soriano del Pino <l.soriano.del.pino@gmail.com>
Daniel Karzel
Thomas Eizinger