kopi.money
  • Welcome
  • Introduction
    • The Kopi Money Market
    • What is a crypto wallet
    • What is a DEX?
    • Strategies to maximize earnings
    • Tokenomics
  • Using Kopi
    • Connect your wallet
  • How to trade
  • How to place orders
  • Using arbitrage
  • Working with automations
  • Essentials
    • Trade execution
    • kCoins
    • Lending
    • Borrowing
    • Fees & Protocol Income
    • Interest rates
    • Liquidations
    • Adding new tokens to the DEX
  • Tokenfactory
    • Factory tokens
    • Liquidity pool
    • Vesting
    • Offers
  • Technical details
    • Constant product
    • Prices
  • Liquidity
  • Epochs
  • Running a node
  • Transaction fees
Powered by GitBook
On this page
  • Prerequisit checks
  • Two-Step trades
  • Using liquidity
  • Buying vs selling
  1. Essentials

Trade execution

Users select a trading pair and specify an amount when initiating a trade. They may opt for additional settings before signing and submitting the transaction to the blockchain. Shortly after that, they receive their exchanged funds. While this process appears straightforward, it involves several complex mechanisms behind the scenes.

Prerequisit checks

This example outlines the execution of a trade where a user intends to purchase kUSD by selling 100 USDC.

Initially, several critical verifications are conducted. For instance, whether the user possesses sufficient funds for the trade is confirmed. If a user aims to sell 100 USDC but only has 80 USDC available, an error message is generated, preventing the trade's execution. Subsequently, the trade's maximum price is evaluated. This involves calculating the expected return in another currency based on the given amount, thereby determining a transaction price. This calculation ensures that trades adhere to predetermined price ceilings or specified slippage percentages. Suppose the calculation suggests executing the trade at the user's specified amount would exceed the maximum allowed price. In that case, an error is returned, or adjustments are made according to the user's preferences regarding incomplete trades.

The platform also assesses whether adequate liquidity exists for the transaction. For example, if a user expects 100 kUSDC in exchange for 100 USDC but only 50 kUSDC is in the liquidity pool, the system checks if the user permits adjustments to the trade amount. Depending on the user's settings, the trade may be adjusted or cancelled if insufficient liquidity prevents the transaction from meeting the original terms.

Two-Step trades

Each trade is executed in two phases following the preliminary checks.

The first phase swaps the funds the user is giving into the liquidity pool to XKP. For example, when the user is selling USDC to buy kUSD, USDC is swapped to XKP. The function responsible to execute this swap receives the amount of USDC and returns the received amount of XKP. In the case where XKP is sold, that function returns the same amount it receives since nothing has to be swapped.

The second phase swaps XKP to the currency the user wants to buy. The same function is used again. In case where the user is buying XKP, no action needs to be taken.

Using liquidity

Funds added to the DEX as liquidity are stored in lists for each currency. Each list entry contains the wallet address that provided that liquidity, making each deposit tracable. When a user adds 10 kUSD and another adds 100 kUSD, those two entries are stored in the order in which they have been added.

Liquidity positions are used from oldest to newest. In the example where 100 kUSD are bought, first the 10 kUSD from the first liquidity position are used, then 90 kUSD from the second position. However: to prevent self-trading, liquidity positions belonging to the same address as the wallet executing the trade are skipped. An exception to this rule are trades executed by the protocol itself: Only the protocol is allowed to buy liquidity provided by itself.

In the described example, there are two used position, one provided 10% and the other 90% of the used liquidity. The funds that are given into the pool are distributed using those shares and are added as new liquidity entries into the list of liquidity entries of that other currency, in the example it's USDC. For each new entry, an event tracking those liquidity swap is emitted. That way, liquidity providers can track how their liquidity has been swapped over time.

Buying vs selling

For each trade users select two currencies: The first currency is for which users have to give funds into the liquidity pool, the second one is the currency in which they receive funds in return. In the user interface, users can either set an amount they want to give (ie sell), in which case they can an estimate they will receive from the pool. When users set the amount they want to receive (ie buy), they see an estimate how much they have to give into the pool.

The steps executed when buying or selling are basically the same. The main difference is how the fee is calculated: When trading selling USCD to buy kUSD, the fee is taken from the kUSD received, so when 100 USDC are sold and the trade fee is 0.1%, the user receives 99.99 kUSD. When the user is buying 100 kUSD, it means the user is selling USDC. In order to receive 100 kUSD, 100.1 kUSD have to be bought to cover the trade fee, thus 100.1 USDC has to be given into the pool (assumes flat prices for simplicity).

PreviousWorking with automationsNextkCoins

Last updated 2 months ago