Our MVP release includes a web wallet, a reserve manager tool and smart contracts that (i) provides the backend interface for the web wallet to execute exchanges and payments and (ii) provides the backend interface for the reserve manager to set exchange rates and manage liquidity (see figure below). The illustration and explanation of the web wallet and reserve manager dashboard were demonstrated over a series of video tutorials.

In this post, we will give an overview of the smart contracts, along with the description of their roles in KyberNetwork. In our MVP release, the smart contract consists of three main modules, namely, KyberNetwork, KyberReserve and KyberWallet, and a few other mock modules that simulate testnet tokens and centralized exchanges.

For this particular entry, we will focus only on the main modules of the smart contracts, starting with how an end-user interacts with these contracts, followed by interactions of reserve managers, before ending with possibilities that we can expect from KyberNetwork in the future

MVP software release. A web wallet, smart contracts, and reserve manager tool.

User Interaction

KyberNetwork enables users to perform these functions:

Token exchange Payment service Proxy payments

Token exchange

In simple token exchange, user want to buy type B tokens in returns to type A tokens, for a certain price (for simplicity we assume Ether is also a token). An exchange transaction involves a user to send type A tokens (for simplicity we assume Ether as a token) to the trade function in KyberNetwork contract, along with a minimum conversion rate for the (A, B) pair, and in return receive type B tokens. When deciding on the minimum conversion rate, user can query the present exchange rate with getRate function. However, there is a possibility that the rate will change by the time transaction is mined to the network. When the trade function is invoked, KyberNetwork queries all reserve instances via KyberReserve smart contract, and searches for the best conversion rate. If the best rate meet the user’s minimum requirements, then the trade request will be processed and the exchange will be executed by the chosen reserve via its trade function. Otherwise, if the minimum requirements are not met, the trade request will be canceled. It should be noted that the entire process is done within a single transaction. This Kovan testnet tx demonstrates a successful exchange.

A successful exchange is depicted in the diagram below.

Successful exchange

An unsuccessful exchange is described here:

Unsuccessful exchange

Payment service

For payment service, the converted token is used to make a payment to a different user or a service. For example, a user that holds only Ether might have to pay for Golem CPU services in GNT token. KyberNetwork supports such payment service by letting user specify a destination address for the converted tokens. An example for a payment service tx can be found here.

Payment service

Proxy payments

In the standard payment services through KyberNetwork, the recipient would recognize KyberReserve as the sender, instead of the actual sender/user. This is seemingly acceptable with instances where the item of exchange are not recorded on the blockchain, e.g. in the form of a cloud computing service or physical goods. However, in some cases it is crucial that the recipient recognizes the sender and not the proxy (KyberReserve). One notable example is ICO participation, because platform tokens need to be sent to user who made the contribution.

For the above mentioned purpose, proxy payment service, which KyberNetwork supports is needed, implemented in the form of KyberWallet module. The proxy payment wallet contract functions as an avatar for the user identity, and this wallet holds all of the user digital assets, such as: Ether, tokens, ENS domains and many others. With this wallet, a user can participate in ICOs and receive the ICO tokens to his wallet. The wallet has a convertAndCall function that allow user to instantly convert token A he holds to token B, and send it to another (for example ICO) contract immediately. All within a single transaction.

Proxy payment

The execute function allows the user to make standard payment/contract calls that do not require any conversion. Hence, a user can seamlessly use the wallet for any purpose he desires.

Reserve Manager

The reserve manager interacts with KyberReserve contract on-chain and with centralized exchanges off-chain. Each reserve has its own instance (i.e. an Ethereum address) of the contract. The reserve manager’s role is to set exchange prices and to provide the needed liquidity (i.e., Ether and tokens) for the reserve contract to support token exchanges.

The prices are determined according to the manager’s view of market price, by querying prices from existing centralized exchanges like Poloniex or Bittrex . With the setRate function, a manager feeds prices to the contract and sets the conversion rate for tokens pairs. In addition to the rates, the manager also sets an expiration time, after which the prices are no longer valid (i.e. a trade is not possible after the stated period, unless manager set new rates before expiration time). The pricing process is illustrated below. Note that in this figure, only the interaction between the manager and KyberReserve is done on-chain. The rest is done off-chain.

Reserve manager pricing

To provide liquidity, reserve balances (for each token) must be sufficient to support expected volume. The needed amount of each token is determined by the reserve manager, and because of the activities on the network, reserve managers need to re-balance their reserve holdings periodically (or on demand), by either buying tokens that are low in supply or by selling surplus tokens, relative to the targets set. The reserve contract provides a withdraw function that can send existing tokens to deposit addresses of centralized exchanges, where they can be converted to other tokens. Conversely, a manager can deposit Ether or tokens in the contract that he got from the centralized exchange.

Below we illustrate a simple re-balance process that happens immediately after an exchange has been performed by a user. After the exchange, the reserve holds 1 ETH more than needed, and 800 GNT less than needed. So, the manager re-balances the reserve by converting one ETH to GNT according to the best price that the market offers. Also, the interactions between KyberReserves are done on-chain, while the rest of the interactions are implemented off-chain.

Reserve manager re-balance their token holdings

Future Work

This MVP release provides a complete setup for a functional exchange over Ethereum kovan testent, however it is still serves mainly as demonstration for the actual KyberNetwork’s exchange system. With that said, for the smart contract side, these following items are still yet to be implemented:

KyberNetwork

Reserves fairness mechanism. A way to split a transaction request among the different reserves that offers the same type of tokens. For this release, the reserve that offers the best price will be selected. Restrictions on reserves. KyberNetwork could enforce its agreements with reserves with the smart contract. For example, the KyberNetwork contract can enforce maximum spread or minimum liquidity, and if a reserve fails to meet those requirements, then it will be de-listed from the network. Platform fees. At the moment, KyberNetwork does not collect any fees from the users’ exchange transactions. Upgradable mechanism. The dynamic and progressive nature of the blockchain space would mean that we need to constantly maintain the contracts and release upgrades. For example, agreements with reserve managers could change, and new and unexpected conditions and limitations could emergy. For this purpose we must make the main KyberNetwork upgradable. Also, it is very likely that we will use ENS domain name for that (we hold kybernetwork.eth domain).

KyberReserve

On-chain pricing logic. More advanced pricing techniques, like tiered pricing, would require on-chain logic (in the smart contract) to the actual price. This logic will complement the off-chain pricing set by reserve managers, by small changes to the market price to reflect an offer price. Failsafe mechanisms. Mechanism to halt exchanges and other services when abnormal trading patterns (e.g., sudden unexpected rise in demand for a certain token) are detected. Secure reserve manager system. The reserve manager tool is fully operated by the reserve manager, and it is the manager’s sole responsibility to maintain the integrity of the reserve. However, KyberReserve contract can introduce additional security mechanisms that could reduce the impact of a potential attack on the network or the reserve. For example, it is possible to restrict the withdrawal addresses of the reserve to predefined addresses such as reserve manager deposit addresses in centralized exchanges, or a cold wallet that is under the control of the reserve manager. Another possibility is to prevent sharp decrease in exchange price, so malicious attacker could not benefit from setting low prices on behalf of the reserve manager, taking advantage of cheap tokens.

KyberWallet

KyberWallet could be extended to better support the use of cold wallets. It is possible to create a close system which is controlled by a hot wallet, and can only perform token exchanges within KyberNetwork. In such a system, the worst outcome in the event of a hack (e.g. a malicious actor takes over a user’s private key) is an unintentionally altered portfolio, while the total value of the portfolio remain relatively unchanged. Withdrawal from this closed system is possible only to a secure cold wallet, as defined by the user. As such, users could securely do their day-to-day exchanges from their hot wallet (e.g., home PC), without getting exposed to the risks of potential hacks.

About KyberNetwork

KyberNetwork is a decentralized and trustless exchange that facilitates instant conversion of crypto-assets with guaranteed liquidity. Our protocol will be key to promote liquidity of crypto-assets in the blockchain ecosystem, and improve the perception of tokens as a tradable asset class to the greater public.

Please join our Slack group, follow us on Twitter and subscribe to our Medium blog for more updates.