Komodo DeFi Framework and Atomic Swaps

Introduction

Komodo DeFi Framework implements a revolutionary decentralized exchange protocol that enables trustless cryptocurrency trading without counterparty risk. The protocol is open source and supports trading for any cryptocurrency that developers choose to connect.

Our service fully realizes decentralized order matching and trade clearing. The order-matching aspect relies on a peer-to-peer network to build public orderbooks, and trade clearing is executed through an atomic cross-chain protocol, also called an "atomic swap."

Current Problems in Cryptocurrency Trading

Centralized Exchanges: The Status Quo

The current, most practical method for cryptocurrency exchange requires the use of centralized exchange services. These centralized solutions require vouchers to perform the exchange, wherein the user sends their funds into the care of a centralized entity and receives "I Owe You" (IOU) statements in return. The user then trades these IOUs within a controlled environment and, when finished, returns their IOUs to the centralized entity for reimbursement.

The Limitations of Traditional DEXs

A decentralized exchange (DEX) allows users to trade funds within an environment that is at least partially decentralized. However, most DEX solutions still require users to surrender control of their assets during the trading process, either to a centralized entity or a distributed group of authority figures. In AMM DEXs, there are issues with slippage and impermanent loss.

Komodo DeFi Framework — A Complete Solution

We now present a fully functional, new decentralized technology that makes a competitive decentralized exchange possible. The Komodo DeFi Framework includes:

1. Decentralized Order Matching

   • Peer-to-peer network
   • Public orderbooks
   • No central authority

2. Atomic Cross-Chain Trading

   • Direct coin-to-coin/token trading using atomic swaps
   • No intermediary custody
   • Full user control

3. Public Reputation System (upcoming)

   • Public trading profiles/addresses
   • Behavior-based reputation
   • Optional trust API

The Decentralized Orderbook

The first component of Komodo DeFi Framework is Order Matching. This is the process of pairing a user's offer to buy with another user's offer to sell. The data of these offers form an orderbook.

Multi-Coin Wallet

Komodo DeFi Framework features a wallet that can manage and trade among multiple different blockchain coins using a single passphrase. This allows a user to trade on multiple chains/protocols with a single wallet.

Atomic Swaps

For trade clearing, Komodo DeFi Framework implements our own unique variation of atomic swaps.

An atomic swap is a technology that allows two users to trade cryptocurrencies across two separate blockchains without requiring an intermediary third party.

The original concept of an atomic swap was created in 2013 by Tier Nolan and many other Bitcoin enthusiasts on the Bitcointalk.org chat forum. In 2014, this conversation inspired members of the Komodo development team to experiment with atomic swaps, and they have remained a key technology in our strategy ever since.

The Value of the Atomic Swap

To understand why the atomic-swap protocol is necessary, one must first recall that computer code is executed in linear fashion. Even if we were to assume that both parties in a trade may be honest, on a computer the process of taking money from each digital wallet and pulling the money into the open must happen one wallet at a time.

Therefore, one person must release control over their money first. The atomic-swap protocol protects that person from vulnerability. Without the atomic swap, any malicious party involved would be able to destroy the fairness of the trade.

A key aspect of a proper atomic swap is that at each stage of the trade-clearing process, each user has incentives to proceed to the next step in the proper manner and disincentives to avoid abandoning the procedure. With this structure in place, regardless of a failure by either user to complete the protocol, each user receives a proper reward.

Introducing Taker and Maker

There are two parties in an atomic swap: the liquidity provider and the liquidity receiver. We call the provider "Maker" and the receiver "Taker."

Taker Makes a Request

The process of an atomic swap begins with the person who makes the initial request.

Taker will need two transactions to perform her swap. One transaction will cover the protocol fee, which is roughly 1/777th the size of the desired order. We call this fee the <dexfee>, and its primary purpose is to serve as a disincentive to Taker from spamming the network with rapid requests.

The Atomic Swap Process

Assuming Taker and Maker are successfully connected, the process from this point forward becomes quite simple.

1. Taker requests a swap and sends the <dexfee> transaction data to Maker.

2. Maker receives the <dexfee>, verifies it, and sends <makerpayment>

   • Maker generates a "secret", creates a hash of the secret, and shares this hash with Taker

   • Maker does not send the payment to Taker directly, but rather into a temporary holding address

     • On utxo-based blockchains, this holding address is a P2SH hash/time locked output
     • On ETH/ERC20 (EVM) based blockchains, this address is an "etomic-swap" smart contract

   • <makerpayment> enters a state of limbo on the Maker's coin network, held safely by cryptography and blockchain technology, awaiting either for Taker to spend the payment, or for the swap to time out

   • If the latter occurs, <makerpayment> is allowed to be automatically refunded to Maker by the Komodo DeFi Framework protocol

3. Taker now sends <takerpayment>

   • Taker does not send the payment to Maker directly, but rather into a temporary holding address

     • On utxo-based blockchains, this holding address is a P2SH hash/time locked output
     • On ETH/ERC20 (EVM) based blockchains, this address is an "etomic-swap" smart contract

   • <takerpayment> enters a state of limbo on the Taker's coin network, held safely by cryptography and blockchain technology, awaiting either for Maker to spend the payment, or for the swap to time out

   • If the latter occurs, <takerpayment> is allowed to be automatically refunded to Taker by the Komodo DeFi Framework protocol

4. Maker now spends the <takerpayment>

   • To spend the payment Maker reveals the secret

5. Taker now "spends" the <makerpayment>

   • Taker finds that <takerpayment> is spent and extracts the secret from the spending transaction. The secret can be used to unlock the <makerpayment> and send the coins to Taker's address

While it may seem inefficient to have five transactions for a swap that could be done with two, the complexity of this process provides us with the requisite "trustless-ness" to maintain user safety.

Incentives and Disincentives to Maintain Good Behavior

As we will now explain, at every step along the way there are incentives for each side to proceed, and there are various financial protections in place should one side fail.

Also, because payments are sent to these "temporary holding addresses" that exist on the respective blockchains, the protocol itself can assist in the process of moving money at the appropriate steps.

Let us now examine what is happening after each step.

1 - Taker Sends <dexfee>

If Maker accepts the offer to trade, but does not send <makerpayment>, Taker only stands to lose the <dexfee>. This is only 1/777th of the entire transaction amount, so she loses very little.

Maker, on the other hand, stands to lose more. Since Maker did not follow through with his end of the bargain, the Komodo DeFi Framework network indicates on his public Komodo DeFi Framework trading profile that he failed in a commitment, thus decreasing his profile’s reputation. If Maker continues this behavior as a habit, he may find it difficult to discover trading partners.

So long as the frequency of Makers failing is low, the occasional extra <dexfee> paid by a Taker is a minor issue. However, if there is a sudden spike in misbehavior, the Komodo DeFi Framework code has built-in contingency plans which can provide refunds to Takers.

2 - Maker Successfully Sends <makerpayment>

If Taker does not follow with her next step, the <takerpayment>, then Taker loses not only the <dexfee>, but she also receives a mark on her public Komodo DeFi Framework profile. She gains nothing, and Maker has no reason to fear as the <makerpayment> will automatically return to him via the Komodo DeFi Framework protocol.

3 - Taker Successfully Sends <takerpayment>

If Maker does not proceed with his next step (spending the payment), then after lock time expires, Taker's Komodo DeFi Framework protocol will automatically refund the payment.

4 - Maker Spends <takerpayment>

If Taker does not follow by also "spending" the <makerpayment>, it is of no concern to Maker because he has already received his funds. If Taker is simply offline and doesn't spend the <makerpayment>, she can only hurt herself.

Naturally, for Taker this is slightly dangerous. Taker’s best course of action is to remain online and let their Komodo DeFi Framework protocol spend the <makerpayment> once the <takerpayment> is spent and the secret is revealed.

5 - Taker Spends <makerpayment>

The process is complete. Taker received the <makerpayment>. Maker received the <takerpayment>. The entire process only cost Taker the original <dexfee>.

At each step along the way, the side that needs to take the next step is motivated to do so, with greater and greater urgency until the process is complete.

Additional Details

Always Manage Risk Appropriately

Naturally, users must understand that outside forces can disable the process and thereby damage one of the users. For instance, an Internet outage for Taker could be particularly dangerous. Therefore, users are advised only to trade manageable sums that they are willing to put at risk, and only with nodes that have reliable reputations.

The Connection is the True Challenge of an Atomic Swap

Performing a successful connection between Maker and Taker, and verifying their funds, is the most complex and difficult aspect of creating the Komodo DeFi Framework network.

Myriad factors are involved in a successful attempt for Maker and Taker to connect: human motivation; the experience level of the users; economics; connection technology; user hardware setups; normal variations within Internet connections; etc.

We emphasize to users here that the process of performing these actions over a peer-to-peer network has almost an artistic element to it. An attempt to successfully connect Maker and Taker can be thought of more like fishing, where we must simply cast and recast our line until we successfully connect with our target.

If a user attempts a trade and no response returns from the network, the user should slightly adjust the parameters of their offer and try again. As Komodo DeFi Framework continues to iterate and improve, and as the number of users increases, we expect any required effort to lessen for users, the network, and the Komodo DeFi Framework GUI apps.

The DEX Fee

The <dexfee> is calculated as the greater of:

• 0.0001 TAKER COIN
• 1/777th of the order size

This fee serves multiple purposes:

• Prevents network spam
• Maintains network health
• Enables protocol operations

Additional Information

Risk Management

• Trade only amounts you can afford to risk
• Ensure stable internet connection

Network Connection

Because the payments that occur on one blockchain will proceed regardless of the actions on the other blockchain — a confirmation failure on one chain will not stop the other blockchain performing its duties as normal — the Komodo DeFi Framework protocol will automatically observe and adjust as necessary.

Experimental Nature

API Documentation

For detailed technical information about the Komodo DeFi Framework API, please refer to our API documentation.