Kuavdin Token - Whitepaper

Core Value Proposition

Kuavdin is set to be the first system to implement several ideal operating properties of an exchange, including:

• Trustless, Decentralized Execution
• Instant Trade Finality
• High Liquidity

Beyond Exchange: Payment APIs

Besides serving as a decentralized exchange, Kuavdin also provides payment APIs that allow Ethereum accounts to easily receive payments from any supported crypto token.

Example Use Case: Any merchant can now use Kuavdin's APIs to allow customers to pay in any crypto token, but the merchant will instantly receive the final payment in Ether (ETH) or another preferred token.

Roadmap and Cross-Chain Vision

While Kuavdin initially runs on the Ethereum network, our roadmap includes supporting cross-chain trades between different cryptocurrencies. This will be achieved using relays and future protocols like Polkadot and Cosmos.

This cross-chain functionality will enable Ethereum accounts to safely receive payments from Bitcoin, ZCash, and other cryptocurrencies via our payment APIs, establishing a trustless payment infrastructure across different chains.

1. Introduction

Emerging cryptocurrencies such as Bitcoin, Ethereum, and others have been gaining significant traction because they allow users to transact and manage their digital assets in a decentralized and trustless model, without relying on a third party. More interestingly, the Ethereum network, with its Turing-complete scripting language and trustless smart contracts, makes it easy to issue and digitalize custom crypto tokens. These tokens can represent real-world assets (e.g., Digix Gold token) or hold value within a specific platform (e.g., Golem Network token, Gnosis token, Augur token, and so on). To date, the total market capitalization of the most popular cryptocurrency assets is $72 Billion USD. This total market cap has tripled in the last five months and continues to grow.

1.1. Motivation

1.1.1. Risk of Centralization

As the Blockchain market grows and more crypto assets are introduced, the need to convert and exchange between crypto tokens is ever-increasing. The trade volume between, for example, ETH and Bitcoin is worth hundreds of millions of dollars per day on major exchanges. The total trade volume between ETH and other crypto tokens on its network, most of which are less than two years old, is also in the range of millions of dollars.

However, despite the decentralized and trustless nature of cryptocurrencies and crypto tokens, most of the trades occur on centralized exchanges which are vulnerable to internal fraud and external hacking. This is an ongoing concern, and a number of hacking incidents have been reported at various exchanges, affecting thousands of users and resulting in the loss of hundreds of millions of dollars.

1.1.2. Lack of Instant Exchanges

Existing exchanges—including both centralized and decentralized ones—often require users to wait for several minutes before allowing them to withdraw their funds.

1.1.3. Problems with Existing Decentralized Exchanges

The quest to build decentralized exchanges has been initiated by several parties on the Ethereum network. Although these parties build decentralized and trustless exchanges, they are still vulnerable to external manipulation because there is a delay between when an order is created and when it is accepted in a block.

There are other possible reasons why existing decentralized exchanges are not as popular as expected, despite having better security features:

• Expensive Order Book Management: These exchanges maintain an order book of users on-chain. As a result, the adjustment or cancellation of bid orders can be expensive for regular users. Repeated revisions of orders compound the issue as the cost escalates until a match between a buy and sell order is found.
• Off-Chain Negotiation Risk: Some exchanges attempt to resolve this by making the price discovery and negotiation process done off-chain via intermediate parties. A trade is only executed on-chain after the two parties have agreed on the rate. This raises trust issues regarding the intermediate party's role in finding the best counterparty for the trade.
• Security Vulnerability: We also note that "no-fee" orders are susceptible to adversarial Sybil or denial-of-service attacks.

1.1.4. The Challenge of Proliferating Digital Assets

As the number of ICOs increases, so does the introduction of new crypto tokens. It is logical to assume that investors will acquire a variety of desired crypto tokens as part of their investment strategy. The convertibility of one crypto token to another represents a new challenge for both investors and operators alike.

For instance, it may be a challenge for any party to allow an already deployed contract to accept new crypto tokens as a form of payment. This proliferation also introduces more room for implementation bugs and security flaws. As an example, a major bug during the DAO Token ICO distributed more tokens to SNGLS contributors than to ETH contributors, despite them contributing the same amount. Thus, there is a clear need to simplify the payment procedure for token holders, merchants, and users on the network.

1.2. The Kuavdin Solution

We introduce Kuavdin, an on-chain decentralized exchange providing several useful applications, including building a practical exchange and offering payment APIs for merchants and users to instantly and effortlessly convert tokens "trustlessly."

• No Order Book: There is no order book. Users will know the conversion rate before sending the transaction and will receive the corresponding amount instantly.
• Cost-Efficiency: Users do not pay any extra fees (other than the gas fees for the transaction). Kuavdin profits through a reasonable spread priced into the conversion rate.

Our system allows users to convert their existing token A to a different type of token B and send it to another user who only accepts payment in B—all in one single transaction.

More interestingly, Kuavdin introduces a new standard contract wallet to allow existing smart contracts, which currently only accept a few tokens, to receive payments from any future tokens supported by Kuavdin without any modification to the contract code. This enables contracts or merchants to access a wider class of users, receiving payments and contributions in any supported tokens.

Kuavdin's design features several novel constructions to support all these applications:

• Dynamic Reserve Warehouse: Instead of maintaining a global order book, we maintain a reserve warehouse which holds an appropriate amount of crypto tokens for maintaining exchange liquidity. The reserve is directly controlled by the Kuavdin contract.
  • The contract determines a conversion rate for each exchange pair of tokens by fetching the best price from all registered reserves.
  • The rates are frequently updated by the reserve managers, and the Kuavdin contract selects the best rate for the users.
  • When a conversion request (Token A to Token B) arrives, the Kuavdin contract checks if the correct amount of Token A has been credited, then sends the corresponding amount of Token B to the sender's specified address. The amount of Token A, after the spread/fees, is credited to the reserve that provided the Token B.
• New Standard Contract Wallet: This wallet enables the Kuavdin contract to send a user's newly converted tokens to their destination address on the user's behalf. The destination address will receive the converted tokens as if they were sent from the original sender, not the Kuavdin contract.
• Cross-Chain Support: Our long-term plan includes employing future features of the EVM language to build an efficient ZCash-Relay on Ethereum. A ZCash-Relay on Ethereum will allow us to support cross-chain trades between ETH and ZEC. We will also leverage future platforms like Polkadot and Cosmos to enable more comprehensive cross-chain trading and payments.
• Extensibility-Focused Design: The Kuavdin contract is designed with an extensibility focus, featuring well-modularized components. We allow dynamically adding any new tokens or delisting existing tokens, ensuring we can work with any future tokens or digital assets.

2. Kuavdin's Design

2.1. Actors in the Kuavdin Network

The network involves five distinct roles:

1. Users: Individuals, smart contract accounts, and merchants who send and receive tokens to and from the network.
2. Reserve Entity(ies): Provides liquidity to the platform. These can be our own reserves or third-party reserves registered by other market makers. Reserves can be classified as public (accepting public contributions) or private (not accepting contributions).
3. Reserve Contributors: Provide capital to public reserve entities and share in the platform profit. This role exists only for public reserves.
4. Reserve Manager: Maintains the reserve, determines exchange rates, and feeds the rates to the Kuavdin contract.
5. Kuavdin Operator: Responsible for adding and removing reserve entities, and listing/delisting pairs of tokens in the network. Initially, the Kuavdin team will act as the Operators to bootstrap the platform. Later, a proper decentralized governance structure will be established to take over this task.

The actors interact with the smart contract independently:

• Users send and receive tokens within a single transaction, without waiting for a response from the reserve or the Operator.
• The Kuavdin Operator manages the listing/delisting of reserves and token pairs.
• The Reserve Manager determines and feeds exchange rates to the contract for a fixed, short period (e.g., several seconds).
• The main contract relies on the Reserve Entity to guarantee high liquidity.

2.2. Dynamic Reserve Pool

Kuavdin guarantees high liquidity by leveraging a dynamic pool of existing reserves in the network.

• Multiple Reserves: Kuavdin allows multiple reserves, managed by different reserve managers (who may or may not be associated with the Kuavdin Operator), to co-exist. This enables better prices (by eliminating reserve monopoly) and guarantees better liquidity (by utilizing diverse sources).
• Low-Volume Token Support: Allowing different parties to manage their own reserves permits Kuavdin to support low-trading-volume tokens by off-loading the management efforts of those tokens to corresponding reserve managers.
• No Fund Custody: Kuavdin does not hold any funds of the registered reserves. Their funds are stored on their individual reserve contracts, which adhere to Kuavdin's ground principles.

When a trade/conversion request arrives, Kuavdin:

1. Fetches the conversion rates from all reserves that can process the request.
2. Selects the best rates and executes the request.
3. Guarantees that both the reserves and the users are safe: we do not keep any party's funds, and all transactions are atomic.

We note that upon launch, Kuavdin will likely start with only a single reserve provided by us as the main source of liquidity before other reserves are registered.

Why Reserves Should Join Kuavdin:

Kuavdin creates a platform for reserve managers to monetize their otherwise idle assets. By serving trade requests from users, reserves earn profit from the spread they define. While reserves can trade independently, they will achieve a higher trade volume due to the network effects of Kuavdin. We will drive user adoption through collaborations with wallet providers and other token projects.

Additionally, Kuavdin provides a Reserve Dashboard software to help reserve managers:

• Manage their reserve portfolio.
• Utilize standard and popular trading algorithms/strategies to automatically make prices and rebalance their portfolio.
• Flexibly implement and deploy their own custom strategies.

Reserve Security:

The security of reserves is a major concern, particularly for public reserves that accept contributions.

• Private Reserves: For private reserves (not accepting contributions), if reserve managers follow good security practices, the risk exposure can be confined, as the reserves are handled locally.
• Public Reserves: To mitigate the security risks of public reserves, we will employ a transparent fund management model, such as MelonFund (developed by MelonPort), so that contributors can track all trading activities done by reserve managers.
  • Transfer Restrictions: We plan to introduce restrictions to protect open reserves. For example, reserve funds can only be transferred to predefined addresses in the contracts (e.g., the reserve contract itself, or whitelisted external exchanges). This removes the risk of unwarranted fund extraction.
  • Rate Manipulation Prevention: To prevent managers from deliberately setting false or unreasonable exchange rates (e.g., to buy assets cheaply), we employ both:
    • On-Chain Mechanisms: (e.g., preventing unreasonable price changes without special authorization).
    • Off-Chain Mechanisms: A background monitor will watch and flag suspicious behaviors, halting transactions when the system detects dubious activities that undermine network integrity.

2.3. Main System Components

Kuavdin consists of the following major components:

• Smart Contracts: Includes the main contract (the entrance point for users and reserve managers), individual contracts to maintain the reserves, and a contract wallet that provides a convenient interface to all supported features.
• User's Wallet: Wallet apps with friendly interfaces to support users. Integrations with existing wallet apps like Status, Token, and Metamask will help improve adoption.
• Reserve Manager Portal: Aids the management of the reserve by displaying performance, network statistics, and supporting different strategies/algorithms for pricing and rebalancing. Managers interact with the Kuavdin contract via this portal.
• Operator Dashboard: Helps the Kuavdin Operator manage the entire system, allowing them to add/remove new reserves and change network parameters.

A Minimum Viable Product (MVP) was released in August 2017.

2.4. Kuavdin APIs

Kuavdin supports different API commands for Users, Reserve Contributors, Reserve Managers, and the Kuavdin Operator.

2.4.1. User API

Callable by any Ethereum account (normal or contract):

• Transfer(amount, source token, destination token, destination address)
  • Converts an amount of the source token (Token A) to the destination token (Token B) and sends the type B tokens to the destination address.
  • Example: Transfer(100, "DGD", "Melon", "0xb794f5...") converts 100 DigixDao tokens to Melonport tokens and transfers them to the specified address.
• GetExchangeRate(token A, token B)
  • Returns the conversion rate between Token A and Token B. Future support for different exchange rates based on trade volume is planned.

2.4.2. Reserve Contributor API

Callable by any account in the Ethereum network (relevant only for public reserves):

• ContributeReserve(token type, amount)
  • Contributes a specified amount of a certain token type to the reserve. The contributor receives an equivalent amount of reserve tokens/shares to represent their contribution (similar to MelonFund's model).
• WithdrawProfits()
  • Distributes profits proportionally to the contributions of the contributors.
• WithdrawContribution(KDN amount, token type)
  • An existing contributor can withdraw their contribution. The contributor can specify in which token type they wish to receive for their withdrawn contribution, and the conversion is done in the background.

2.4.3. Reserve Manager API

• SetRate(token A, token B, rate)
  • Used to set a conversion rate for an existing pair. In the real deployment, this will be replaced by a batch-update API to reduce gas costs.

2.4.4. Kuavdin Operator API

• ListPair (token A, token B, initial rate)
  • Introduces a new pair of tokens that Kuavdin supports.
• DelistPair (token A, token B)
  • Stops accepting trades between a pair of tokens.
• AddReserve (reserveAddress)
  • Adds a new reserve to the network.
• RemoveReserve (reserveAddress)
  • Removes an existing reserve from Kuavdin due to reasons like low liquidity or bad pricing.

2.5. Support Trustless Trading Cross-Chain

Chain relays, such as BTCRelay, enable communication between different blockchains. The launches of protocols like Polkadot and Cosmos will make cross-chain interactions even easier. Kuavdin will leverage these technologies to allow Ethereum accounts to receive payments from different cryptocurrencies via a trustless mechanism.

3. System Properties

3.1. Trustless and Secure

The Kuavdin Operator does not hold the users' tokens. By design, user's tokens are secure from theft losses. Users need not trust the intentions of the reserve entity or the KDN token holders, as the integrity of the operation is enforced and ensured by the smart contract.

3.2. Instant Trade

An exchange or conversion request is executed immediately within a single transaction. Users receive their exchanged token at the exact moment they transferred their original token. No deposit, confirmation, or waiting time is needed. This efficient and user-friendly feature distinguishes Kuavdin from most other existing and future exchanges.

3.3. On-Chain Exchange

The exchange runs entirely on-chain and is accessible to all accounts, including normal accounts and smart contracts. This allows smart contracts to directly interact with the exchange without a third-party intervention, enabling them to receive funds/payments from different tokens that they did not originally support. This feature establishes Kuavdin as an on-chain proxy payment platform for all accounts.

3.4. Compatibility

Kuavdin does not require any modification in the underlying Ethereum protocol or existing smart contracts to function. Our payment API can communicate with existing contracts without requiring any change on their side.

Furthermore, our new contract wallet allows a user to seamlessly pay with Token A to a contract that expects Token B, with the conversion from A to B handled by Kuavdin. The receiver will receive the payment as if it was sent by the original user.

3.5. Comparison to Existing Systems

We compare Kuavdin to existing systems in the table below. (We have intentionally left out Bancor, as they state their focus is on community tokens rather than general-purpose exchange.)

4. Applications

4.1. Instant and Secure Exchange

First and foremost, Kuavdin is an exchange. Unlike most existing exchanges, Kuavdin executes trade requests instantly. Moreover, Kuavdin does not hold users' tokens; thus, any theft or loss of user funds is prevented by design.

This contrasts sharply with most exchanges where a confirmation time of several minutes is typically required. Any malfunction during that waiting period could potentially result in inconvenience or, in the worst-case scenario, the loss of funds.

4.2. Generic Payment APIs with Any Token

Conducting an exchange via a smart contract allows users to pay for any service or product with any crypto token they prefer. The Kuavdin contract provides instant conversion to Ether (or another desired token) and securely completes the payment on behalf of the user to any contract they wish.

The figure below describes how a user could participate in an ICO that accepts only Ether while paying with any other supported token.

The entire process occurs within a single transaction, and Kuavdin never takes possession of the user's tokens (neither the source token A nor the destination token B).

4.3. Trusted On-Chain Source for Rate Quotes

Kuavdin's exchange rates are visible to other smart contracts. This transparency enables the implementation of advanced financial instruments such as swap contracts. The quotes provided by Kuavdin are inherently secure as they reflect the real rates being used for atomic trades between pairs of tokens.

4.4. Mitigating the Risks of Price Fluctuations

Due to the general illiquidity of crypto assets, exchange rates often appear volatile due to irregular demand and supply. This issue is aggravated by the lack of parties willing to warehouse crypto assets. This scarcity of options makes it nearly impossible for crypto asset users to hedge against future requirements.

Kuavdin will address this challenge by introducing derivatives in the forms of forwards and options to provide more alternatives to users.

4.5. Forwards

A forward is a contract whereby parties agree to trade an asset at a later date at a price specified in the present. One common problem as ICOs become mainstream is the need for some users to convert between tokens, such as from Melon to ETH, in preparation for an upcoming ICO. The user could either acquire ETH at the current market rate or commit to a forward contract to negate the risk of price fluctuations in ETH as a viable alternative.

4.6. Options

Options contracts allow users to hedge against adverse price movement for a fee called a premium.

• A call option gives the owner the right to purchase the crypto asset at an agreed price.
• A put option is the opposite, giving the right to sell.

The premium is typically calculated using the implied volatility of the underlying crypto asset. Crypto asset users who need to prepare for a future purchase or sale commitment can pay a premium to buy a call or put option. As an example, holders of idle tokens are able to write call options to earn premiums while forgoing the upside of the price.

5. Road Map

The road map for Kuavdin includes several key phases.

5.1. Phase 0: Testnet Deployment

• Est. Delivery: August 2017
• Goal: Develop a Minimum Viable Product (MVP) version of our platform, including the Kuavdin wallet, the main Kuavdin contract, and our reserve dashboard. This phase focuses on creating a basic, functional version of Kuavdin with all the main functionalities and applications.
• The MVP will be publicly released, and the related contracts will be deployed and tested on the Ethereum testnet.

5.2. Phase 1: Basic Mainnet Deployment

• Est. Delivery: Q1 2026
• Goal: Deploy the first version of Kuavdin on the mainnet. We will begin by supporting trades and proxy payments between any token to and from Ether. Initially, our reserve will likely be the primary one serving all trades, although we plan to partner with major token holders and market makers to introduce their reserves into Kuavdin.
• The tokens supported will be popular ones with high demand and trading volumes.
• We will also partner with wallet providers like MyEtherWallet, Status, Jaxx, and others to implement Kuavdin's core features. Since most users prefer their existing wallets, integrating our features directly is the best way to increase Kuavdin's adoption.

5.3. Phase 2: Supporting Arbitrary Pairs of Tokens

• Est. Delivery: Q2 2026
• Goal: This phase can be easily achieved following the smooth implementation of Phase 1. By then, we expect more reserves (market makers) to join Kuavdin, increasing the number of supported tokens.
• Kuavdin will also work with strategic partners to build APIs that allow users on their platforms to efficiently withdraw tokens or shared fees in preferred tokens. For example, platforms employing fee-sharing models (where token holders share platform fees spread across many tokens) can use our APIs to allow token holders to seamlessly receive their shared fees in ETH or another preferred token via Kuavdin.

5.4. Phase 3: Trading Advanced Financial Instruments

• Est. Delivery: Q4 2026
• Goal: Once our development and operations stabilize, we will deploy Phase 3 of Kuavdin, supporting the trading of advanced financial instruments as discussed in Section 4.
• We plan to work with decentralized hedge fund platforms (e.g., provided by Melonport) that allow people to invest in trustless hedge funds and earn profit shares from efficient fund management. Our team will need to discuss, exchange, and build secure APIs between the related platforms to enable these functionalities. Similarly, collaborations with ICO projects that have vesting schemes for their founders and advisors are also important.

5.5. Phase 4: Support Cross-Chain Trades

• Est. Delivery: End 2026/Early 2027
• Goal: The deployment in this phase allows users to trade between Ether/tokens and other major cryptocurrencies like Bitcoin, ZCash, ETC, and so on.
• There are two primary ways to achieve this: using chain relays (e.g., BTCRelay and ZecRelay) or using interchain communication protocols (e.g., Cosmos, Polkadot). We will closely monitor the development of these protocols and relays to decide which solution Kuavdin will employ.

6. Crowdsale and the KDN Token

A fixed number of Kuavdin tokens (KDN) will be distributed to the public in exchange for Ether contributions. The details regarding the number of KDN distributed and how the sale is conducted will be publicly available on our blog posts and website.

6.1. Use of Tokens

KDN tokens are required for reserves to participate in the network, granting them the right to operate and earn profits from trading activities in Kuavdin.

• Token Burning Mechanism: The KDN tokens collected from the fees, after paying for operation expenses and supporting partners, will be burned (taken out of circulation). The burning of tokens could potentially increase the appreciation of the remaining KDN tokens as the total supply in circulation is permanently reduced.
• Fee Calculation: To determine the network fees, the conversion rate between KDN and ETH will be updated frequently to the Kuavdin contract by KDN operators, based on trading rates on various exchanges.
• Example: For a trade volume of 10 ETH with a 0.01% fee, a corresponding 0.001 ETH worth of KDN will be paid by the chosen reserve to Kuavdin as a fee for using the reserve dashboard and accessing network users. Suppose the rate of KDN at the trading time is 1 KDN for 0.1 ETH, the reserve needs to pay 0.01 KDN to the Kuavdin platform.
  • The wallet/website that helped the user initiate the trade will get, supposedly, 5% of the fees, or 0.0005 KDN.
  • The remaining 95% of the fees, or 0.0095 KDN, will be burned forever.

This approach would increase the demand for existing KDN tokens as the trading volume on Kuavdin increases. The mechanism also properly rewards all participants who help grow the ecosystem. KDN token holders can easily track the total supply by reading from the contract, without relying on any off-chain accounting firm.