- wallet feed that sends balance + current address
- display in UI (balance + address) in separate wallet component (shared for taker and maker for now)
Includes two seed files that are already funded with some testnet coins. We can share those for testing for now. If more funds are needed I'm happy to top them up.
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.
Achieving this is rather tricky due to the nature of our multi-page
project. We need to solve several problems:
1. We want a single npm project that produces two independent bundles.
2. We want our paths to be relative to the serving URL, that is `localhost:3000`
in development and in production, whereever the backend is hosted.
3. We have independent backends, hence requiring different `server.proxy`
configurations.
We solve (1) by using vite (already prior to this commit).
To solve (2), we simply remove all absolute URLs from the code and replace
them with absolute paths which will be relative to the serving host.
This creates a problem: Prior to this patch, we only have one devServer running
that would serve both frontends under a different sub-directory (/maker and /taker).
Even though this worked, it was impossible to create a proxy configuration that would:
- Forward API requests from `/maker` to `localhost:8001`
- Forward API requests from `/taker` to `localhost:8000`
Because in both cases, the API requests would simply start with `/api`, making
them indistinguishable from each other.
To solve this problem, we needed to serve each frontend separately. Doing so
would allow us to have dedicated proxy server configurations and forward the
requests to `/api` to the correct backend.
Unfortunately, the intuitive approach of solving this (have a `maker.html` and
`taker.html` file) does not work. With React being a client-side routing framework,
full page-reloads would be broken with this approach because they would be looking
for an `index.html` file which doesn't exist.
To work around this issue, our final solution is:
1. Use a dynamic ID to reference the desired app from within the `index.html`: `__app__`
2. Use a vite plugin to resolve this ID to the file in question: `maker.tsx` or `taker.tsx`
Fixes#6.
Extract the functionality into its own module, as the logic was exactly the same
on both sides.
I've introduced 2 new concepts:
- "own" - the caller of the function, it's either taker or maker,
depending on the OwnParams parameter,
- "other" - the other party, the opposite role.
A threshold is added. This is needed because a malicious user might "change their mind" and publish transactions at any time trying to get out of the contract. The refund timeout should ensure that the refund transaction can only be published if the oracle does not publish a signature.
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.
By doing a single `cargo build` ahead of time, we are creating all
necessary binaries at once. This allows our cache to work for tests
as well as the binaries.
There is also no need to use release binaries for the smoke test.
Building debug binaries is a lot faster and serves the same purpose:
Checking whether the application actually starts up.
- 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
Daniel Karzel
Thomas Eizinger
dependabot[bot]
Mariusz
Philipp Hoenisch
Philipp Hoenisch