UPDATE: Read about Kyber APR’s advantages over other models, including how it is more capital-efficient and provides lower slippage market making.

In order to further grow our network of reserves, we developed a new reserve type — the Automated Price Reserve (APR), mainly targeting entities such as token teams with larger token holdings, but without the need to commit extensive technical resources to maintain the reserve. In this post, we will explain the process of creating an APR, its specifications, the motivations behind it, and the current state of our liquidity network.

How the APR Works

The Automated Price Reserve relies on Kyber’s pre-defined algorithm set in the smart contract to automatically provide conversion rates for a token. It changes the price of the token based on the trades performed and the ETH/token inventory.

It starts with an initial supply of Ether and tokens and an initial price set at deployment which does not change until a trade occurs. Depending on the change in price with respect to the price of ETH and on market conditions (for example if users mostly BUY or users mostly SELL), the ETH or token inventory needs to be replenished in the reserve.

The figure below shows an example of how the price of the token changes as trades occur and based on the initial ETH and token inventory deposited in the reserve.

Figure 1: The price function, with relevant parameters, indicates the change in price with respect to the change in inventory as trades occur

Process for Creating an Automated Price Reserve

Creating an APR is a simple 3-step process. First, the following smart contracts need to be deployed on the blockchain: KyberReserve.sol and LiquidityConversionRates.sol. Second, the reserve manager deposits the initial ETH and token inventory into the reserve contract. Lastly, the reserve manager invokes the function setLiquidityParams() in the LiquidityConversionRates contract to set the liquidity parameters. After which, the reserve will be able to market make until its own inventory is depleted. Invoking setLiquidityParams() should be done once at the deployment of the reserve, and subsequently whenever inventory in the reserve is replenished.

The reserve manager needs to only decide on the initial liquidity parameters of the APR. Specifically, the following information needs to be considered:

Liquidity Rate Initial Ether Amount Initial Token Amount Initial Token Price Minimum and Maximum Supported Price Factor Maximum Buy and Maximum Sell Amount in a Trade Fee Percentage

These information will be used to calculate the parameters needed to pass into the setLiquidityParams() function.

Parameter Description

The parameters are as follows:

function setLiquidityParams(uint _rInFp, uint _pMinInFp, uint _numFpBits, uint _maxCapBuyInWei, uint _maxCapSellInWei, uint _feeInBps, uint _maxTokenToEthRateInPrecision, uint _minTokenToEthRateInPrecision)

There are several things to take note of in the list of parameters. First, notice that some parameters will have the InFp suffix. InFp refers to formula precision. While this is configurable, 2⁴⁰ is the recommended value.

r is liquidity the rate in which the price should move each time the ETH/token inventory changes in 1 ETH worth of quantity. For an r of 0.01, the price will move 1%. r is calculated taking into account the amount of initial ETH and tokens deposited into the contract, and the desired minimum/maximum price factor ratio. A smaller r also means more ETH and token inventory is needed to facilitate the liquidity.

For the minimum/maximum price factor ratio, it is recommended to start with a ratio of 0.5:2.0. This indicates that the inventory will suffice for up to 100% increase or 50% decrease in token price with respect to ETH.

Below is an example table for a token with a price of 0.00004258 ETH: