Since we went live last week, we got bulk of requests from users for a public API to programmatically fetch prices from YOLO exchange. Today we are proud to announce that the API is live at https://api.yoloswap.com/.

Currently the API consists of one command, namely, getRatewith the following syntax:

Name       | Type   | Required | Description              | Example
-------------------------------------------------------------------
srcSymbol  | String | True     | Source token symbol      | EOS
destSymbol | String | True     | Destination token symbol | IQ
srcAmount  | Number | True     | Source amount            | 12.012

A successful response returns the conversion rate as a data and a successful return code (200).

{
    status: {
        code: 200,
        message: "success"
    },
    data: 1878.6507
}

For example, to check the conversion rate of EOS to IQ for 12.012 EOS quantity is returned by calling https://api.yoloswap.com/getRate?srcSymbol=EOS&srcAmount=12.012&destSymbol=IQ

A response with data=1878.6507 indicates that for 12.012 EOS, a total amount of 1878.6507 * 12.012 =22566.3522 IQ tokens will be given.

Currently, the supported tokens are: EOS, IQ, CHEX, BNT, EMT, PTI, ARN, and INF. Also, only conversion between EOS to token or token to EOS is supported. We will update the api whenever a new token is listed on yoloswap.com.

The API implementation is open source and can be found at https://github.com/yoloswap/YoloSwap

We welcome our community to give us feedback and feature requests in the API repository and in our other public channels.

The YOLO team is committed to building useful tools like this API and many more to come. This comes as part of our commitment to add value and liquidity to the projects in our network.

YOLO Beta Site is Live: https://yoloswap.com/

• Our ongoing Bug Bounty
• Join our Telegram Channel.
• Stay updated in our Twitter Feed.

Background — on chain market making

For over a year Kyber Network team is market making Ethereum ERC20 tokens over the KyberSwap DEX. On-chain market making dictates that at any point of time, a smart contract should provide ask and bid price quotes for its inventory. Over Ethereum network we implemented such market making system using two different approaches:

1. External price discovery — in this approach we query the price from centralized exchanges and periodically relay it to the smart contract.
2. Inventory based exponential price discovery — in this approach the price is determined uniquely by the size of the current inventory according to a fixed exponential formula. Given an initial inventory threshold T, the formula increases the token price (more expensive) when the contract has less than T tokens (to boost supply), and decreases the price when there are more than T tokens (to boost demand).

Each one of the approach has its own advantages and pitfalls. The external price discovery can support small inventory size while making sure that token is not traded with losses, however due to blockchain tx latency the external price discovery cannot react in real time (e.g., During high volatility situations, price discovery needs to quickly update sudden changes in price) and in addition the price injection has a cost in the form of transaction fees. As a result an additional spread must be introduced to compensate on the uncertainty in the period between price updated. The inventory based price discovery reacts to changes in inventory in real time, however requires relatively big inventory and in addition it underperforms in terms of profits as the price calculation primarily depends upon inventory size as opposed to mark to market pricing.

More efficient on-chain market making over EOS

The sub-second block time and the flexible transaction fee model in EOS allows us to improve the external price discovery by relaying prices more frequently and thus reduce the uncertainty time interval. However it is still far from real time behavior due to network latency and the possibility that multiple trades will occur in the same block.

The exponential liquidity reserve

The exponential liquidity reserve combines our two previous approaches.

Not only it supports small inventory by enabling external price discovery but also adjusts the price based on the internal inventory and thus react in real time to changes in the inventory size.

This allows the market maker to send external price updates less frequently, when there are big changes in market price, while the exponential formula adjust the price during small changes in price.

Current state and future plans

The external price discovery reserve is used by Kyber on Ethereum blockchain for over a year and generated profits to market makers who used it, however we often get feedback from them about the sub-optimal way it price big quantities and one-sided volume. Due to the strict transaction fees model we were forced to introduce an ad-hoc linear step function, which cannot fully capture the desired change of price for a given quantity.

In addition, the inventory based pricing is being used for over 8 month by over 10 projects. This reserve is very popular as it requires very little maintenance. However the minimal inventory requirements are in the order of $30,000.

The YOLO network will offer the unified solution, namely, the exponential liquidity reserve, which support relatively small inventory size while still allowing real time on chain reaction to big changes in inventory. Initially the external price discovery will be done infrequently by manual operations, however we are excited to see how the full system work in couple of month time when the development of a supporting backend is completed.

KyberNetwork Exchange Model

At KyberNetwork, the exchange fixes a rate between two tokens and users can buy and sell tokens according to this rate. For example, an exchange rate of ETH/GNT 666.68 means that the exchange would buy 666.68 GNT in return to 1 ETH and vice versa (a small spread between sell and buy price is plausible). This exchange model, which is common in FOREX (e.g., USD/EUR exchange), guarantees that a user can always instantly execute an exchange, without the need to wait for a buyer.

However, the reserve operator needs to ensure that there are sufficient ETH and GNT holdings in reserve in anticipation of the demand and supply of both tokens, in order to satisfy user requests and to evaluate the true market-price of ETH-GNT pair.

More formally, a reserve operator will have to constantly decide on the these aspects:

1. Target portfolio — how much tokens of each type to hold
2. Re-balancing technique — how to strive to target portfolio structure after trades are executed.
3. Pricing technique — how to estimate the true market price of pairs of tokens.

In the next sections, we describe each of the items in greater depth and survey basic standard strategies.

Target Portfolio

The target portfolio is the distribution of the holdings of the exchange operator. For example, if an exchange only trades ETH, GNT and DGD, a possible target portfolio is 70% ETH, 22% GNT and 8% DGD. Alternatively, the portfolio can be also be represented with numbers of tokens of each kind, for example: 10,000 ETH, 200,000 GNT and 128,000 DGD.

Two main considerations should be taken into account when deciding on target portfolio:

1. Subjective expectations on token value: if the operator predicts that current GNT token value is expected to rise (relatively to other tokens), then he should increase the relative weight of GNT in his target portfolio. A textbook strategy is to set target portfolio to the relative market cap of each of the tokens. I.e., if DGD market cap is 5% of the combined market cap of ETH, GNT and DGD, then 5% of the target portfolio will be DGD.
2. Expected trading volume: exchange should hold enough tokens to support daily trade volume for each token. A possible strategy is to hold only the minimal amount of tokens that are needed for daily trading, and hold the rest in Ether or other more stable currencies (crypto or fiat).

The target portfolio could change over time according to operator preferences and personal experience. On the other hand, the actual portfolio, namely, the actual holdings of the exchange, are constantly changing after every trade. The role of the re-balancing component, which we will come to in the following section, is to make the actual portfolio as close as possible to the target portfolio.

Re-balancing

Once a target portfolio T is fixed, the re-balancing component role is to buy and sell tokens, from and to other brokerage-firms (e.g., exchanges like Poloniex or Kraken) until the actual holdings are close enough to T. Three classical re-balancing strategies are:

1. Auto-instant: a re-balance is made after every buy/sell operation. For example, if a user bought 500 GNT tokens from the exchange at the price of 1 ETH, the exchange operator will immediately use the 1 ETH to buy 500 GNT from other exchanges. By doing so, the exposure of the operator to price fluctuations is minimized, and this method is suitable for operators that wish to base their earnings mostly on buy/sell spreads.
2. Time-spacing: a target of H hours is set for full re-balance. Small partial re-balances are done at every M minutes. This technique exposes the operator to more risk, but on average allows the exchange operator to buy and sell tokens from the market at better rates.
3. Price-spacing: the portfolio re-balancing is done only when operator witnesses significant moves in token prices. For example, a re-balance operation for GNT is done only if GNT price goes up (or down) by 5% in comparison to its price in the last re-balance operation. This strategy is good if a reserve operator wants to perform the re-balancing act only when the prices are more favourable to its holdings.. However, the downside is that the reserve could be over depleted/inflated if the market does not move in the owner’s favor.

For all re-balancing strategies, the best-priced exchanges will be exhausted first, for all available liquidity, to ensure operator get the best price.

Pricing

A reserve operator always aims to offer true market prices for buy and sell trades, up to some small spread in buy/sell rates. Indeed a lower rate would cause him loses in every trade, while a higher rate would make users to prefer other exchanges.

At KyberNetwork we do not believe that market price can be determined by a fixed formula. Instead a (human) operator should decide on an automated policy for determining prices and update his policy over time according to observed performances and behaviours of token pairs. Below we survey the two most basic techniques for determining market price:

1. Quote-price: the operator scan all market prices offered by brokerage-firms and base its price as the average (or median) of all prices. A simple average (or median) is commonly used in FOREX by non-financial savvy operators. However, in the crypto world, where liquidity is much lower, an exchange that offers low liquidity could dramatically disrupt prices.
2. Liquidity-weighted-quote-price: To overcome bias from low liquidity exchanges, one could use the more accurate method of liquidity-weighted-price. Here, a weighted average of the price is taken, where the weight of an exchange corresponds to its liquidity. For example, if in exchange A the ETH/GNT rate is 600 with 1000 tokens up for sale, and in exchange B the rate is 700 with 2000 tokens for sale, then the liquidity-weighted-price is 666.667.

When the market price has been decided, the operator determines the buy/sell spread. The spread is dynamic and could vary over time, and should take into account these considerations:

1. KyberNetwork maximal spread — To stay competitive, KyberNetwork will dictate spread upper bounds for exchange operators.
2. Liquidity of token — For competitiveness purposes, liquid tokens will have lower spread, while illiquid tokens will have higher spread.
3. Target portfolio — If the re-balancing algorithm aims to increase the holdings of the token, then a lower spread is set for sell orders. Conversely, if quantity is to be reduced, then lower spread is set for buy orders.

Conclusion

In this post, we gave an introduction for the basic architecture of a crypto exchange. While the components are similar to those of FOREX exchange, the dynamic nature of crypto markets makes it more challenging to decide on the optimal parameters. These parameters should be adjusted by the operator according to his point of view and over time according to the observed performance of the exchange.