The Arrow Markets V.2 Frontier
Arrow V.2 implements an optimized microstructure primitive for options
Arrow Markets lives in a world of burgeoning market microstructures. In this world, application developers use programmable blockchains to delegate trust, harness liquidity and manage data.1 Trust in counterparties like intermediaries is costly because reputation management is challenging and mitigating agency frictions requires effort. By providing common infrastructure for reducing the cost of delegating trust, programmable blockchains drive down barriers to entry for new financial applications. These forces drive the proliferation of new market microstructures.2
In the context of this girth of feasible microstructures, the design objective for Arrow Markets is to choose a microstructure to minimize costs to users, subject to the requirement that primitives for pricing, transferring and settling options are implemented. Minimizing costs to users - which come in the form of high bid-ask spreads, high transaction fees, high costs of risk management, obfuscation of the roles of intermediaries, counterparty risk and barriers to access - is analogous to maximizing user experience (UX).34
Minimizing user costs is a compelling objective because in existing options markets, costs of institutional trust - for example in the form of intermediary overhead - are passed on. Because obfuscation and complexity can be tools for established participants, prevailing systems favor insiders and large players, resulting in additional costs to users in terms of execution prices, fees and payment for order flow (PFOF). Moreover, a littiny of centralized brokerages and banks have recently gone insolvent at the expense of their clients, highlighting costs to users of transferring custody to centralized players in nascent markets.
When solving for the microstructure that mitigates these costs, Arrow searches a hybrid design-space. The hybrid space exploits the contact surface between on- and off-chain resources, and Arrow uses this surface to calibrate tradeoffs between trust and performance. Because this problem space is high-dimensional, Arrow focuses on a handful of key margins. To see one of these margins, think about the case when markets are illiquid: if one completely removes trust in experts, bid-ask spreads can become large and volatile. This tells us the benefits of on-chain trust will have to be weighed against costs to users in the form of low-quality prices.
Below I walk through Arrow’s choices and the corresponding microstructure priorities. I also discuss the hybrid space and frame the design problem.
First, TL;DR.
1 → Arrow implements a complete microstructure primitive for options
Full options creation, pricing and settlement workflows
2 → Request for execution (RFE) circuit improves over RFQs, AMMs and CEXs
RFQs require the user to confirm an exploding quote, while the Arrow RFE lets users submit execution requests that are sent to chain directly when matched
AMMs underperform when liquidity is low, and present challenges for options because of instrument multiplicity, enforcement of contingent payments, and on-chain hedging. The Arrow RFE socializes prices in low liquidity environments, handles settlement terms trustlessly, and relies on existing counterparty infrastructure for enforcement and hedging
CEXs typically involve forfeiting custody, while the Arrow microstructure preserves self-custody
3 → Arrow’s microstructure is adaptive and consolidates liquidity
Adapts to changing liquidity profiles, allowing the movement between AMM-style limits and LOB-style limits
Multichain is automatic, and there is no cross-chain price or liquidity fragmentation
Arrow Markets Problem Space
The problem for Arrow is to choose a microstructure to minimize costs to users, given the necessary primitives of an options market, and given that these costs can be reduced by providing good prices and moving trust on-chain.5 There are many costs to users in prevailing market arrangements, both on- and off-chain, including high bid-ask spreads, capital inefficiency, multi-day settlement processes, and costs associated with managing institutional and counterparty trust. Naturally, different microstructure design choices have different implications for mitigating these costs.
Arrow’s choices reflect nuances about how some of these costs interact in practice as a function of market design variables. The design reflects a fundamental tension between cryptographic security and pricing when markets are illiquid. Specifically, costs to asset price quality of moving trust on-chain are high when market participation is low.6 So, in practice the problem is to choose the microstructure that minimizes costs given the necessary primitives, subject to the interplay between performance, cryptographic security and liquidity, and subject to non-monotonicity of the cost profiles.7 The resulting Arrow microstructure improves along each of the target cost dimensions.8
Hybrid Surface
The hybrid space is a fundamental resource that Arrow uses to accomplish its microstructure objectives. Examples of hybrid systems are myriad. Optimistic Ethereum Layer-2 rollups (L2s) like Arbitrum or anything built with the OP stack like Base are hybrid systems, as are zero-knowledge Ethereum L2s like zkSync and the Polygon zkEVM. Block ordering microstructure implementations like mev-boost
on Ethereum and Jito on Solana are hybrid systems, as are asset-backed stablecoins like USDC. Eigenlayer’s actively validated services (AVSs) are designed to enable hybrid systems.
In general, the hybrid design space helps builders optimize and calibrate a variety of tradeoffs related to limitations of delegating trust to a blockchain. Typically this tradeoff is made between trust and things like finality and transactions per second (tps). This was the motivation for many early Ethereum L2s like Polygon and Arbitrum, and also leading alt-L1s like Avalanche and Solana. Circle implements a hybrid circuit for USDC for different reasons, specifically to enforce credibility about the 1-1 dollar backing, balancing on- and off-chain trust. In the case of Arrow, the tradeoff made in hybrid space is between trust and performance, where performance is measured by price quality and the costs of risk management. The Arrow RFE is fundamentally a hybrid system, chosen to optimize along these two dimensions.
Trust versus Prices
In the case of trust versus prices, makers are contracted to quote based on liquidity of their best available spot venue. However, quotes are communicated through off-chain websocket infrastructure. The off-chain infrastructure includes several layers of redundancy and is cryptographically secured.9 This configuration reflects an optimal tradeoff, because from here, the cost in terms of reliable prices to traders of moving logic on-chain exceeds the benefit of delegating an additional unit of trust. Nonetheless, if one were willing to tolerate larger spreads in less liquid markets, more of the pricing and matching could be moved on-chain.
Trust versus Hedging Costs
In the case of costs of risk management, the Arrow RFE circumvents the need for on-chain delta hedging, which would otherwise pass a significant cost on to traders. It does this by delegating risk management to the off-chain systems of makers, which are more cost efficient, and are consolidated across chains. Again, this choice reflects the tradeoff between delegating trust and execution costs. If one were willing to tolerate higher risk management costs to users, typically in the form of poor execution prices, some or all of the delta hedging could be done on-chain.
Multichain Consolidation
There are additional benefits of building in the hybrid space. Arrow’s hybrid stack makes multichain easy. In fact, up to a small per-chain integration cost for makers, multichain is automatic for EVMs. Moreover, the multichain circuit eliminates price variation as a function of target-chain liquidity, because quotes matched by the RFE are chain-agnostic, and already reflect best-depth venues. Hence, under the Arrow microstructure, cross-chain liquidity fragmentation is moot.
MEV-Proof
Arrow uses the contact surface between the on- and off-chain resources to improve pricing and latency via the RFE system, but as a side effect, the circuit eliminates maximum extractable value (MEV). It does this by removing the degree of freedom in users’ signed transactions relative to AMMs like Uniswap, where slippage introduces ambiguity about the final execution price. In the Arrow RFE system, transactions are sent on-chain only after the execution price is agreed to, so there is no undetermined variable for block builders to manipulate.
AMM to LOB Continuum
The Arrow tech is designed to be robust to improvements in liquidity environments. Specifically, as a function of real-time market liquidity, the system behavior lands at an interior point between the following limits
Low-liquidity service provider model (RFE/AMM)
High-liquidity matching model (LOB)
The low-liquidity service model limit is the RFE, which improves over the AMM limit. AMMs are transparent, but low liquidity trading can have catastrophic price impact. If a Uni pool reserve levels are low, even if the ratio is right, the effective execution price of AMMs can be off by double digit percentages.10 Relative to the AMM, the RFE service system does two things: one, it guarantees quotes reflect best-depth venues, and two, if the best-depth venue is thin, prices are socialized.11 Moreover, AMM swaps are subject to MEV, and RFE transactions are MEV-proof because by the time they go on-chain, there are no free parameters.
On the other side, the high-liquidity matching model corresponds to a limit order book (LOB). Arrow is designed to converge to a system that can be as democratic as any market can support as a function of liquidity. The Arrow Markets RFE system in its initial version is optimized for low-liquidity environments, but subsequent versions will facilitate a trustless margin system. Hence, makers can be disintermediated organically as liquidity improves, because the margin system makes it easy for new users to write options.12
The real-time Arrow microstructure can move between these limits endogenously because the mixture of participant types varies as a function of liquidity. The different constitutions of participant types - or type demographics - reflect different effective microstructures. Liquidity making is concentrated when most quotes come from market makers, representing the RFE limit, while making becomes dispersed when quotes come from users writ-large, corresponding to the LOB limit.
The Future
There are of course many new things that can be done when moving trust on-chain to reduce costs. Arrow’s solution involves novel programmable workflows that accelerate price discovery and accessibility, which will be important for upcoming versions of Arrow, where margin enforcement becomes fully programmatic.13
Arrow Markets will continue to push the frontier of options market design. Keep your eyes out for upgrades to the Arrow microstructure, including additional cryptographically secure infrastructure for risk management computations, and smart contract support for trustless, automated margining.
This essay does not constitute a solicitation to participate in Arrow Markets, which is limited to use by select non-U.S. persons.
Nothing in this essay is intended to provide tax, legal, or investment advice and nothing in this essay should be construed as a recommendation to buy, sell, or hold any investment or to engage in any investment strategy or transaction.
Credits:
The Arrow Markets tech wouldn’t be what it is today without an incredible team of developers, quants and industry expert advisers - from Citadel, Optiver and NASA to the University of Chicago - whose contributions were inimitable. Arrow has also benefited greatly from the support of the Avalanche team and community. Patrick Kiefer’s bio.
Programmable blockchains draw on earlier innovations in public-key cryptography, which are themselves fundamental to most blockchain workflows.
Spreads can be high because of information asymmetries and/or market power, both of which, outside of edge cases, matter more in less liquid markets.
Because the cost metrics prioritized by Arrow lead to an improved trading experience, the problem of minimizing costs is roughly isomorphic to the problem of optimizing user experience (UX). However, key aspects of the UX calculus are prioritized at the frontend application level and are excluded from this discussion, as are important considerations like PMF. Discussions about how options dominate perpetuals, like the fact that long options can’t be liquidated, are also important but not detailed here.
These priorities are specific to markets for contingent payouts and would differ if one wanted to build a different type of market. For example, the high cost of trading spot on chain may not matter for spot markets where most users are long-term holders. They may also differ for alternative priorities for creating options markets, for example if physical delivery was required for an option on a tokenized commodity.
This is because delegating trust on-chain reduces costs insofar as costs of institutional trust are circumvented, but increases costs when trades are subject to low venue liquidity and manipulation.
There are also design priorities that impact the software architecture
It is adaptive, easy to upgrade
It is easy to debug, easy to use and simple to understand
Layers of redundancy where needed
Reproducibility
While these would be priorities independently of design, items 1 and 3 interact with the Arrow microstructure priorities. The contracts are built to integrate an automated margining system, allowing more users to be makers. Number 4 reflects the fact that in addition to the on-chain data, internal DBs store requests and responses so that any realized transaction can be reconstructed for diagnostic or verification purposes.
Existing market designs represent historical lessons. Discarding the entire existing infrastructure would also be costly. I wrote about similar dynamics here. Arrow Markets chooses a new options trading microstructure that sidesteps important legacy costs, but preserves key lessons from history about redundancy, security and risk management.
At each step, the transaction parameters are verified against a hash of the order parameters, and the sender address is verified against a signature of the hash value using ecrecover
. The orders cannot be forged without the user’s private keys, which is the same security assumption as the underlying blockchain.
Uniswap’s AMM uses a constant product market maker rule that results in a marginal price p
of asset x
in terms of asset y
equal to the ratio of the reserve balances of these assets in its liquidity pool, p = x/y
. Slippage occurs whenever discrete amounts are transacted.
Quotes are socialized in the sense that makers are paid a fixed servicing fee but are obliged to keep bid-ask spreads within a range. This fee offsets expected losses from providing tight spreads in thin markets.
In Arrow’s high-liquidity limit, price discovery may actually be superior to existing LOB implementations, because the automated margin enforcement system reduces the asymmetric costs of taking short positions commonly charged by brokerages.
To facilitate the transition from the AMM-style limit to the LOB-style limit, Arrow programmability enforces self-regulating, automated cross-margining. Liquidations are enforced programmatically, so liquidators never have to take custody of a delinquent users’ assets. Similarly, because of programmability, neither liquidators nor borrowers need to worry about counterparty risk: the trust has been delegated.