<
Back to arcticles
Penumbra’s DEX Arrives From The Future
Penumbra has achieved another major milestone in our journey to mainnet. ThePenumbra testnet now includes our flagship feature: a private,concentrated-liquidity DEX with unique capabilities only possible with a Cosmosappchain. These capabilities advance the practical utility of decentralizedexchanges as an alternative to centralized exchanges for both liquidityproviders and traders, and the launch of the Penumbra DEX provides DEXenthusiasts an opportunity to experience capabilities that until now have onlyexisted in research papers.
Penumbra arrives from the future – now is the time to get ready.
Privacy is key to unlocking the future of crypto. Real-world coordinationrequires control over information disclosure, yet existing systems broadcast allinformation to all participants all the time. This increases costs for existingusers in the form of MEV, and makes new kinds of coordination likeConstitutionDAO impossible. At the same time, existing privacy solutions havefailed to achieve wide adoption, because they don’t provide economically usefulfunctionality: users can shield their funds, but can’t do anything furtherwithout unshielding them.
At Penumbra, we believe the way to bring privacy into the mainstream is to startwith one concrete application — one where excess information disclosure hasreal, quantifiable costs, and where private systems can out-compete transparentalternatives on the merits — and then, use the lessons learned from thatapplication to build a general-purpose interchain privacy layer.
That application is trading, and it’s why we’ve focused on building somethingthat we believe can be the best DEX, even for users who aren’t motivated byprivacy. To achieve this goal, we’ve designed an advanced DEX engine withfeatures no existing alternative supports:
This combination of capabilities breaks out of the existing paradigm, in whichtraders and market-makers must choose between using centralized exchanges, wherethey give up custody to preserve their alpha, and decentralized exchanges, wherethey reveal their alpha to retain custody. Let’s see how it works.
Budish, Cramton, and Shim (2015) analyze trading in traditional financial markets using the predominant continuous-time limit order book market design, and find that high-frequency trading arises as a response to mechanical arbitrage opportunities created by flawed market design:
These findings suggest that while there is an arms race in speed, the arms race does not actually affect the size of the arbitrage prize; rather, it just continually raises the bar for how fast one has to be to capture a piece of the prize… Overall, our analysis suggests that the mechanical arbitrage opportunities and resulting arms race should be thought of as a constant of the market design, rather than as an inefficiency that is competed away over time.
— Eric Budish, Peter Cramton, John Shim, The High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response
Because these mechanical arbitrage opportunities arise from the market designeven in the presence of symmetrically observed public information, they do notimprove prices or produce value, but create arbitrage rents that increase thecost of liquidity provision. Instead, the authors suggest changing from acontinuous-time model to a discrete-time model and performing frequent batchauctions, executing all orders that arrive in the same discrete time step in asingle batch with a uniform price.
This approach is an even more natural fit in the blockchain context, where thenetwork already comes to consensus on batches of transactions (called blocks) indiscrete time steps. Aligning economic mechanisms with consensus mechanismseliminates mechanical arbitrage that provides no value to users and negatively interacts with economic security.
Penumbra eliminates intra-block transaction ordering by executing all swap andLP intents at the end of each block, in the following phases:
In this model, intra-chain arbitrage (making prices consistent within the chain)is performed automatically by the chain, while inter-chain arbitrage (makingprices on Penumbra consistent with other markets) is performed by arbitrageurs.This arbitrage game has interesting pro-rata dynamics, which you can read aboutin this research paper we collaborated on with the Bain Capital Crypto team.
It also allows for interesting tools for market-makers. For instance, by openingand closing a position in the same transaction, market-makers can create JITliquidity with prices valid for exactly one block, competing on price ratherthan ordering.
However, the biggest impact is efficiency: because DEX execution only runs onceper block, not once per transaction, Penumbra can amortize the cost of executionover all swap intents, providing significantly better execution quality for thesame compute budget. This is further enhanced by vertically integrating the DEXengine with the node software, as execution happens in native Rust code withaccess to concurrent state access and parallel computation.
Liquidity on Penumbra works differently than other chains. Each liquidityposition on Penumbra is its own constant-sum automated market-maker (AMM)trading between two assets at a fixed price, similar to a limit order. Thisdesign gives market-makers complete control over their liquidity, at the cost offragmenting it across each individual position. But because trades are optimallyrouted over the entirety of the liquidity graph, this fragmentation does notaffect users, whose trades are always executed against the best available liquidity. This is possible because individual positions are AMMs of thesimplest possible form, so optimal routing across them is just a graph traversal.
Liquidity positions themselves are public, so all users have the same view ofthe market state, but they can’t be identified as belonging to a specificaccount, allowing market makers to protect their strategy and trading history.
Active market makers can quote prices and adjust them as frequently as everyblock. All DEX activity is processed in batches, so they don’t need to competefor ordering within a block. As a demo, we’ve built a bot calledOsiris that can quote prices from the Binance API with a customizablespread. This bot is live on the Penumbra testnet today.
To support passive liquidity, we’ve also shipped the first version of ourreplicating market maker (RMM) tooling, which constructs a set of concentratedliquidity positions whose payoff function replicates the payoff of an arbitraryAMM. This allows users to provide passive liquidity with any AMM they want –Uniswap V2, Uniswap V3, Balancer, Curve, etc – without any special supporton-chain.
On Penumbra, the DEX engine synthesizes many “local” component AMMs into asingle global AMM, whose trading function is the aggregate of all traders’strategies, on all trading pairs, with all fee tiers. Capital efficiencyimproves, because swap intents can execute against synthetic liquidity on amulti-hop route rather than being limited to liquidity on a specific pair. Forinstance, the chain can automatically compose stableswaps between differentbridge representations on either end of a trade, making the available liquidityindependent of the specific bridge path of an asset.
Routing a desired trade on Penumbra can be thought of as a special case of theminimum-cost flow problem: given an input swap intent of the source asset S, wewant to find the flow to the target asset T with the minimum cost (bestexecution price). Each liquidity position is a constant-sum AMM that allowsexchanging some amount of asset A for asset B for a fixed effective price.
This means liquidity on Penumbra can be thought of as existing at two differentlevels of resolution: a “macro-scale” graph consisting of trading pairs betweenassets, and a “micro-scale” multigraph with one edge for each individualposition.
In the micro-scale view, each edge in the multigraph is a single position, has a linear cost function and a maximum capacity: the position has a constant price (marginal cost), so the cost of routing through the position increases linearly until the reserves are exhausted.
In the macro-scale view, each edge in the graph has a convex cost function, representing the aggregation of all of the positions on that pair: as the cheapest positions are traded against, the price (marginal cost) increases, and so the cost of routing flow through the edge varies with the amount of flow.
To route trades on Penumbra, we switch back and forth between these two views,solving routing by spilling successive shortest paths.
In the spill phase, we perform a graph traversal of the macro-scale graph fromthe source asset S to the target asset T, ignoring capacity constraints andconsidering only the best available price for each pair. At the end of thisprocess, we obtain a best fill path P with price p, and a second-best spillpath P' with spill price p'>p.
In the fill phase, we increase capacity routed on the fill path P, walkingup the joint order book of all pairs along the path P, until the resultingprice would exceed the spill price p' (or a price limit). At this point, weare no longer sure we’re better off executing along the fill path, so we switchback to the spill phase and re-route, or terminate if we've exceeded a limit.
This approach splits the required state accesses into two modes, each of whichwe can optimize: in the spill phase, we perform a parallel graph traversallooking only at the tip of the order book, performing concurrent random accessesto a small amount of state for each pair; in the fill phase, we execute seriallybut perform a linear scan of the state as we walk up the joint orderbook of thepath.
The exact same code path also allows us to perform in-protocol arbitrage: wehave the chain make a flash loan to itself, and attempt to route along a cyclefrom the staking token to itself with a price limit of 1, filling anymispriced positions along the way.
Finally, because the Penumbra codebase is built around lightweight, copy-on-writestate forks, simulation capability is built in: traders running full nodes candirectly simulate execution via RPC, executing exactly the same codepaths on anephemeral state fork.
To find out more about how to use the testnet, check out the user guideon how to install the command-line client pcli or run a node, then join theDiscord and post an address in the faucet channel to get testnet tokens.
We’ve added several new test assets to the allocations, including test_usd,test_btc, test_atom, and test_osmo to help simulate paper trading, andwe’ll be running an instance of Osiris that quotes real-world prices – but, likeall other Penumbra testnet tokens, these have no value whatsoever! Happytrading!
