πŸ”Spot SWAP

We are currently in development of Spot Swap dApp. Derivatives and Pool Lending functionality will be built on top of Spot Swap smart contracts. This is the reason why we are starting with Automated Market Maker. It is extremely important to get this part right, as batching and fund pooling (global state) architecture and functionality will serve as a base building block for our future products, including Derivatives and Lending pools.

Spot Swap consists of 4 smart contracts/minting policies:

  1. Batch contract. Used in order to fairly aggregate UTXOs to perform a global state transition via Pool smart contract, in order to avoid congestion and race conditions.

  2. Pool smart contract. Used for maintaining pools as separate UTXOs with Datums. exposes pool create, swap, add liquidity, remove liquidity redeemers, implements business logic. In the vast majority of cases, it is accessible only by batch smart contract.

  3. Factory minting policy. Ensures that each pool has a unique identifier NFT. Used for validation and identification.

  4. LP minting policy. Manages minting and burning of liquidity provider tokens, enforces business logic in those cases.

Smart contracts expose these endpoints (redeemers):

  1. Create pool. Exposed directly by Pool smart contract, as congestion is not an issue in this case. Allows the creation of a new UTXO with Datum, which represents a Pool state. Expects both base and quote tokens as an initial deposit to pool. Mints Factory identity NFT and stores it at Pool UTXO. Mints and sends LP tokens to the user.

  2. Swap. Exposed by batch contract, which acts as an aggregating proxy to a Pool smart contract. UTXO is stored at batch contract, until it is applied with other UTXOs to Pool smart contract. Datum defines all of the rules for the swap, owner, as well as the action itself. On execution, base token amount is deposited to Pool UTXO, and quote token amount is returned to the user, based on Constant Product formula.

  3. Add liquidity. Exposed by batch contract, which acts as an aggregating proxy to a Pool smart contract. UTXO is stored at batch contract, until it is applied with other UTXOs to Pool smart contract. Datum defines all of the rules for adding the liquidity, owner, as well as the action itself. On execution, both base and quote token amounts are deposited to Pool UTXO, pool UTXO state changes and the user receives newly minted, pool specific LP token amount based on Constant Product formula.

  4. Remove liquidity. Exposed by batch contract, which acts as an aggregating proxy to a Pool smart contract. UTXO is stored at batch contract, until it is applied with other UTXOs to Pool smart contract. Datum defines all of the rules for removing the liquidity, owner, as well as the action itself. On execution, sent LP tokens are burned, Pool state UTXO changes, and the user receives base and quote tokens from Pool UTXO, based on Constant Product formula.

  5. Close pool. Exposed directly by Pool smart contract, as congestion is not an issue in this case. Allows the full consumption of an existing Pool UTXO if conditions apply (user has all of the LP tokens in circulation for this specific pool). Burns Factory NFT, LP tokens, returns all of the UTXO token amounts (base and quote) to the user.

  6. Cancel action. If action (swap, add liquidity, remove liquidity) UTXO is present in the batch smart contract (not yet applied to Pool smart contract), allows to consume the UTXO and return tokens (be it base, quote or LP tokens) back to the user, based of ownership address stored in the Datum.

Batching

Our number one priority is to get the batching (UTXO aggregation) part right, as it is the only possibly centralized part in the whole solution. We cannot eliminate it because of the eUTXO model architecture, but we can make it decentralized. Our main concerns and solutions to them are:

  • Extracting value by ordering. If there is no validation enforced on the order of the UTXOs, by manipulating it, malicious agents can break built-in fearness enforced by smart contracts, and execute actions in the order which is beneficial to them. Our solution is to enforce first in first out principle at the batch contract level.

  • Artificial congestion. Malicious agents can batch the minimum possible UTXOs per block, this way eliminating the purpose of aggregation in the first place, and making the product virtually unusable. Our solution is to enforce maximum possible transaction execution/memory units for each transaction involving batching on a batch contract level.

  • Selecting specific parties to perform batching. This removes the decentralization, as now the power is in those party hands. They can stop executing batching transactions and bring the whole product to a halt. Our solution is to introduce an agent-agnostic batch smart contract, which can be executed by anyone, as validator script enforces fairness and designed execution.

This is by far not the only concerns we are facing and we will be communicating more on those issues in the near future.

Future improvements

Apart from realizing the Spot Swap itself, we are constantly doing R&D on possible improvements:

  • Oracle outputs. As a side effect of an Automated Market Maker is price discovery, it makes sense to expose the price as an output in the Spot Swap smart contract, which can later on be consumed as reference input by other smart contracts. This would eliminate a need for outside world data collection via oracles, as price can be determined and accessed within the blockchain itself. We are working on implementing and streamlining this approach.

Last updated