Intention is All You Need

Thanks to Kevin from Khalani, Hart and Nick from Across, Khushi from Predicate, Jon from Hyperlane, Soubhik, and Brandon for reviewing drafts of this piece.

Intents are transforming how we think about interactions on Ethereum.

Instead of rigid transaction paths, intents open up a world where users declare their desired outcome — and the network takes care of the rest. From intent-based applications to modular protocols that compose seamlessly with Ethereum, to full-blown intents-first systems, the possibilities are endless.

But none of these visions can scale without verifiable offchain infrastructure — and that’s where Actively Validated Services (AVSs) come in. In Part 1 of this research series, we’ll dive into the intent-based applications of today: how they operate in both single-domain and cross-chain contexts, and how AVSs can unlock new efficiencies for them.

Let’s dive into the future of intents!

What are intents?

Enough has been written on intents since Chris Goes coined the term while working on Wyvern, the precursor to OpenSea’s famous Seaport contract, so I’ll keep this brief.

Intent allow users to express desired state transitions — subject to specific constraints and preferences. While a traditional transaction locks in a specific execution path (“trade $1000 USDC for ETH on the Uniswap v3 USDC-ETH 0.3% fee pool with no more than 0.5% slippage”), an intent authorizes the desired end state (“trade $1000 USDC for as much ETH as possible”).

A real-life version of an intent vs. a transaction.

From a user’s perspective, intents are typically initiated by signing a message that declares their desired outcome. Once signed, any third party—usually called a solver—can execute the intent. Intents provide several distinct advantages for end users:

  1. Revert-Free Guarantee: A Uniswap transaction can fail due to high slippage or insufficient gas, yet the user will still pay gas fees for the failed transaction. With intents, transactions only land onchain if successfully executed.
  2. Abstracted Optimization: Users don’t need to worry about finding the best place to swap or getting front-run. They simply submit an intent, and a solver will execute it optimally.
  3. Chain Abstraction: Users can sign a single message to transfer assets, without manually bridging across chains. Intents can operate across multiple chains, and users can even allowlist or blocklist certain chains.
  4. No Gas Fees: Users don’t need to hold a chain’s native asset or worry about paying gas fees. Solvers handle gas and take their fees in an asset the user already holds.
  5. Conditional Execution: Intents are often jokingly called a rebrand of limit orders. For example, a user can set an intent to swap USDC for ETH only if ETH hits $2500.
Differences between an Ethereum transaction and an Anoma intent. From Delphi Digital’s WTF Is Anoma? Part 1: WTF Are Intents?
Differences between an Ethereum transaction and an Anoma intent. From Delphi Digital’s WTF Is Anoma? Part 1: WTF Are Intents?

Flow of an intent

Let’s walk through the flow of an intent in the real world using CoW Swap, an exchange that batches user trades for better execution. CoW Swap is one of the most widely used intent-based apps. Here’s how it works:

  1. Users express intents: Users share their limit orders as signed messages to CoW Swap.
  2. Protocol shares intents: CoW Swap collects these intents and shares the aggregate with solvers, aiming to find the best overall execution for traders.
  3. Solvers compete on intents: Solvers run algorithms to determine the best execution. They look for a coincidence of wants—where two opposing trades, like buying ETH with USDC and selling ETH for USDC, cancel each other out—and they route to both onchain and offchain liquidity sources. Solvers then submit their bids to CoW Swap within the allocated time.
  4. Solver settles intents: CoW Swap selects the winning bid and alerts the solver. The winning solver settles all intents in a single transaction.
A visual representation of the flow of intents in CoW Swap. From CoW Swap’s docs.

Overall, CoW Swap delivers many of the key benefits of intents and saves costs by batching orders. However, its atomic settlement only works within a single chain. What happens when we extend intents to cross-chain bridging and swapping?

Cross-chain intents

Cross-chain intents introduce two major challenges: asynchronicity and non-atomicity. When executing an intent across chains, each chain is unaware of the other’s state. Unlike a single-chain transaction, where actions can be bundled into one atomic step, cross-chain transactions must rely on two separate actions—locking collateral on the origin chain and executing on the destination chain—which cannot be combined into a single transaction.

This lack of atomicity introduces risk for solvers. In theory, solvers should wait until the user’s collateral is finalized on the origin chain. In practice, however, users demand speed, and solvers take on the risk of executing on the destination chain before finalization. This means solvers must rely on their own capital and are vulnerable to origin chain reorgs.

How Across solves cross-chain intents

We can best understand cross-chain intents by examining Across, an intents-based bridging protocol that consistently offers some of the fastest settlement times. Here’s how their system works, with the new steps that address the challenges of cross-chain intents:

  1. User expresses intents: The user shares their order as a signed message with Across.
  2. Protocol locks user collateral: Across locks the user’s collateral on the origin chain. Because payment will occur on another chain, the transaction is not atomic. Locking this collateral ensures Across can repay the solver (called a “relayer” by Across).
  3. Protocol shares intents: The transaction that locks the user’s collateral also broadcasts the intent to solvers, who monitor the origin chain for opportunities.
  4. Solvers compete on intents: Solvers race to settle the intent. Currently, Across has fixed fees, and solvers compete on speed.
  5. Solver settles intents: Solver pays user on the destination chain.
  6. Protocol repays solver: Once the intent is fulfilled, Across repays the solver on the origin chain after a challenge period. If no challenge is made, the locked collateral is released. (Across also enables solvers to be repaid on any chain they specify, via maintained LP pools.)
Full flow of intents in Across. The exact process (and the numbering) differ because I simplified the explanation for this article. From Across v3’s docs.

While Across’s design is fast, it comes with trade-offs. The added complexity (steps 2+6) comes from the non-atomicity of cross-chain transactions. Users need to lock their capital on the origin chain, which costs gas. Solvers need to wait before getting repaid, which decreases capital efficiency. Even with these constraints, Across solvers typically fulfill orders in under a minute.

Upgrading cross-chain intents with AVSs

While users earn rewards quickly, it takes time for solvers to be repaid. We can expedite solver repayments by relying on verifiable offchain infra, via EigenLayer AVSs. AVSs allow us to design different cross-chain intent platforms with unique trade-offs.

1. Fast intent verification for solver repayments

Currently, Across pays its solvers after waiting a challenge period. While solvers are waiting to be repaid, they can’t use that capital to fulfill other orders. This decreases the overall capital efficiency of the intents protocol and increases the upfront capital requirements for a solver to be competitive.

We can solve this with a “fast intent verification” AVS. Rather than wait for the challenge period to pass, the EigenLayer operators for the fast intent verification AVS can make a credible commitment that the solver did fulfill the user’s order on the destination chain. Then, Across can pay the solver on the origin chain immediately (in seconds, not an hour).

How the fast intent verification AVS would work, if solvers and AVS operators act honestly.
How the fast intent verification would work, if solvers and AVS operators act maliciously.

During the challenge period, anyone can still submit a challenge. If it’s shown that the solver in fact did not pay the user, the operators are slashed for their malicious attestation. These funds are redistributed to the user in a StakeSure-like mechanism.

This design is inspired by fast finality AVSs like AltLayer MACH and Nuffle’s NFFL which cater to optimistic rollups.

At its core, this design shifts capital obligations from active participants to passive ones. Solvers have high cost of capital, whereas AVS operators will have a lower cost of capital. Thus, freeing up solvers’ capital in exchange for locking AVS operators’ capital is net positive.

2. Solver payment before fulfillment

Currently, Across locks user funds on the origin chain, the solver pays the user on the destination chain, and then Across pays the user on the origin chain. These three steps all require gas.

Theoretically, we could simplify this to two steps:

  1. User pays solver on the origin chain.
  2. Solver pays user on the destination chain.
How the solver payment before fulfillment AVS would work, if solvers act honestly. Solvers are also EigenLayer operators.

However, this requires us to trust the solver to fulfill their end of the bargain. If the solvers register as EigenLayer operators, they can be cryptoeconomically trusted. If they fail to pay the user within predefined criteria, the solvers can be slashed, and slashed funds will be redistributed to the user.

How the solver payment before fulfillment AVS would work, if solvers act maliciously. Solvers are also EigenLayer operators.

Importantly, there’s a limit to how much these solvers can be trusted. Assuming a 1 hour challenge period, solvers’ rolling 60-minute limit must be ≤ their slashable amount for this AVS.

Relay Protocol is building a gas-efficient intents-based bridge with this design.

Conclusion

Intent-based applications are already live on Ethereum today. We’re strong believers that we can create more efficient, user-friendly experiences with Actively Validated Services. If you’re building in intents, join the BuildOnEigen telegram chat, and reach out to our Head of Developer Relations Nader or the author Ishaan.

Stay tuned for part 2, where we discuss the future of intents.