tdex-network / dev-portal Goto Github PK

This should touch

• Forking the repo and locate the pkg folder to create a file
• Detailing the Go interface to satisfy
• Detail the checks to sanitize the inputs
• Writing an unbalanced formula
• Build the daemon, run and make a custom trade in regtest

Following this discussion, it could be worth adding a rpc like the one below to the trade service to expose data about market volumes on a given time range.

rpc MarketVolume(MarketVolumeRequest) returns (MarketVolumeReply) {
    option (google.api.http) = {
      post: "/v1/market/volume"
      body: "*"
    };
}

message MarketVolumeRequest {
   Market market = 1;
   TimeRange time_range = 2;
}

message MarketVolumeReply {
   uint64 quote_asset_volume = 1;
}


message TimeRange {
  // predefined time_period till now
  PredefinedPeriod predefined_period = 1;
  // granular time range
  CustomPeriod custom_period = 2;
}

message CustomPeriod {
  // start_date in RFC3339 format
  string start_date = 1;
  // end_date in RFC3339 format
  string end_date = 2;
}

enum PredefinedPeriod {
  NULL = 0;
  LAST_HOUR = 1;
  LAST_DAY = 2;
  LAST_MONTH = 3;
  LAST_3_MONTHS = 4;
  YEAR_TO_DATE = 5;
  ALL = 6;
}

This issue tracks ideas and discussions for the Pool concept.

Pool

_Providers can pool together liquidity registering their endpoints into a distributed service mesh, creating a direct bi-directional stream connection to communicate their reserves/prices. The pool acts also as a first responder for traders to lookup for the provider's aggregated market prices and to register the trader's limit order proposals.

The main purposes of Pool are:

1. Accept requests from traders using the same interface defined here.
2. Let Liquidity Providers register themself and keep track of the network topology.
3. Let the traders placing limit orders. Maybe dedicated protocol?

NOTICE The provider joining the pool MUST serves only trade requests coming to the the pool, cannot serve traders directly.

https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-sitemap

We must update BOTD#3 by moving to psetv2 (drop in/out blinding keys and add unblinded inputs) and by adding fee asset and amount to the swap request.

It is also very important to describe thoroughly how to use these new fields, in particular how to correctly charge the fees to either amount_p or amount_r.

At the very end of the Configure CLI section, it would be better to mention the daemon's env var to use to make it run without macaroons out instead of just talking about it like:

If instead, your dameon's Operator interface is not proteced by this type of authentication/authorization (meaning you exported the env var TDEX_NO_MACAROONS=true at start-up), then you need to run:

https://docusaurus.io/docs/versioning
Doc says: "Versioning is best suited for websites with high-traffic and rapid changes to documentation between versions. If your documentation rarely changes, don't add versioning to your documentation."
What do you think?

Suggesting to use the same fonts as in Tdex-App.
https://fonts.google.com/specimen/DM+Sans for most text content.
https://fonts.google.com/specimen/DM+Mono for specific values or short text that would benefit being more stylish.

Fonts

• Osvald for titles/headings
• Roboto mono for paraghraph

Mockup

Background asset

Let's add an API to fetch the spot price of a market. Without this API, one must make a preview with an arbitrary amount to fetch the current market price.

Spec:

rpc GetMarketPrice(GetMarketPriceRequest) returns (GetMarketPriceResponse) {
   option (google.api.http) = {
      post: "/v1/market/price"
      body: "*"
    };
}

message GetMarketPriceRequest {
  Market market = 1;
}
message GetMarketPriceResponse {
   double spot_price = 1;
   uint64 min_tradable_amount = 2;
}

Remove blog and keep footer link that redirect to Medium.

The Trade protocol spec must make clear that the inputs of a partial transaction sent within a TradePropose message must contain the RedeemScript/WitnessScript for every P2SH/P2WSH input.

This is because by design the daemon is in charge of adding the network fees and without these info, it simply cannot do its job correctly.

Making this explicit forces both parties to make sure that the constrain is respected:

• the daemon must reject the partial transaction because it's malformed in case its partial inputs miss those fields
• the client must enforce this condition to sanitize the transaction before making a TradePropose request