Background
Web3 is improving financial technologies by facilitating access to common infrastructure for computing, transferring and storing value. Used correctly, this access can reduce reliance on intermediaries who impose excessive costs on users through rent-seeking or waste. But in some cases, intermediaries have expertise or economies of scale that are beneficial to users and worth preserving.
The fact that not all financial workflows involving intermediaries need to be delegated to web3 drives the popularity of hybrid systems. Hybrid systems allow builders to delegate trust to blockchains when the cost reductions are compelling but preserve advantages from existing infrastructure or expertise in targeted cases. Fundamentally, hybrid systems are able to modularize trust, assigning some components to experts or existing infrastructure, and other components to blockchains.
Examples of hybrid systems include L2s, bridges, multichain aggregators, oracle-dependent applications, and web3 games. This earlier article discusses the emerging contact surface between on- and off-chain resources in the context of Arrow Markets, a hybrid web3 platform for connecting options traders. Convergence RFQ, an on-chain primitive for provisioning protocol liquidity on Solana, also uses a hybrid architecture.
What are Intents?
Intents are a type of order, enabled by hybrid systems, that provide greater flexibility for applications to process components of the application logic outside the scope of the base layer. This Paradigm article is an early reference on intents that emphasizes intents are declarative, in that, relative to an imperative, fully on-chain transaction, it commits to an outcome, but not necessarily the computational path to that outcome.
Intents can and should be used to reduce the user-facing complexity of an order. For example, a user can execute a complex sequence of transactions with one click by allowing the application to delegate transaction components to specialized resources, like a multi-asset limit order book run by a reputable specialist. Delegating transaction components to alternative resources can be used to optimize user experience along many dimensions, including complexity, frequency of interaction, and several forms of expenses including gas costs. Intents can also eliminate MEV, as in the case of Arrow Markets, a point made in this post.
Intents-based circuits rely on specialized resources like oracle networks, centralized matching engines, and trusted counterparties.1 A specialized resource is any resource external to the blockchain where the value is transferred and stored. In practice, if a resource is included in an application architecture, it has advantages for the function it performs relative to the base chain, so we can limit our attention to specialized external resources. By the time an intent makes it to its base chain, only a subset of the transaction elements need to be computed, so the intent allows the transaction to abstract from specifics that are determined through a resource other than the base chain.2
There are many degrees of specialization and centralization in practice, and not all hybrid systems are intents-based. Mempool implementations like FlashBots and Jito are hybrid systems, because trust is being delegated to the block builders or their clients who have some expertise or private incentive to organize blocks in particular ways that are implemented outside the scope of the base-chain consensus. However, with the possible exception of Jito, it is challenging to incorporate the degree of freedom MEV extractors exploit to benefit the end user, so intents are not exactly the right model. Other specialized resource implementations of hybrid systems include Arbitrum and Base sequencers, multichain DEX aggregators, and fintech applications like Convergence RFQ and Arrow Markets. Of these, the DEX aggregators and the fintech applications are intents-based hybrid systems.
The Modularization of Trust
Intents and hybrid systems support architectures with isolated trust modules. Trust modularization is a helpful mental model for evaluating which steps of a transaction should be carried out on the base layer and which can be specialized to alternative resources. This decision space can be as simple as which pieces are to be implemented on an Ethereum smart contract and which pieces can be carried out on a server run by a trusted party. As cross-chain and multi-resource communication innovations facilitate finer-grained architectures, the trust modularization model evaluates how applications can run specialized modules on specialized resources.Â
A transaction needs to be decomposable into modules that can be processed independently for the distinction to be meaningful. As an example in practice, Arrow Markets carries out the settlement payoff computation, retrieval of the settlement price, and the distribution of terminal payoffs entirely on-chain. In contrast, matching - equivalently, price discovery - as well as risk management, are handled off-chain, by experts. This bifurcation is optimal, because the costs of moving price discovery and risk management computations on-chain is high in practice. These costs typically manifest to traders as high bid-ask spreads in markets with low liquidity. Delegating to reputable experts for these components improves outcomes for users.
Convergence RFQ
Convergence RFQ is an on-chain primitive for provisioning protocol liquidity on Solana that uses intents-based architecture. The intents structure is used to reduce both circuit complexity and transaction costs. The Convergence architecture can be summarized as follows:
Intents: Borrowing core concepts from Uniswap permit 2 architecture, which are pre-authorized transactions that users can create for specific actions on the Uniswap platform. Convergence RFQ adopted the permit 2 architecture for an Arbitrum Integration on Vertex for delta one spreads. These intents include spot swap, and a short perpetual position, to mint a cash and carry trade with one click.
To create an intent, a taker would have to provide the following parameters:Â
Basis trade base asset using available Vertex assets
Size
Define a Buy or Sell order type
Submit the order
Via pre-defined cards with set basis points, a user could mint all of the above in one transaction.
Quotes: Maker bots can monitor new intents through a Kafka Queue and provide quotes for them until the intent expires or is confirmed. Only the best quote is stored for each intent.
Authorization: Users can authorize specific actions by signing transactions, essentially granting permission for the intended transaction to be executed on their behalf. These permits are signed using the user's private key and can be stored securely, ready for execution when needed.
Last Look: In an effort to mitigate adverse selection. During a predefined window, a minute(default value) after an intent confirmation, the confirmed maker could do a last look for the intent, which includes signing and sending Vertex orders to the backend service. The intent is ready to settle after that and we settle the intent in this backend call immediately. It would save settlement results to the intent - either success or failure.
Efficiency: By pre-authorizing transactions, UP2 reduces the need for users to interact directly with the blockchain for each transaction, significantly improving efficiency and reducing gas costs associated with executing trades on Convergence.
Arrow Markets
A user who comes to Arrow is initially shown a curated list of reference prices, but can also request quotes for any instrument in real-time. These quotes are benchmarks that traders can use when submitting an order. When submitting an order, a request for execution (RFE) is made, where the user chooses a target price (typically from the broadcasted quotes), a tolerance (similar to slippage on an AMM), a quantity, and the necessary variables to identify the instrument or bundle, including strikes, expirations, contract types and underlyings.Â
The request is sent to a server network and broadcast instantly via websockets to a network of registered makers. Market makers have a selected amount of time to respond. The target price and slippage are encoded so makers all submit their most competitive quotes. The order is matched with the best maker or combination of makers, and the transaction is sent on-chain with the execution price and counterparties filled in.Â
All quotes and RFE responses are recorded to a SQL database for reproducibility and to facilitate performance analyses. Makers agree to KPIs on bid-ask spreads before integrating. All order parameters are hashed and signed by the trader and then verified by the server and subsequently the smart contract using the Ethereum elliptic curve cryptography (ECC) standard. The instrument is delivered to the user on-chain via NFT, and the settlement price and computations are computed on-chain. The settlement computation is triggered by Chainlink Keepers. Â
Because the counterparty and price matching are carried out through the network of makers, they are determined before the transaction is sent on-chain. Hence the RFE can be viewed as an intent to purchase a specific instrument and spend no more than some maximum price (since this is also checked on-chain). The specific prices and combination of counterparties are determined by the automated system for communicating with makers, so by the time the transaction gets on-chain, there are no remaining free parameters.
The system relies on existing expert infrastructure for risk management and reputation building, while the terms for instrument payouts are computed and distributed on-chain. Hence, the pricing and settlement components are modularized, with the former delegated to experts and the latter delegated to the blockchain. The targeted delegation of trust enabled by this modularization is a primary advantage of Arrow’s microstructure, which is built to provide both more reliable instrument prices than fully on-chain implementations and more transparency than centralized options venues.
The FutureÂ
The set of possible hybrid and intents-based systems is large. We think focusing on a few main areas for web3 financial applications will be productive, including price discovery and enforcement for margin systems, where third party experts are earning disproportionate rents. This means streamlining the communication circuits between resources using things like creative private-key-cryptography wiring and zero knowledge. It is important to remember that these architecture decisions are about tradeoffs, and the benefits of delegating trust to experts or centralized resources need to be weighed against the costs. We believe we will see this tradeoff more tightly calibrated in the future as builders continue to push the boundaries of intents-based and hybrid systems.
Citations
[1] Anoma: a unified architecture for full-stack decentralized applications August 21, 2022: https://media.githubusercontent.com/media/anoma/whitepaper/main/whitepaper.pdf?ref=blog.anoma.net
[2] Paradigm article, June 2023: https://www.paradigm.xyz/2023/06/intents
This essay does not constitute a solicitation to participate in Arrow Markets, which is limited to use by select non-U.S. persons, or Convergence RFQ.
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.
While the specialized resource can be on- or off-chain, we can think of the fully on-chain resource as a limiting, special case for intents. Limiting, fully on-chain intents implementations are via smart contracts, and are not hybrid systems. For example, a smart contract can carry out a sequence of checks of alternative paths and choose the one with the least cost. But, these have limited computational firepower and may not reliably assess the relative costs of the paths inline.
If all components are carried out on-chain, the intent is trivial, so we are thinking of transactions where the end user needs to specify N parameters but only N-K of these are computed on-chain with 0 < K <= N.
 | A guest post by
|
 | A guest post by
|