QuickSwap is a permissionless decentralized exchange (DEX) based on Ethereum, powered by Matic Networks Layer 2 scalability infrastructure. By utilizing Layer 2 for transactions,
Quickswap is an automated liquidity protocol powered by a constant product formula and implemented in a system of non-upgradeable smart contracts on the Ethereum blockchain. It obviates the need for trusted intermediaries, prioritizing decentralization, censorship resistance, and security. Quickswap is open-source software licensed under the GPL.
Each Quickswap smart contract, or pair, manages a liquidity pool made up of reserves of two ERC-20 tokens.
Anyone can become a liquidity provider (LP) for a pool by depositing an equivalent value of each underlying token in return for pool tokens. These tokens track pro-rata LP shares of the total reserves, and can be redeemed for the underlying assets at any time.
Pairs act as automated market makers, standing ready to accept one token for the other as long as the “constant product” formula is preserved. This formula, most simply expressed as
x * y = k, states that trades must not change the product (
k) of a pair’s reserve balances (
kremains unchanged from the reference frame of a trade, it is often referred to as the invariant. This formula has the desirable property that larger trades (relative to reserves) execute at exponentially worse rates than smaller ones.
In practice, Quickswap applies a 0.30% fee to trades, which is added to reserves. As a result, each trade actually increases
k. This functions as a payout to LPs, which is realized when they burn their pool tokens to withdraw their portion of total reserves. In the future, this fee may be reduced to 0.25%, with the remaining 0.05% withheld as a protocol-wide charge.
Because the relative price of the two pair assets can only be changed through trading, divergences between the Quickswap price and external prices create arbitrage opportunities. This mechanism ensures that Quickswap prices always trend toward the market-clearing price.
Ultimately, of course, the Quickswap protocol is just smart contract code running on Ethereum. To understand how they work, head over to Smart Contracts
The Quickswap ecosystem is primarily comprised of three types of users: liquidity providers, traders, and developers. Liquidity providers are incentivized to contribute ERC-20 tokens to common liquidity pools. Traders can swap these tokens for one another for a fixed 0.30% fee (which goes to liquidity providers). Developers can integrate directly with Quickswap smart contracts to power new and exciting interactions with tokens, trading interfaces, retail experiences, and more.
In total, interactions between these classes create a positive feedback loop, fueling digital economies by defining a common language through which tokens can be pooled, traded and used.
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 Quickswap.
- Finally, some DeFi pioneers are exploring complex liquidity provision interactions like incentivized liquidity, liquidity as collateral, and other experimental strategies. Quickswap 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 Quickswap 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 Ethereum markets and keep things fair.)
- DAPP users buy tokens on Quickswap for use in other applications on Ethereum.
- 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 Quickswap is used in the wider Polygon ecosystem to count, but some examples include:
- The open-source, accessible nature of Quickswap means there are countless UX experiments and front-ends built to offer access to Quickswap functionality. You can find Quickswap functions in most of the major DeFi dashboard projects. There are also many Uniswap-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 but splitting their trades. Quickswap is the biggest single decentralized liquidity source for these projects.
The Quickswap team along with the broader Quickswap community drives development of the protocol and ecosystem.
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 Quickswap'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 Quickswap V2.
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 ETH as a first-class citizen, and offers meta-transactions for removing liquidity.
The following sections describe some of the notable design decisions made in Quickswap V2. These are safe to skip unless you're interested in gaining a deep technical understanding of how V2 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 V2 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.
Matic⇄ERC-20 pairs must be emulated with WMATIC. The motivation behind this choice was to remove Matic-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 Matic in the periphery.
The router fully supports interacting with any WETH pair via ETH.
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.