Simplify model's state machine as PendingClose only matters for the UI
(for user feedback & available actions).
Disallow proposing another settlement if one was already signed.
The daemon adds `CfdDetails` that contains:
* `Vec<TxUrl>` - relevant transaction-id URLs to block explorer based on the state and bitcoin network
* `Option<bitcoin::Amount>` - The payout if we already have an attestation
* Display tx-urls and payout when unfolding the cfd row in table
- Handles the Oracle's attestation in the cfd actor, transition according to the knowledge we have about the timelock expiry already.
- Tries to publish the CET if we are in `CetStatus::Ready`, i.e. both the attestation and timelock expiry happened. We try publishing if either event happened, and just print a log in case it's not ready yet.
- Tries to re-publish CET if we are in `PendingCet` upon restart.
- Re-triggers CET monitoring upon startup.
- Extends any state after `ContractSetup` to be able to store the attestation. (see below for ideas to change that)
Things that could be done different:
Currently we are carrying on the attestation through a lot of states - because we cannot just transition the user to `OpenCommitted` because it is a user decision to go for commit, but we have to keep the attestation around once it happened.
To reduce the state complexity, we could store the attestation independent of the state, but associated with the cfd.
This would make things a lot simpler, but we would then always have to go to the database to check if the attestation is already around (which might make other parts more complex).
If the switch is enabled, the maker gets price suggestions based on the current
ask price on Bitmex + 3% spread.
Auto-refresh turns off whenever user modifies the field manually, and can be
re-enabled later if desired.
Fixes#214
Add support for multiple update proposals.
A taker might request to update/change a CFD in different ways, e.g.: propose to settle it or roll over.
In order to support different scenarios we introduce another layer of abstraction.
The rest of the changes creates a boilerplate for the actual rollover protocol.
By removing the onclick handler on the table row, clicking any button in the row does not fire the onclick handler of the row as well.
This has the effect that for expanding the row you need to click the expand button.
Red colour is best used for drawing attention to unusual things or marking a
hazardous action.
Sell positions on the maker side are an expected & common thing, so there is no
need for the sell positions to stand out.
Keep track of outgoing/incoming settlement proposals in a hashmap inside the CFD
rocket that is available as a Rocket state in order to derive correct CfdState
for the UI.
Add placeholders for actions for accepting/rejecting settlement offers in the maker.
Also:
- rename Accept/Reject in few places to reduce ambiguity between interacting
with an order and a settlement proposal.
- allow only one in-flight settlement proposal from the taker
CfdTable uses react-table which resets its state if the data sources changes. We don't want some state to reset, e.g. sorting and un-expanding because that will mess with the user if the table suddenly changes.
Note: it looks like that the provided types are missing this field. It's been tested and it works as expected but we need to @ts-ignore because tsc would complain.
* Offer price based on current price
To keep it simple we set the offer price to current price + 3% spread if we have a current price and the offer's initial value is 0.
This. means we cannot set the offer price to 0 anymore, but that is OK.
Additionally, there is a refresh button so the maker can refresh the offer price (no auto-refresh for now).
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
For calculating the Profit/Loss in BTC we use a simple forumla:
- for long: `profit_btc = quantity_usd * ((1/initial_price)-(1/current_price))`.
- for short: `profit_btc = quantity_usd * ((1/current_price)-(1/initial_price))`.
We round the p/l to 6 decimal points in the UI.
P/L is easier to understand in percent. For the UI we round to 2 decimal points.
Caused trouble because of route collisions, so the integration was done now.
Required distinguishing Maker and Taker on the cfd level, which comes in handy anyway.
We distinguish by order origin, but still map to a `Role` enum (`Taker` / `Maker`) for readability.
To avoid duplication the `Role` from contract setup was moved into the model and used throughout.
All display related decisions are taken in the UI, but on top of the UI's model.
For this purpose we introduce classes for `CfdState` and `Position` so we can add the relevant mapping functions to these classes.
To achieve the mapping from daemon sse even to the `Cfd` / `Order` interface (that now contain classes instead of just primitives) we extend the sse hook to accept a mapping function.
We define this mapping function for `Cfd` and `Order`, because those contain classes, for all others we just use the default mapping.
Actions are dynamically rendered based on the state.
The daemon decides on the action name.
A single post endpoint handles all actions.
The UI maps the actions to icons.
Co-authored-by: Thomas Eizinger <thomas@coblox.tech>
We can create a grid that has two columns:
- The first one is set to `max-content`.
- The second one is set to `auto`.
This will make the first columns as wide as the widest row and the
second column will take up the remainder of the space given by the
parent container.
When sorting the triangle appears next to the header text - that is expected and standard behaviour.
The span was always rendered (also with no sorting), and message up the alignment of the text.
Additionally add a text-align right for fixing the `State` header, that was somewhat floating around.
The Grid was restrictive and caused problems overlapping things.
We can achieve better layouting with flex components (for now mostly HStack and VStack flexes).
We can eventually also add space bounds to the flexes for more layourting (i.e. graph should take 70% on right...), but for now I kept it rather simple.
I experimented with Grids for the tiles where we group information (i.e. Buy, Order) but it did not look good, so I amd using flexes with fixed label width for better looks.
Bundling the frontend does not necessarily require type checking,
nor should type checking imply bundling.
TSC is also fairly slow. Separate the two and invoke tsc separately in
CI.
The only thing that has to stay in the root is the `index.html` file,
otherwise the dev server doesn't pick it up.
Also make sure our frontend tests actually run and pass in CI.
Mariusz Klochowicz
DelicioiusHair
Daniel Karzel
Philipp Hoenisch
Lucas Soriano del Pino
Daniel Karzel
Thomas Eizinger