Bitcoin has a number of admirable qualities:
- Deep liquidity
- High security budget
- Completely decentralized
- Fixed money supply
- Durable—Bitcoin has survived and thrived in the last 15 years
For all these reasons, Bitcoin should be the base layer for Web3. But it isn’t.
Because of the lack of smart contracts on the Bitcoin blockchain, Bitcoin has been used purely as a store of value, while its integration into finance—as a money, currency, and capital asset—has lagged.
That’s now changing with Bitcoin layers, which enable devs to build DeFi in the Bitcoin ecosystem. So if you are a developer building on Bitcoin, what do you need to know about DeFi to build your own applications?
We covered the DeFi 101 basics previously, but here we’re going to go deeper into decentralized exchanges. Decentralized exchanges (DEXs) have become the hallmark of DeFi due to their ability to provide users with trustless, permissionless, and non-custodial trading, and we’ll cover two mechanisms that enable them to work: liquidity pools and automated market makers (AMMs).
What Is a Liquidity Pool?
At the heart of DeFi is the DEX, and at the heart of the DEX is a liquidity pool. A liquidity pool is a set of two or more cryptocurrencies locked into a smart contract. When a user trades one asset for another using a DEX, it’s the liquidity pool underneath that provides the user the new token they swap for.
Liquidity refers to the ease and speed with which you can turn one asset into another. When liquidity is high, it benefits traders. For example, the depth of a pool (its total value) determines how well it can handle "price slippage" during individual trades. Price slippage is the difference between the expected trade price and the actual execution price. An "illiquid" pool, one with a low total value, struggles to accommodate large trades without depleting its assets at the quoted price. This leads to less efficient and costlier transactions.
Liquidity Providers (LPs) add assets to a pool and receive an LP token, which are claims of ownership on the value in that pool and can be redeemed for assets in the pool at a later date.
Each pool contains two or more tokens that you can trade (e.g. a BTC/ETH pool that lets you trade BTC for ETH and vice versa). The relative balance of assets in a pool dictates the price of each. As a general rule, when an asset is swapped for another, the balance shifts, and the price of each asset changes.
Let's say you have a liquidity pool of Bitcoin/Ethereum. There are 50 BTC and 50 ETH in the pool. For simplicity's sake, let's say 1 BTC = 1 ETH. Let’s also say there are 50 liquidity providers in the pool, who each contributed 1 BTC and 1 ETH to the pool.
Users can use the pool to swap BTC for ETH, but that changes the ratio of assets in the pool. For example, User A swaps ETH for BTC. To do that, they add 1 ETH to the pool and withdraw 1 BTC, paying a transaction fee in the process. Now the pool balance is 49 BTC and 51 ETH. This now makes it more expensive to buy BTC and cheaper to buy ETH. With each trade, the price shifts.
Liquidity pools are powered by automated market makers (AMMs) that are essentially mathematical formulas that dictate the trading prices of assets in the pool. One of the most common formulas used to determine pricing is the constant product formula, represented as x.y = k, where x and y are the quantities of the two assets in the pool, and k is a constant. As transactions occur and the quantities of assets change, the formula adjusts the price to maintain the constant k, ensuring that the product of the quantities remains the same.
These formulas are expressed in smart contracts. You can see how Arkadiko, a DeFi app on Stacks, implements the constant product formula in their code here. This is a powerful consequence of decentralized exchanges built on blockchains–you can see the code that is determining how value is assigned.
Here are some important concepts to keep in mind when it comes to liquidity pools:
- Incentives: Users provide funds to liquidity pools with the promise of earning interest on their deposited assets. That interest comes in the form of trading fees paid by users swapping assets through the pool. Additionally, many protocols incentivize liquidity provision with additional token rewards, enhancing the overall yield.
- Liquidity Bootstrapping: For a new pool, attracting initial liquidity can be a challenge. Strategies like offering higher rewards in a pool's early days or creating innovative tokenomics can bootstrap liquidity, ensuring a pool's functionality and attractiveness.
- Impermanent Loss: Impermanent loss is when a token's price change causes your share in a liquidity pool to be worth less than the original value of your deposit. As the prices of assets in the pool diverge, liquidity providers can face a situation where their holdings in the pool are worth less than if they had just held the assets separately. Effectively, they lose money by providing liquidity. As the name suggests, this can be impermanent, if the prices converge again, but understanding and mitigating this risk is vital.
- Slippage: This is the difference between a quoted price and the actual executed price of a trade. It primarily occurs due to market volatility and thin liquidity. For users it means that the trade might be executed at a different price than anticipated. In decentralized exchanges and liquidity pools, significant slippage can arise when large trades are made in liquidity pools with limited funds.
- Security Concerns: As smart contracts govern liquidity pools, they must be watertight against potential exploits. Economic attacks, like arbitrage opportunities birthed from manipulating a pool's balance, can also lead to substantial losses.
- Liquidity Migration: Liquidity, unlike traditional finance, is highly portable in DeFi. If a more attractive opportunity arises, liquidity providers can swiftly shift their capital. Developers must be aware of this fluidity and continuously ensure their pool's competitiveness, either with a superior user experience or through innovating lower—but yet still sustainable—fees.
Order Books vs Automated Market Makers
Traditional centralized exchanges use an order book model where buy and sell orders are matched based on price and volume. Some DEXs employ a similar mechanism. Order books allow buyers and sellers to advertise their demand/supply at a specified price, and guarantee that, if their bid/ask is met, it will be met at 100% of the price quoted with no slippage.
However, centralized order books do not guarantee fulfillment of bid/ask. Only that there will be no price slippage if fulfilled. There are a few drawbacks to these centralized order books.
The principal challenge when creating an order book exchange on a blockchain is that fulfilling a buy or sell order can involve interacting with multiple orders in the book if there isn't a precisely equal sell (in price and quantity) for every buy.
This can lead to multiple transactions to fulfill orders, and an increase in transactional complexity. Add the computational and data storage overhead of maintaining every buy/sell order in an order book in a smart contract, and you have an expensive model for an exchange that, by design, imposes higher fees on users than an AMM.
That’s why AMMs have become the most popular model for decentralized exchanges, where blockchains impose costs on transactional complexity, and why virtually all liquidity in DeFi is traded in that manner. There’s no need to comb through order books looking for precise matches for buys and sells.
This means that the smart contract logic can be simpler and requires less computation, which means lower fees for traders, and increased adoption for the pool.
Because AMM liquidity pools are decentralized, we can see how they are implemented. For example, here is the source code for one of ALEX’s pools, a DeFi app on Stacks.
Exploring DEXs on Bitcoin
The great thing about DEXs is that they are decentralized, so you can explore and analyze their code to understand more about their inner workings. On the surface, they are simple, but as is true with so many things, the devil’s in the details.
Ready to start building?