The advent of Bitcoin, fuelled initially by its promises of individual sovereignty through programmable and uncontrollable money, has led to the proliferation of a relatively new trillion-dollar asset class, whose behaviour and value proposition is mostly incompatible with pre existing market models for other asset classes.
The peculiarity of cryptocurrencies and their derivatives has inspired the creation of new marketplaces and primitives to accommodate them as well as their proposition of individual sovereignty and decentralisation. This is one of the various fronts of cryptography-related and mechanism design research spurned by the overtly-criticised asset class.
In this article i intend to present a review of the last decade of mechanism design for trust-minimised exchanges designed solely for the exchange of crypto tokens- from the days of backroom OTC deals to fully onchain exchanges.
First Generation of Crypto-Native Markets; Offline Coordination
The only available data from this era are the random tweets and comments from twitter and archived forum discussions during that period.
Over-the-counter channels were (arguably still are) the best way to trade very large amounts of tokens with the least market impact possible. It is also the best way to trade assets without an established marketplace.
It was mostly coordinated and carried out amongst acquaintances and friends who were in it for the thrill and the tech (as was recently the case during the rise of ordinals and Bitcoin inscriptions). Thus it was usually either reputation or capital gated, or both. For two parties who don't know each other; in order for there to be a trade, there had to be a middleman who was either very reputable or trusted by both.
This setup led to the creation of "middleman services" where a seller (or buyer) sends out word to their network that they are in need of a counterparty for a trade; these individuals then race to find a counterparty within their own network in order to earn a preset portion of the trade as fees. This incentive structure led to the possibility of there being multiple middlemen for one trade, making it less profitable for the buyer (or seller).
Another alternative trade venue at the time was to be early. Yes, being early has always been necessary, especially when money is on the line. This was achievable in two major ways;
could be by participating in the new altcoins ICO (initial coin offering); in which the trader sent some amount of an existing coin with an established market presence (usually BTC or ETH back then) to a provided address and are then sent the new altcoin. This was hailed as one of the more democratic methods of sourcing startup capital effortlessly from all interested users, regardless of their trade size or reputation. However it fizzled out due to regulatory crackdown (maybe time to run it back? in minceraft of course).
the other means to obtain a new altcoin was to devote resources to it, if possible. Most of the altcoins back in the day were implemented with their dedicated blockchains (which were mostly hard forks of Bitcoin), this meant that a user could run the required software/hardware in order to earn the altcoin.
This development also led to "cloud mining" services, in which users pool their resources together to run the required software/hardware in order to subsidise individual costs. The profits were then split proportionally to users' contributions after the service provider had taken a fee.
These last two alternatives were seen as more problematic than OTC trades, but were also more democratic and trustless.
Second Generation of Crypto-Native Markets; Satoshi's Vision and Bitcoin Markets
You've probably heard tales of the OP_RETURN wars and the rise of bitcoin maximalism, if you haven't, this article is a great starter and a pointer for the currently brewing OP_CAT wars.
Just before Ethereum was live, there were already considerable efforts to build markets for altcoins native to the Bitcoin chain, more recently referred to as "BRC-20s" or BRC-20 compliant tokens. These new altcoins, unlike most previous iterations, didn't have their own blockchains. Instead they were included as extra data in bitcoin transactions using one or a combination of the following:
OP_RETURN outputs
multi‐signature data outputs
fake public key hashes.
These three data fields could be used for arbitrary data storage on Bitcoin, in this case the data being stored was the details of the altcoins being traded amongst other things.
The most successful of the Bitcoin-native altcoin marketplace ventures was Counterparty.
The Counterparty decentralised exchange was basically a reimplementation of Mastercoin, which had launched earlier with less success.
The onchain LOB model Counterparty used allowed users to submit their orders directly to the Bitcoin chain through the application's interface. As stated earlier, the transaction data was directly sent to Bitcoin which verified the validity of a user's spends. However, interpretation and implementation of the data occurred on the DEX.
Counterparty users specified what asset they had to offer, in exchange for a second asset, and at what price they would like the exchange to occur. They were also required to specify the duration (in epochs) within which their submitted orders must be satisfied or their assets returned to them.
The market's matching logic was price-time priority based, i.e; orders were matched on the best prices available at that time based on other open orders, orders with the same price were then processed based on which was submitted first.
Also, the matching logic allowed partial execution/filling; so that matched users' corresponding assets were immediately made available to them at the end of the block in which matching took place, regardless of whether a user's initial order was completely filled or not.
The order flow for orders in which one trade counterparty was offering BTC was different due to the platform's lack of support for bitcoin escrows. While assets involved in trades were generally "locked" and inaccessible to the users until the order is satisfied or until their order expires, bitcoin was not locked. Instead, users who wished to sell their bitcoin in exchange for some asset were charged a fee when they submitted their orders to disincentivise spoofing. When their order is matched, they then make the payment via a BTCpay message, specifying which order they intend to pay for by including the related transaction hashes.
Despite the countermeasures implemented, the DEX reportedly suffered from spoof orders which occasionally resulted in DoS attacks on other genuine orders.
The cost of every action was also a genuine challenge as users had to pay fees for every action they carried out, in fact the fees a user pay when they submit an order scales directly with the duration they want to keep their order open.
Various challenges, especially cultural ones, and being too early and complex in an underexplored niche of a still developing asset class led to the eventual abandonment of Counterparty. However, most of the services provided there, such as betting markets and LOBs, were reimplemented with variations to much more fanfare on Ethereum when it went live.
Third Generation of Crypto Native Markets; Interoperability & its Unintended Consequences, Partially On-chain CLOBs and Financial Alchemy
The third generation of crypto native markets is perhaps the most pivotal, especially in regards to its contribution to research on multiple fronts besides trading of crypto assets.
By this time there were more ongoing research efforts, both formal and informal, into the development of primitives at both the protocol and application levels. These research efforts birthed many of the decentralised finance (DeFi) infrastructure in use today across hundreds of protocols.
Interoperability:-
Interoperability these days is mostly used to refer to bridging and bridges- obtaining a "mirror" of an asset A, native to protocol X, on protocol Y as asset yA. A common example is wBTC on the Ethereum blockchain which is meant to represent the value of BTC on the Bitcoin blockchain, while satisfying Ethereum token properties. But it wasn't always that way.
Interoperability was initially used to refer to the ability to obtain asset A on chain X, from a second agent who accepts asset B on chain Y. So basically you send an asset you want to sell to someone on one chain, and they send you the asset you want to buy on a second chain.
There were various ways to do this but the underlying technology that enabled it is referred to as "hash time locked contracts", or simply, HTLCs.
A HTLC as the name implies is a conditional contract whose validity criteria is either hash-based or time-based or a combination of both. It is implemented as a script/smart contract that pays out either after a predetermined period of time has passed, or after a hash is decrypted.
A simple HTLC for cross-chain swaps would typically contain
the target chain
the recipient's address on the target chain
an expiry period for the HTLC, at the end of which the contract is voided and the involved parties' funds are returned to them
a hashed secret
the asset being traded
The two major methods for cross-chain swaps were-
TierNolan cross-chain atomic swaps: this method was first proposed on the bitcoin forum in 2013 by Tier Nolan. It involved implementing a HTLC on either chain the parties would be transacting on, i.e; assuming Alice was trading BTC for ETH with Brian, they would both need to implement a HTLC on BTC and ETH respectively, and they both must have accounts/addresses on both chains.
The mechanism worked as follows;
Alice and Brian would first need to negotiate on the trade's terms offline, after concluding satisfactorily they go on to create similar HTLCs that can communicate with each other on either chain, a setup referred to as a "tunnel". The whole mechanism is insured by an arbitrary hashed integer simply referred to as "the secret" and bitcoin's nLocktime parameter.
Assuming Alice is first to set up their HTLC after the negotiation part; they initiate a transaction to send BTC to Brian via the tunnel, conditional on the secret they pick being known by Brian, or that both parties sign the transaction enabling Brian to receive the BTC.
They then create a second transaction to pay the same BTC in the first transaction back to themselves at some epoch, T_1, and send this second transaction to Brian who signs it with their public key and sends it back to Alice. After Brian sends the contract back with their signature, Alice submits the first transaction to the Bitcoin mempool.
Brian then creates their own Ethereum transaction sending ETH to Alice, on the condition that the former knows the value of Alice's secret, or that they both sign the transaction enabling Alice to receive the ETH. Brian also creates a second transaction which sends the ETH from their first transaction back to them after some time, T_2, where T_2 < T_1. Like before, they send the second transaction to Alice who signs and sends it back.
Brian then submits their first transaction to the Ethereum mempool, enabling Alice to obtain their ETH by revealing the hashed secret. After a preset number of confirmations on the Ethereum blockchain, Alice's secret is revealed to Brian, enabling the latter to use it and complete the former's first transaction sending BTC to them.
Basically, the tunnel structure the HTLCs form between both chains enables the contracts to monitor the states of both blockchains, ensuring that each transaction of the process is up to a certain depth in the merkle tree of its originating chain, and thus validating it.
The major drawbacks of this system include-
offline coordination and negotiation must occur before the tunnel is setup, thus the process is mostly a reimplementation of a generic OTC market but with no middlemen.
The parties conducting the exchange must remain online during the duration of the exchange to ensure it occurs as seamlessly as possible and prevent potential theft.
There's a free option problem exploitable by the first user to create and fund their HTLC, which is covered much better here. Basically, from our initial description, Alice could choose to delay claiming the ETH locked up in Brian's HTLC for as long as possible in order to see if they achieve a better payoff by buying it or jinxing the trade.
There's also a liquidity DoS/troll attack exploitable by Brian, where they delay opening their own end of the tunnel for as long as possible or opt out entirely after Alice has started the process, leaving Alice's funds inaccessible for an irreversible period.
All these, including regulatory uncertainty around the framing of cross-chain atomic swaps as options, led to the eventual abandonment (or refinement?) of the method.
Stateless Simple Payment Verification Swaps: or simply stateless swaps, are based on simple payment verification (SPV) proofs. SPV proofs are a form of Dynamic Membership Multi-party Signatures (DMMS), which is a long-winded way of saying these signatures enable users to transfer assets of equivalent value between two blockchains, through a two-way state peg scheme, while enabling another party to verify the validity of this transfer on either blockchain. That is, DMMSs enable a user to transfer w amount of BTC to another party and present a proof of this transfer to a smart contract that will release w amount of ETH to them, where w is denominated in a common currency/numeraire.
SPV proofs specifically are a form of probabilistic insurance against state reorgs up to a particular point. They can be used to approximate the finality of a particular transaction based on its quality (accumulated difficulty).
Proof of Resource blockchains achieve probabilistic finality by expedition of a particular resource to extend the chain's state, the general assumption being that the most resources will be spent on extending the most valid state. SPV proofs are based on this correctness of this assumption; that a transaction situated in a header sufficiently far in the chain's history is as reorg-resistant as the quality of the headers up to the chain's current state.
Cross-chain stateless swaps are enabled by SPV proofs and work by checking for a specific event in a chain's history as well as how much validity the event has based on its position in the history. If the event satisfies all the conditions of the swap, it then triggers a change in a second chain's state.
In this way, stateless swaps are analogous to good-till-cancelled limit orders, in that Alice simply sets up a contract containing the ETH they wish to sell, at what price they wish to sell it and how much quality the payment for their order must have. Bob or Chris or Duke could see the contract when it is propagated across the ethereum network and decide they want that much ETH. They then make the payment for the ETH on Bitcoin to Alice's provided BTC address and ensure their transaction satisfies all the conditions of the swap. They then input their transaction's hash into the contract which verifies its validity and allows them to claim the locked ETH.
The concept of SPV proofs and stateless swaps is succinctly covered in this video and article from its creators.
Stateless swaps failed to take off at the time, although they were very much needed. A probable reason for its market failure might be the UX complexity associated with the process, or maybe they were too early for the market, or they simply weren't in line with the risk appetite of crypto participants at the time.
Either way, stateless swaps are a very neat tool and are often utilised in cross-chain bridges.
Generally, cross-chain swaps also required the two (or more?) parties involved in the trade to be online in order to be seamless. This requirement, although seemingly trivial, could be very troublesome in edge cases of network failures and downtime.
Partially on-chain CLOBs:-
the Limit Order Book design was an obvious one since it is one of the most commonly utilised market designs and has even been tried before in a less welcoming environment. However, as we observe in the name, these markets in this context were
a. only partially on-chain; due to overhead costs of maintaining open orders on a public, permissionless ledger as we noted earlier in "Counterparty".
b. centralised; as their matching engines and logic for processing user orders were operated internally or by proprietary bodies.
The second point especially was troublesome as it went directly against the ethos prescribed by the niche. But this didn't prevent such market places from attracting and retaining a considerable amount of users and volumes, back then at least.
Model examples of such markets were Etherdelta and iDEX, and more recently- Serum, dYdX, Hxro and Drift on Solana. The latter markets on solana take advantage of the relatively negligible fees to overcome the overhead costs of maintaining an on-chain order book.
Following regulatory crackdown on etherdelta, most of the other markets at the time went through a reform that ultimately resulted in reduced on-chain activity for a while.
Financial Alchemy:-
While Etherdelta was undergoing its woes, Uniswap began its meteoric rise to domination through 2019, giving rise to a truly permissionless and fully on-chain market with no restrictions and minimal oversight.
Although revered greatly, Uniswap was actually not the first to launch a constant function market, as its simple design was preceded by Bancor's "smart tokens" and bonding curves (which is a bit of a perpetuated misnomer).
In Bancor's smart token model, a smart token represents a basket of other component tokens which depend on it for price discovery via a continuously calculated process dependent on demand and supply. These smart tokens also contain at least one "reserve token" with an established market presence which is used as a numeraire.
The price for the smart token is obtained as;
balance ÷ (supply × CRR)
where 'balance' refers to the reserve token's balance in the smart token's contract, 'supply' refers to the smart token's current supply, and CRR (constant reserve ratio) is predefined by the smart token's creator to stipulate a constant scale value between the 'balance' and 'supply'.
Uniswap v1 launched the constant product market maker design initially specified by Vitalik. In its design, different smart contracts held different liquidity reserves for different ETH-paired erc20s.
The process flow for a trade of ETH for wHAM is thus;
a. a buyer sends their ETH to the contract via a frontend interface, or directly if they can
b. the contract reduces the ETH's value by a specified percentage for the fee
c. the remaining ETH is added to the ETH previously in the pool, and the new total ETH is used to divide the invariant, providing the new quantity of wHAM now in the pool due to the addition of the trader's ETH.
d. the new quantity of wHAM is then subtracted from the old quantity in the pool before the trader added their ETH
e. the difference is paid to a wallet address specified by the trader via either the 'swap' or 'transfer' modules. the difference here is that the previous simply returns purchased wHAM to the trader, while the latter allows the trader to transfer the purchased wHAM to a different address.
A major fault of this version was the inefficiency of erc20 - erc20 trades which required a two-step trade. Thus, a trade of wHAM to some other token VEGAN would require a trade of wHAM to ETH first and then a trade of the ETH to VEGAN.
This two-step trade process was also implemented in Bancor's later version, where instead of ETH, BNT (Bancor Network Token) was used as the common pool numeraire for all pairings.
The use of these "bridge currencies" greatly reduced liquidity fragmentation and routing complexity, but at the cost of traders being charged transaction fees twice and being exposed to slippage twice continuously for one trade.
This was the major reform implemented in Uniswap v2, alongside flash swaps (unless you're a mempool merchant the latter is mostly trivial). ERC-20 to ERC-20 pairing was allowed, so that a trader could swap their wHAM for VEGAN without having to swap to ETH first, on the condition that a wHAM-VEGAN pool exists.
Around this time, there was also the rise of more specialised CFMMs- Curve for stablecoins & stable assets, and Balancer for multi-asset trades.
Another interesting model whose design was based on Uniswap's CPMM is Thorchain, which implemented its invariant at the consensus layer, instead of the application layer as in other markets. i.e. Throchain basically functions as a blockchain used to facilitate trades between other blockchains.
Thorchain connects to external blockchains via a one-way state peg scheme, so that its validator nodes are able to ensure the validity of inbound transactions by making “witness transactions”, which they use to commit blocks and ensure liveness. Thus, any connected blockchain's state is continuously monitored, and state changes targeted at Thorchain are used to modify the latter's state.
A witness transaction will typically contain the state change's transactional data (memo, transaction hash, origin & target chain and address), and is composed and broadcasted by nodes. When a quorum is reached, an exchange logic is applied.
“liquidity is achieved by bonding each supported asset to the network's native asset in pools, where the purchasing power of the asset is measured by the ratio of the depths of both assets”
Thorchain's exchange logic as previously noted is CPMM-like, specifically, it is very similar to Bancor's design where assets are bonded only with the native asset. However, Thorchain's exchange logic is implemented at the consensus layer and contributes to network security, while Bancor's is implemented as a dAPP and doesn't contribute to network security.
Thorchain's model also incorporates a slippage-based fee on trades, so that the fee paid for a transaction is proportional to the supply and demand of liquidity at any point. To an extent this fee model can be considered the first implementation of a dynamic fee model for a CFMM. It is made easier and less expensive due to the exchange logic's implementation at the consensus layer, so that fee tracking and adjustment is trivial. In contrast to fee tracking on dAPPs, where the costs of running a smart contract to track trade sizes and available liquidity potentially negates the benefits.
Fourth Generation of Crypto Native Markets; the continued rise of the Unicorn and its horsey side
From Vitalik's reddit post, to Bancor's shaky beginnings and Hayden Adams' nights on couches; the CFMM space has evolved greatly in both positive and negative ways, all while maintaining the promise of ever available, permissionless markets.
But these markets are extremely inefficient for both takers (traders) and makers (liquidity providers), the payoff was greatly skewed in favour of arbitrageurs. The only thing it has going for it is the ease with which one could create a market for any asset, using any parameters and without having to go through what is usually a long-winded permissioned process. Also there are zero restrictions on who could use the contracts and backend for trades, although the frontend has been gated in order to be more regulation-compliant.
Some of the inefficiencies of CFMMs are in part due to the environment in which they are executed (the consensus layer), or due to the CFMM's parameterisation. We'll briefly explore the latter for both makers and takers in CPMMs.
The most touted fault of CFMMs generally is "impermanent loss", which is actually quite permanent in practice.
In the relatively new, and ever evolving world of decentralised finance; you could choose to either buy an asset directly (henceforth we assume you purchase the asset with 50% of your total capital and keep the remaining 50% in your numeraire, the dollar) on any number of decentralised exchanges and be wholly responsible for storing and handling your investment as you see fit, or; you could choose to be a liquidity provider for a constant product market maker, the specific type of decentralised exchange which we're interested in right now, a "vanilla" CPMM, and provide assets in a 50:50 ratio in a liquidity pool comprising of a volatile asset and the dollar.
In the first case, as previously stated, you are wholly responsible for managing your investment and rebalancing as you see fit. In the latter, the quadratic process of rebalancing is automatic due to a strict "pricing function". This process is responsible for the problem commonly referred to as impermanent loss, or more accurately- divergence loss.
When vanilla CPMMs rebalance, either due to trades or evolving asset prices, the costlier asset is sold into the cheaper asset to ensure their dollar values constantly remain in an equal ratio. Thus, in the event of a downturn in prices of the asset, our dollars are automatically sold to buy an increasingly worthless asset.
Another fun bit about vanilla CPMMs is that positions aren't customisable! When you provide liquidity you do so for ALL TRADES, for prices ranging from zero to infinity. Stating the obvious, this is a lot and spreads the LP's capital too thin, leading to less capital efficiency for them, and worse execution for traders due to the higher price impact of their trades.
Thus, vanilla CPMMs have two major problems they pose to LPs; diminished or net negative payoff due to impermanent loss and capital inefficiency due to being spread too thin.
On the other side, takers experience amounts of slippage directly proportional to the quantity they wish to trade, alongside the fees. This slippage is mostly a protective feature for CPMMs, to prevent the emptying of reserves, but is often more problematic due to consensus layer inefficiencies.
So Uniswap v3 birthed another primitive in its bid to be more capital efficient- concentrated liquidity CPMMs, commonly referred to as 'clAMMs'.
Uniswap v3 solved the capital inefficiency problem to a great extent by introducing bidirectional range pools, allowing LPs specify over what price range they wanted their provided assets to be available for trades. Allowing better execution for traders and higher payoff for themselves, range pools enable a liquidity provider on a CFMM to "concentrate" their liquidity within a particular price range, or a collection of price ranges.
This essay has been a review of past designs that don't entirely scale and ones that don't scale at all. A succinct understanding of the shortcomings of these designs is how we evolve and design better mechanisms!
The second part will be another deep dive into newer, shinier designs and mechanisms that evolved from the ashes of these predecessors.
Thank you for reading this far! Hope you'll be there for the second part.