Liquidity providers, or LPs, are not a homogenous group:
- Passive LPs are token holders who wish to passively invest their assets to accumulate trading fees.
- Professional LPs are focused on market making as their primary strategy. They usually develop custom tools and ways of tracking their liquidity positions across different DeFi projects.
- Token projects sometimes choose to become LPs to create a liquid marketplace for their token. This allows tokens to be bought and sold more easily, and unlocks interoperability with other DeFi projects through Capricorn.
- Finally, some DeFi pioneers are exploring complex liquidity provision interactions like incentivized liquidity, liquidity as collateral, and other experimental strategies. Capricorn is the perfect protocol for projects to experiment with these kinds of ideas.
There are a several categories of traders in the protocol ecosystem:
- Speculators use a variety of community built tools and products to swap tokens using liquidity pulled from the Capricorn protocol.
- Arbitrage bots seek profits by comparing prices across different platforms to find an edge. (Though it might seem extractive, these bots actually help equalize prices across broader cube markets and keep things fair.)
- DAPP users buy tokens on Capricorn for use in other applications on cube.
- Smart contracts that execute trades on the protocol by implementing swap functionality (from products like DEX aggregators to custom Solidity scripts).
In all cases, trades are subject to the same flat fee for trading on the protocol. Each is important for increasing the accuracy of prices and incentivizing liquidity.
There are far too many ways Capricorn is used in the wider cube ecosystem to count, but some examples include:
- The open-source, accessible nature of Capricorn means there are countless UX experiments and front-ends built to offer access to Capricorn functionality. You can find Capricorn functions in most of the major DeFi dashboard projects. There are also many Capricorn -specific tools built by the community.
- Wallets often integrate swapping and liquidity provision functionality as a core offering of their product.
- DEX (decentralized exchange) aggregators pull liquidity from many liquidity protocols to offer traders the best prices by splitting their trades. Capricorn is the biggest single decentralized liquidity source for these projects.
- Smart contract developers use the suite of functions available to invent new DeFi tools and other various experimental ideas.
The Capricorn team along with the broader Capricorn community drives development of the protocol and ecosystem.
- Smart contracts
Capricorn is a binary smart contract system. Core contracts provide fundamental safety guarantees for all parties interacting with Capricorn . Periphery contracts interact with one or more core contracts but are not themselves part of the core.
The core consists of a singleton factory and many pairs, which the factory is responsible for creating and indexing. These contracts are quite minimal, even brutalist. The simple rationale for this is that contracts with a smaller surface area are easier to reason about, less bug-prone, and more functionally elegant. Perhaps the biggest upside of this design is that many desired properties of the system can be asserted directly in the code, leaving little room for error. One downside, however, is that core contracts are somewhat user-unfriendly. In fact, interacting directly with these contracts is not recommended for most use cases. Instead, a periphery contract should be used.
The factory holds the generic bytecode responsible for powering pairs. Its primary job is to create one and only one smart contract per unique token pair. It also contains logic to turn on the protocol charge.
Pairs have two primary purposes: serving as automated market makers and keeping track of pool token balances. They also expose data which can be used to build decentralized price oracles.
The periphery is a constellation of smart contracts designed to support domain-specific interactions with the core. Because of Capricorn 's permissionless nature, the contracts described below have no special privileges, and are in fact only a small subset of the universe of possible periphery-like contracts. However, they are useful examples of how to safely and efficiently interact with Capricorn.
The library provides a variety of convenience functions for fetching data and pricing.
The router, which uses the library, fully supports all the basic requirements of a front-end offering trading and liquidity management functionality. Notably, it natively supports multi-pair trades (e.g. x to y to z), treats CUBE as a first-class citizen, and offers meta-transactions for removing liquidity.
The following sections describe some of the notable design decisions made in Capricorn. These are safe to skip unless you're interested in gaining a deep technical understanding of how works under the hood, or writing smart contract integrations!
Typically, smart contracts which need tokens to perform some functionality require would-be interactors to first make an approval on the token contract, then call a function that in turn calls transferFrom on the token contract. This is not how pairs accept tokens. Instead, pairs check their token balances at the end of every interaction. Then, at the beginning of the next interaction, current balances are differenced against the stored values to determine the amount of tokens that were sent by the current interactor. See the whitepaper for a justification of why this is the case, but the takeaway is that tokens must be transferred to the pair before calling any token-requiring method (the one exception to this rule is Flash Swaps.
Unlike Capricorn pools, pairs do not support CUBE directly, so CUBE⇄CRC-20 pairs must be emulated with WCUBE. The motivation behind this choice was to remove CUBE-specific code in the core, resulting in a leaner codebase. End users can be kept fully ignorant of this implementation detail, however, by simply wrapping/unwrapping CUBE in the periphery.
The router fully supports interacting with any WCUBE pair via CUBE.
To ameliorate rounding errors and increase the theoretical minimum tick size for liquidity provision, pairs burn the first MINIMUM_LIQUIDITY pool tokens. For the vast majority of pairs, this will represent a trivial value. The burning happens automatically during the first liquidity provision, after which point the totalSupply is forevermore bounded.
An automated market maker is a smart contract on Cube that holds on-chain liquidity reserves. Users can trade against these reserves at prices set by an automated market making formula.
The automated market making algorithm used by Capricorn. See x*y=k.
CRC20 tokens are fungible tokens on Cube. Capricorn supports all standard CRC20 implementations.
A smart contract that deploys a unique smart contract for any CRC20/CRC20 trading pair.
A smart contract deployed from the Capricorn Factory that enables trading between two CRC20 tokens.
Liquidity within a pair is pooled across all liquidity providers.
A liquidity provider is someone who deposits an equivalent value of two CRC20 tokens into the liquidity pool within a pair. Liquidity providers take on price risk and are compensated with fees.
The price between what users can buy and sell tokens at a given moment. In Capricorn this is the ratio of the two CRC20 token reserves.
The difference between the mid-price and the execution price of a trade.
The amount the price moves in a trading pair between when a transaction is submitted and when it is executed.
Smart contracts that are essential for Capricorn to exist. Upgrading to a new version of core would require a liquidity migration.
External smart contracts that are useful, but not required for Capricorn to exist. New periphery contracts can always be deployed without migrating liquidity.
A trade that uses the tokens being purchased before paying for them.
x * y = k
The constant product formula.
The "k" value in the constant product formula