Waves DEX API (official team's communication)

Core Development
1

Hello everyone! Here we’ll be discussing DEX API changes and improvements. Also, you can ask any questions related to API.

Here is our main API documentation: DEX API
REST API Explorer: https://matcher.wavesplatform.com/api-docs/index.html

3 Likes
2

Currently, DEX supports deletion of orders in the final state (Canceled or Filled) from Order History. It’s a controversial method that rarely exists on other exchange APIs.

Our proposal is to deprecate this method:

POST /matcher/orderbook/{amountAsset}/{priceAsset}/delete

It will remain in the current version of API but executes “No Operation” to not breaking the existing clients. Later it can be removed.

Other changes will affect getting order history method (by AssetPair and PublicKey):

GET /matcher/orderbook/{amountAsset}/{priceAsset}/publicKey/{publicKey}

We’re working on the current optimization of Order History storage. This method will be unified with All Order History:

  1. At first, all active order is returned and the remaining capacity (up to 100 orders per one pair) will be supplemented with inactive orders in chronological order.
  2. activeOnly parameter will be added to return only currently open orders.
  3. By default activeOnly = true if not specified.

Please, provide your cooments and suggestions regardign these changes.

2 Likes
3

Hi there!

Actually I have a question here concerning removal of /delete method. Have you got any usage statistics for this method? I guess it is not correct to delete it as some logic can rely on it somewhere. It breaks backward-compatibility of your API.

Why have you decided to delete it? Because each and every software uses it and it slows down operations because of internal implementation or just to be aligned with other exchanges APIs?

I want to encourage you to use Parallel change (Parallel Design) pattern, it is very important for public APIs if you want your clients be with you.

Personally I used this method widely and now part of my software has been broken. Broken software == upset clients == drawback to business.

Thanks.

2 Likes
4

Hi @goliaf!

Thanks for your feedback. Actually, we haven’t deleted this method but make it do nothing, because it’s wired to delete something from history and also has some technical reasons behind it.

Also, we’ve added activeOnly method to GET /matcher/orderbook/{publicKey} method if you don’t want finished orders (in Filled or Cancelled status) in your response.

Could you please clarify how you software became broken?

1 Like
5

I was working on api and really get tired of current history books. Do we really have to get the id of order on the exchange? Why don’t we have an option to cancel order with this method
/matcher/orderbook/{amountAsset}/{priceAsset}/cancel and get the info if it is filled or else.

6

Btw, while working on matcher could you please change testnet pairs. All based on waves market eg: usd / waves. Make it same with mainnet. Difficult to use testnet while programming trading bots. Also having difficulties with decimals :joy::zipper_mouth_face:

7

muito bom o procedimento aplicado

8

New validation rule for order price.
With the new version of DEX that will be on mainnet next week, we’re going to apply additional validation to Order price.

You may already know the following formula to convert raw price from an order in the blockchain to the human-readable form:
PriceDecimals = 8 + (PriceAssetDecimals - AmountAssetDecimals)

Current Problem:
For pairs where PriceAssetDecimals > AmountAssetDecimals price can contain more decimals than PriceAssetDecimals.

Example:
Pair is WCT/WAVES, price = 16073267999999
PriceDecimals = 8 + (8 - 2) = 14
UI Price = 0.16073267

This price was previously valid for DEX, but non-zero decimal after 8th digits are not needed and hidden in UI.
Only 8 significant digits will be shown in UI price = 0.16073267
and valid price in Order JSON should be price: 16073267000000.

16073267999999 (0.16073267999999) - Invalid price
16073267000000 (0.16073267) - Valid price

The new added validation will check this and won’t allow such prices with non-zero digits after 8th digit with error:
“Invalid price. Last {N} digits should be zero”, where
N = PriceAssetDecimals - AmountAssetDecimals

1 Like
9

Cancel all active order.

Using new API methods you can cancel all active orders by a pair or for all pairs in one call.

For both methods, you should use the request body without order id, where signature sign publicKey ++ timestamp bytes

{
  "sender": "string",
  "timestamp": 1543417471843,
  "signature": "string"
}
1 Like
10

Hi,

What is the api uri to receive all ‘asset/WAVES’ pairs?

gr

11

Is there any way to get more than 100 orders from DEX?
/matcher/orderbook/{publicKey} does not seem to have any limit modifiers

12

At the moment DEX database stores only 100 last order. But you can use our dataservices to get more orders from the blockchain. And also we going to implement DEX long-term storage for all orders and events soon. After that, you’ll be to query more order.

13

Tick Size on Waves DEX

We’d like to present a new feature for our DEX - Tick Size, which is the minimum price movement of a trading pair. E.g. at the moment we have the following prices for ETH/WAVES orderbook:

| 557.84692412 | 155.48925217 |              |
|   3.22305817 | 155.48922841 |              |
|              | 154.60404461 | 499.79072965 |
|              | 154.60404444 | 322.13687271 |

Obviously, there is no need for such small price differences, 5 significant digits would be enough, i.e

155.48
154.60

The main reason behind it is to reduce the spread between the buy and sell orders, as well as to make useless to constantly resubmit an order changing the price just by 1e-8 without making a trade and reducing the spread.

First, we’re going to implement tick size in the most commonly used pairs, like WAVES/BTC, ETH/WAVES, ETH/BTC.

Implementation Plan

We’re going to implement this in 2 steps:

  1. First, accept orders with the price that are less than the minimum tick size, but put them in the nearest level in orderbook that. E.g. if tickSize = 0.01 and a user submits a SELL order with the price 155.698 it will be placed in the 155.70 level of orderbook. But when it’s matched with contra order the execution price will be the one that is specified and signed in the initial order, i.e. 155.698. Thus the user wouldn’t get any advantage of submitting such orders against tick size rules without affecting the spread. The orderbook will contain only 2 digits levels in both bids and asks after enabling that tick size.
  2. Reject orders that don’t satisfy minimum tick-size for the given pair

UI clients, including Web and mobile client, will treat the first step as mandatory restriction and won’t allow entering more digits than allowed by tick size. So the 1) step is more for automatic bots until they change their algorithms to taking into account tick size settings.

Timeline

The pilot trading pair will be BCH/WAVES to which we’ll apply 0.01 ticksize. After 2 months of testing, we’re going to enable strict validation for prices in that pair.

After a successful testing period, we’ll set up ticksize for other most tradable pairs, including WAVES/BTC, ETH/WAVES, Vostok/WAVES, BCH/BTC and others. The implementation timeline will be the same for them: first, enable 2 months rounding mode followed by the strict validation.

API changes

A new API endpoint:

GET /matcher/orderbook/{amountAsset}/{priceAsset}/info

Returns different settings and restrictions for the pair, e.g.:

{
  "restrictions": {
    "stepAmount": "0.01",
    "minAmount": "0.01",
    "maxAmount": "100000",
    "stepPrice": "0.0000001",
    "minPrice": "0.000003",
    "maxPrice": "100"
  },
  "matchingRules": {
    "tickSize": "0.000001"
  }
}

There are 2 fields related to tick size:

  1. matchingRules.tickSize - a setting to be applied for step. 1 from our implemetation plan.
  2. restrictions.stepPrice - strong restriction for step. 2. Default value is 1e-8.

So for the above example: stepPrice = 1e-7 and tickSize = 1e-6, our DEX won’t accept orders with 7 digits price after comma, but bids and asks in orderbook levels will have only 6 digits.
UI client is taking the least common multiple of two fields and apply validation rules with it. But usually, only 1 setting will be defined.

Additionally, API endpoint:

GET /matcher/orderbook

will include all non-default settings for all pairs.

Tick size for WAVES/BTC pair is already enabled on TestNet DEX, you can look at the settings here:
https://matcher.testnet.wavesnodes.com/matcher/orderbook.

1 Like