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 hold the potential to transform how we interact with Ethereum, yet today, they risk creating fragmented “walled gardens” where each intent-based application exists in isolation. Rather than isolated ecosystems, we need invisible gardens — a landscape where intent-based applications interconnect and interact fluidly, because composability matters.

In Part 1, we introduced intents and explored how AVSs (Actively Validated Services) enhance them across single and cross-chain contexts. Now, we’ll dive deeper, examining how intent-based applications can inadvertently lead to fragmentation — and how AVSs, through a Modular Intent Stack, unlock the power of fusion across the broader ecosystem.

Intent fragmentation

CoW Swap and Across are incredible examples of intent-based apps, as are UniswapX, OpenSea, Blur, dYdX, and DEX aggregators like 1inch and Matcha. Intents are inherently user-centric and platform-agnostic, so, in theory, these applications should be composable.

However, the surrounding solving infrastructure — the systems that determine how intents are shared with solvers and how solvers compete to fulfill them — is currently app-specific. This creates intent fragmentation, where each intent-based app exists in isolation.

To better understand this fragmentation, let’s double click into how CoW Swap collects intents and shares intents with solvers. CoW Swap currently maintains a centralized orderbook to host user orders. While anyone can call the orderbook’s API, this setup creates a single point of potential failure or censorship. Further, CoW Swap runs a centralized engine to conduct auctions and store solvers’ bids.

This isn’t a critique of CoW Swap (progressive decentralization is a good thing, actually). Rather, it highlights issues that we can collectively work towards solving (pun not intended):

1. Low-latency, censorship-resistant environments: Intents need a fast, resilient space to propagate to solvers without risk of censorship.
2. Unified integration for solvers: Solvers need a single, standardized interface for viewing intents. Currently, CoW Swap requires solvers to integrate a custom driver for its interface. While functional, this approach doesn’t scale across multiple applications.

Put more eloquently, “intent-based apps don’t scale, intents do.” All that’s missing is the solving infrastructure to unlock their potential.

Modular Intent Stack

To scale intents beyond isolated applications, we need a shared process to guide intents from a user’s wallet all the way to execution. This requires three essential components:

1. Representation: Ways to represent intents across applications, either through standards or a full specification language.
2. Propagation: Methods to share intents across solvers.
3. Selection: Processes to choose the winning solver to settle an intent.

I call this the Modular Intent Stack.

ERC-7683: representing cross-chain intents

Intents have far more degrees of freedom than standard, ready-to-execute transactions. By converging on common standards to share intents, intent-based applications could enable solvers to integrate seamlessly across platforms rather than requiring individual integration with each app. This unified approach creates a stronger, more resilient solver network, ultimately benefiting users.

Interestingly, this also shifts competitive focus: instead of competing to maintain exclusive solver networks, applications can focus on enhancing other layers of the stack.

Across and Uniswap Labs took a pragmatic approach, partnering to propose ERC-7683, a standard for cross chain intents. Just as ERC-20 defines a standard for fungible tokens, ERC-7683 lays out common requirements for all cross-chain intents. ERC-7683 sets a standard flow but leaves implementation details flexible.

Across and Uniswap’s approach is bottom-up: it starts with the existing Ethereum and rollup ecosystems, extends with Across’s bridge and UniswapX, and proposes a standard that others can build on while maintaining composability.

Alternatively, intents could be represented with a full specification language, providing more flexibility but adding significant complexity. We’ll discuss solutions that adopt this approach in Part 3.

IntentPool: storing and propagating intents

Aligning on a common standard is not enough. We also need a common decentralized network to transmit intents for solvers to access and settle. This is critical to decentralize the solver selection process and ensure censorship resistance of intents.

So, what does the intentpool look like?

Before diving in, let’s outline our goals an intentpool:

• Censorship resistant for both users submitting intents and solvers submitting solutions
• Low latency to ensure quick access for both users and solvers
• Denial-of-service resistance to protect against attacks

Current approach: centralized database

Currently, intent-based applications like CoW Swap and UniswapX maintain centralized databases to store intents and provide read access to (often whitelisted) solvers. While functional, this approach is neither censorship-resistant nor sustainable.

New approach 1: repurposing the Ethereum mempool

Transactions and intents share similar requirements. In Ethereum, transactions propagate through a network of validators, who add them to blocks when selected as block proposers (either directly or with help from a builder). Validators maintain local mempools and gossip transactions to the network within 1-2 seconds, creating a censorship-resistant network for Ethereum transactions.

If the Ethereum mempool works so well for transactions, why not adapt it to also support intent propagation?

This approach works well in certain cases, specifically when an intent is combined with a gas-required transaction and is low MEV. Across, for example, uses the Ethereum mempool to transmit its intents to solvers. Users pay gas to lock up their collateral, and because the intent is simply to bridge assets between chains, it’s low MEV and doesn’t present an attractive target for manipulation.

However, repurposing the Ethereum mempool isn’t feasible for intents in the general case, primarily due to DOS risks. For transactions, gas serves as a natural deterrent, preventing malicious attackers from attempting to DOS the network. Supporting gasless intents would require Ethereum nodes to validate that intents are solvable before forwarding them, which is a heavy burden, especially given that most node operators are not involved in solving. Forwarding intents without validation would simply enable malicious attackers to send spam intents, overloading the network.

Intents have far more degrees of freedom than transactions, and handling this complexity would severely strain Ethereum nodes without relying on a trusted party or restrictive limitations on intent functionality. As Georgios and Quintus note, “generic support for fully general intents in the Ethereum mempool is out of the question even in the long term.”

New approach 2: let solvers propagate intents

While the mempool mechanism works well, intents often require more complex validation and thus higher bandwidth than general-purpose Ethereum validators can provide. What if we let solvers propagate intents?

This approach, however, introduces new risks of censorship. The mempool relies on nodes openly sharing transactions across the network, but many intents hold inherent profitability for the solvers who execute them. This incentive can lead solvers to keep high-value intents private, limiting broader access and undermining censorship resistance.

New approach 3: store intents on a low-latency data availability network

The previous methods relied on node propagation networks, which work well for transactions but are less suited for intents due to the more complex validation required. The current approach uses a centralized server-client architecture, where a servr acts as a repository for intents, storing and organizing them until solvers (clients) request access. But what if we could retain this server-client model while decentralizing the server itself?

One solution for an intentpool is to use a low-latency data availability (DA) network to store intents. DA networks are purpose-built to ensure that all posted data is accessible to all participants (read: censorship resistance) through decentralized storage and data redundancy. Further, EigenDA in particular has significant excess capacity (see the “All chains fit on EigenDA” stunt).

EigenDA has two active concerns:

• Centralized data dispersal: Currently, EigenDA only supports data posting from a centralized disperser. While the architecture is designed to eventually allow anyone to disperse data (or intents) to the network, this feature is not yet live. Even so, while write access remains permissioned, read access is fully censorship-resistant, offering meaningful improvement over the current centralized approach.
• Latency requirements: For optimal execution, intents need sub-second latency, which remains a challenge. Reducing latency is actively being worked on to meet the demands of high-frequency intent execution.

Both concerns will be addressed. In the long run, I envision low-latency DA networks serving as the “public mempool” for intents.

Use case: CoW Swap and UniswapX with EigenDA

CoW Swap and UniswapX are ideal candidates for using a low-latency DA network like EigenDA to store intents. Both currently store user intents and solver bids (or bid representations via scoring) in a centralized database. Since they follow the client-server architecture for intent dissemination, it’ll be a natural upgrade for solvers with minimal uplift.

Further, once EigenDA’s concerns are solved, CoW Swap and UniswapX will have a strictly better solution:

• Censorship resistance: Users wouldn’t have to rely solely on CoW Swap and UniswapX to publish intents. If either platform chooses to censor (whether directly or due to regulatory pressures), users could publish intents to EigenDA independently.
• Consistency for solvers: Solvers would receive a unified, consistent view of intents, ensuring a level playing field. This is especially important for CoW Swap’s batched swaps, where uniform access to intents is crucial.
• Verifiable best execution: Users could verify that they achieved best execution by comparing all solver bids stored on EigenDA, adding a layer of transparency.

Overall, CoW Swap and UniswapX can pair with EigenDA to build towards a more verifiable, intents-based future.

Auction AVS: selecting a solver

Building on the benefits of a decentralized intent store with EigenDA, we also need a fair, transparent way to select solvers to execute these intents. There are several ways to determine which solver wins an intent — ranging from RFQs, where solvers compete based on speed alone, to price-based auctions.

Currently, most protocols host solver bids and select the winning solver bid via a centralized auction, which carries risks of censorship or manipulation. However, protocols can leverage an Auction AVS to conduct censorship-resistant auctions, ensuring the best bid is chosen without centralized oversight.

As protocols move toward decentralized storage and propagation of intents, a censorship-resistant auction layer powered by an Auction AVS provides the final step to a fully decentralized, fair, and verifiable intent-based architecture.

Conclusion

Intents offer a powerful new paradigm for interacting with decentralized systems, but they risk fragmentation across isolated applications. Actively Validated Services like EigenDA and Auction AVSs created the shared solving infrastructure needed to fuse intents into a unified, interoperable ecosystem.

If you’re building in intents and want to join us in building an invisible garden, start here, join the BuildOnEigen telegram chat, follow along at @buildoneigen on X and reach out to our Head of Developer Relations Nader or the author Ishaan.

In the final part, we’ll discuss next-generation architectures that supercharge intents via composable solving.

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.