Comment on page
No 👙 required.
For any sort of trading to happen, buyers and sellers have to converge on the price of an asset or contract.
However, this requires a first mover (i.e. the maker) to place his trade intent (e.g. by placing an order on the orderbook). Other traders can then review this quote and either accept it by taking the order (i.e. the taker), or place a counter quote at a different price (thereby becoming a maker on the order side of the book). When this happens iteratively, a liquid order book is eventually formed, and the marketplace has now converged on a good indicative "fair" price for future takers.
As you might imagine, this requires multiple parties willing to wait for some indeterminate period of time for the trade to occur. In some markets or venues, there may simply not be sufficient traders or liquidity for that to ever happen.
A traditional market maker solves this problem by committing to always be active in a certain market to act as buy or sell quotes for other takers. Centralized cryptocurrency exchanges (CEXs) also partner with market-makers to provide this liquidity.
In general, market makers are incentivized to do so by profiting off the difference between their quoted bid and ask prices (i.e. the spread). To perform this service though, market makers need sophisticated knowledge of trading, require programming resources, among other things.
In a decentralized exchange (DEX) like Demex, there is a further innovation on the concept of market makers that makes the game fair and permissionless!
In DEXs like Demex, any user can in fact become a market maker by simply providing liquidity.
For spot markets, users may provide the two tokens belonging to both side of a spot market to a common pool (known as a "liquidity pool"). This combined liquidity is then managed by an automated market maker (or "AMM"). The AMM typically acts in a path independent way such that it is resistant to manipulation, and will not lose money except for a transient change in market prices.
For perp markets, users provide stablecoins to a common pool (known as a "perp pool"). This liquidity is then managed by an AMM which regularly quotes bids and asks near the oracle price based on the configuration of the perp pool in a way that is resistant to manipulation.
Users deposit their assets into a common pool which is then managed by the Carbon AMM module. In return, they obtain liquidity pool tokens (
clpts) in proportion to the value of assets deposited. These tokens can be understood as a "receipt" to the assets that they have deposited in the pool.