Pools

Introduction

Each Casperswap liquidity pool is a trading venue for a pair of CEP-18 tokens.

When a pool contract is created, the balance of each token is 0; in order for the pool to begin facilitating trades, someone must seed it with an initial deposit of each token.

This first liquidity provider is the one who sets the initial price for the pool. They are incentivized to deposit an equal value of both tokens into the pool. To understand this dynamic, consider the case in which the first liquidity provider deposits tokens at a ratio different from the current market rate: this immediately creates a profitable arbitrage opportunity that is likely to be taken by an external party.

When other liquidity providers add to an existing pool, they must deposit pair tokens proportional to the current price. Failing to do so puts the liquidity they added at risk of being arbitraged as well. If they believe the current price is incorrect, they may arbitrage it to the level they desire, and add liquidity at that price.

Pool tokens

Whenever liquidity is deposited into a pool, unique tokens known as liquidity tokens are minted and sent to the provider's address. These tokens represent a given liquidity provider's contribution to a pool.

The proportion of the pool's liquidity provided determines the number of liquidity tokens the provider receives. If the provider is minting a new pool, the number of liquidity tokens they will receive will equal sqrt(x * y), where x and y represent the amount of each token provided.

Whenever a trade occurs, a 0.3% fee is charged to the transaction sender. This fee is distributed pro-rata to all LPs in the pool upon completion of the trade.

To retrieve the underlying liquidity, plus any fees accrued, liquidity providers must "burn" their liquidity tokens, effectively exchanging them for their portion of the liquidity pool, plus the proportional fee allocation.

As liquidity tokens are themselves tradable assets, liquidity providers may sell, transfer, or otherwise use their liquidity tokens in any way they see fit.

Why pools?

Casperswap is unique in that it does not use an order book to derive the price of an asset or to match buyers and sellers of tokens. Instead, it uses liquidity pools.

Liquidity is typically represented by discrete orders placed by individuals on a centrally operated order book. A participant looking to provide liquidity or make markets has to actively manage their orders, continuously updating them in response to the activity of others in the marketplace.

While order books are foundational to finance and work great for certain use cases, they suffer from a few important limitations that are especially magnified when applied to a decentralized or blockchain-native setting.

Order books require intermediary infrastructure to host the order book and match orders. This creates points of control and adds additional layers of complexity.

They also require active participation and management from market makers who usually use sophisticated infrastructure and algorithms, limiting participation to advanced traders.

Order books were invented in a world with relatively few assets being traded, so it is not surprising they aren't ideal for an ecosystem where anyone can create their own token, and those tokens usually have low liquidity.

In sum, with the infrastructural trade-offs presented by a platform, order books are not the optimal architecture for implementing a liquidity protocol on a blockchain.

A blockchain-native liquidity protocol should take advantage of the trusted code execution environment, the autonomous and perpetually running virtual machine, and an open, permissionless and inclusive access model that results in an exponentially growing ecosystem of virtual assets.

It is important to stress that a pool is just a smart contract, operated by users calling functions on it. Swapping tokens translates into calling a swap function on a pool contract, whereas providing liquidity translates into calling a deposit function.

Just like end-users can interact with the Casperswap protocol through its interface (which in turn interacts with the underlying contracts), developers can interact directly with the smart contracts and integrate Casperswap functionality into their own applications without relying on intermediaries or needing permission.