Before the collapse of Luna, I was running a stablecoin yield strategy for an older friend of mine who wanted exposure to the absurd "FTX Customer Deposit Special" rates we were able to earn back in 2020/1. My friend was not a crypto specialist and never even made a transaction at all before we had worked together. Our arrangement was simple. He would custody his funds on his own hardware wallet and then we would meet once or twice a week on Zoom, where I would explain to him step by step what he needed to do.

From the get go we were depositing funds into nearly every available DeFi protocol on every chain. Within a 2-4 hour session we would make tens of transactions to approve, move, swap, deposit, claim, and withdrawal funds. Funds were moved into custom Uniswap LPs, Curve vote locking, and more, all spread out to capture rewards. We used almost every bridge service, major DEX, yield aggregator, and more to move our basket of stablecoins around. No yield was too far out on the crypto frontier to stop us.

To say I threw him headfirst over a cliff is a little too kind.

The hardest part of my job was trying to explain in detail all the steps we would need to take. I would give commands and he would go execute them, having to figure out the UIs of all these complex DeFi tools. It was a lot of "click here" "go there" "swap this" in our meetings. Taking for an example the process of swapping USDC for a FRAX/DAI LP on Polygon:

1. Swap USDC to DAI on Uniswap (2 transactions, approve + swap)
2. Bridge USDC & DAI to Polygon (4 transactions, approve + bridge)
3. Combine USD and DAI on Polygon DEX (4 transactions approve + bridge)
4. Deposit LP into vault to receive rewards (2 transactions approve + bridge)

For this one simple movement of money, we would need to fire off 12 transactions! We had to find, create and execute individual transactions directly to the EVM using information provided through protocol specific UI's. The process was manual, long, and arduous, especially with a sizable diversified portfolio. On reflection its crazy how complicated these tasks were just to ape into a few yield farms.

On a high level all of these processes that we were carrying out had an explicit "how" and "what" of what the desired outcome should be. We had assets and we wanted to do X,Y,Z tasks with them. Like the example above, "We have USDC (on Ethereum) and we want to provide liquidity as FRAX/DAI (on Polygon) and then deposit it into a staking vault" is the "what" and the 12 individual transactions we had to execute individually is the "how." There is a clear, logical set of steps needed to go from the start to end point, all of which is quantifiable.

What would have made the process vastly easier and brought down to 1-2 steps would be a powerful algorithm built to handle transaction routing. We would share our desired outcome and the algo would return the best path for us, and potentially would even handle execution.

This type of path mapping structure is called "intents" and it's one part of a middleware future Ethereum is barreling quickly towards. While we do have a broad conception of what an intent is, there is no consensus definition yet, but there are some general ideas.

Here's Paradigms version: "An Intent is signed a set of declarative constraints which allow a user to outsource transaction creation to a third party without relinquishing full control to the transacting party."

Another definition from David Ma of Near: " Transactions are imperative whereas intents are declarative. In other words, transactions are well-defined messages that specify how to run the EVM to produce a state change, whereas intents specify a desired state change while leaving the implementation unsolved"

In both definitions, an intent is "declarative," a call for outside help through data sharing between a user and a "solver." The users declares their desired outcome, and a solver gives them the method to achieve it. Unlike a transaction, which has specific parameters, an Intent has to be mapped out by a third party.

Additionally there are constraints which limit the set of paths possible. This helps bring the total number of possibilities to a smaller, filterable set which the user can choose from.

With my friend being an example, Intents would have allowed us to broadcast our end goal to a set of solvers who would then compute the most optimal path. We would then choose the best priced route and the transaction would execute. All of the intermediary steps would be handled by the solver's route, leaving us with 1-2 transactions to confirm.

Rudimentary "Intent" based architecture has already been built on the EVM. When you use any DEX, it finds the optimal route for trade execution. In the above Curve interface, after choosing assets to be bought and sold, the UI automatically finds the best LP to route through.

Since there is no USDT/frxETH LP, the order is routed through several LPs to get the best execution USDT > sUSD > sETH > ETH > frxETH. All within one transaction.

It also gives a rough idea of what price impact will be, and a user can do to limit slippage. Once the right parameters are chosen, the UI also helps build the raw EVM data for broadcast.

This Curve trade is an intent, just a very basic example. The UI is just a helpful tool to build swap transactions with the following logic:

FRAX Transaction: Swap 100,000 FRAX for at least 999,000 USDC with the 5bps FRAX/USDC Curve LP, valid until X block.

Intents on the other hand share a desired outcome (acquire the maximum amount of USDC) and constraints (only sell 100,000 FRAX). It's up to the solver to figure out what the best swap rate is.

If you've ever used 1inch or DeFiLlama you've seen an Intents system for building swap transactions. With Llamaswap you still provide all the parameters for execution, and then are given a set of potential transaction relayers who will execute the transaction. In the above screenshot, all of the potential swaps are still run through Curve (except for CowSwap, but we will talk about that later), but they have different fees and gas costs depending on the relayer of the transaction. Ultimately it's up to the user to choose the best price/cost.

In addition to swap aggregators, several other types of "Intents" already exist on Ethereum:

1. Limit Orders: Allows assets to be taken from an account if conditions are fulfilled.
2. CowSwap-style Auctions: third party order execution with non-DEX liquidity.
3. Gas Sponsorship: Allows for third party transaction execution using tokens like FRAX, applicable for Account Abstracted wallets.
4. Delegation: Whitelisting falls under this, where a check is made to a database before transaction can be executed.
5. Transaction Batching: Allow batching of intents for gas efficiencies.
6. Cross-Chain Swaps: See Socket

While there is a growing diversity of order types, the easiest way that I've seen Intents described are "limit orders" but with a new marketing speak. A limit order is a desire to buy a certain amount of assets at a certain price. The order itself is not filled until another party comes along and takes the order.

Like a limit order, an Intent is made up of two partial transactions. The first part is the desired end state from the user. The second part is the proposed transaction by the solver. When you put the two together, you end up with what's needed to execute a transaction.

MEV for Sale

There are few risks with how Intents based architecture is constructed. First, solvers have the incentive to not propagate Intents that contain MEV they can profit from.

"In many cases, extraction of MEV requires a user’s order to be executed on chain. In these cases, execution of the user order exposes a blockchain state that can be profitably acted upon by an extractor. Backruns and sandwiches are common some examples."

Intents core feature is data leakage. By signing a message of Intent, you signal your willingness for MEV extraction at the cost of convenience. As Intents cannot be broadcasted directly to the Ethereum mempool, the place where transactions are queued before execution, they are filled on private off-chain Interpools.

These Interpools can be permissioned, permissionless or a hybrid of the two.

Permissionless mempools employ a decentralized API, enabling nodes in a system to share Intents freely and grant unrestricted access to executors. Examples include the 0x protocol relayers and the proposed shared ERC4337 mempool. Open mempools are ripe for DDOS attacks and cannot ensure the propagation of intents that dissuade poor execution.

Permissioned mempools, in contrast, a trusted API that's DDoS resistant and eliminates the need for intent propagation. Relying on trusted intermediaries, they assure execution quality as long as trust is maintained. Such intermediaries often have a reputation to uphold, which acts as an incentive for them to ensure top-notch execution. But they still have strong trust assumptions, which detracts for the core ethos of open blockchains.

Hybrid solutions bridge the gap between permissionless and permissioned systems. They might employ permissioned propagation coupled with permissionless execution, or the reverse. Order flow auctions like CoW Protocol use a trusted party (the protocols off-chain order matching) to operate the auction, but participation is permissionless.

The most popular Interpools today are centralized and permissioned, with no incentives share information with competitors. The risk here is that one party absorbs the majority of all Intents-based transactions and uses its monopoly to start introducing fees and other rent seeking behavior. The negotiating power users have disappears to extractive middlemen.

Middleware Risk

When contextualizing Intents as limit orders, we can make a clear comparisons to Robinhood's Payment for Order Flow (PFOF).

The brokerage giant offers "free" trades to its users on the basis that they get to sell the order flow, rather than routing them to traditional exchanges. Market makers, who are firms that buy and sell securities in large volumes, offer this payment as they can profit from the bid-ask spread of the orders.

Critics have widely panned Robinhood for conflict of interest. While brokerages are obligated to provide the best execution for their clients' orders, the monetary incentive from PFOF is claimed to influence their decision on where to route the orders.

Intents are a form of PFOF arbitrage, just we call it MEV. Standing open orders (partial orders) create arbitrage opportunities potentially far more valuable than transactions manually added to the Ethereum mempool, as the solver gets to determine the route, rather than compete for pre or post trade MEV in a given block with sandwich transactions.

An unchecked, non-transparent solver is highly incentivized to provide the worst routes possible, as their profit margins are inversely correlated with good execution. Users still have to pick the solver, and they can use this negotiating power to force solvers to bid against each other for the order flow. The solver with the highest returns for the user within constraints wins the auction.

This design is what's used by CoWSwap, which uses batch auctions to find the most optimal settlement price for traders. On the CoWSwap, orders are not executed immediately but collected and settled in batches. Instead of a central operator, the system uses an open competition of solvers to match orders. These solvers submit solutions for settling orders once a batch is closed.

Batch Auctions, however, enable trades within a batch to have the same price, negating the need for miners to rearrange trades. No front-running or back backrunning. CoW Protocol uses Order Flow Auctions to ensure traders get the best price execution. But there is some MEV with CoW orders, as market makers must be able to arbitrage the trade on another venue to remain profitable.

Future Implementations

Right now several protocols are developing Intents based infra to allow for hybrid systems. Flashbots SUAVE is explicitly building a private mempool and block building network to direct traffic to L2s and Ethereum. Anoma is trying to build next generation fully permissionless infrastructure. Several other companies are throwing their hat in the ring as well too.

While there's no consensus on who the winners will be for Intents, it's just one growing part of the emergent middleware layer revolution taking place in crypto today necessary for convenience. Crypto UI "as-is" is not user-friendly enough for wider adoption. Intents are typically for swaps and order batching currently, but the goal is to have them adapt to fully generalizable and arbitrary data.

It opens up the possibilities of what can be built on Fraxchain, as all wallets potentially will by-default be Account Abstracted. A robust Intents layer could unlock new use cases for Frax products and simplify their use for applications building on top of it.