WTF Is Anoma? Part 2: WTF Are Intent-Based Apps?

Part 2 – Applications

In Part 1 we have overviewed Anoma’s intents and seen how they compare to Ethereum-style txs & smart contracts.

As a refresher, the goal of intents & predicates is fundamentally different from that of smart contracts & txs. While the former is designed for declarative programming the latter is designed for imperative programming. In this part, we shift our focus to the application layer.

However, before moving further we share a key realization: 

While designed for different purposes, intents & predicates and tx & smart contracts are equivalent in *theoretical* power. They can be used to emulate each other. After all, EVM is a Turing-Complete machine and anything can be built on it.

Indeed, if we largely define intent-based apps as “apps where users express their preferences and allow third-party permissionless agents to fulfill them”, we quickly realize that many of today’s apps in Ethereum and other ecosystems can already be considered intent-based. 

“Part 2: WTF are intent-based apps?” has 2 sections;

1. First, we take a look at some existing intent-based apps across various verticals that fit into the broad definition mentioned above. We’ll walk through these apps, some in more detail than others, to get a sense of their intent-based traits as well as market size & user traction
2. Next, we argue that emulating intent-based apps with smart contracts & txs is sub-optimal, highlighting some of the prevalent drawbacks and inefficiencies of existing dapps.

Intent-Based Apps Are Already Here

App	Vertical
Safe / Argent	Smart Contract Wallets (ERC 4337)
Across	Bridges
Arbitrum / Optimism	Rollups
SUAVE	MEV
Li.Fi / Socket	Aggregators
OpenSea / Blur	NFT Marketplaces
CoWSwap / 1inch Fusion	DEX (Spot)
dYdX	DEX (Derivatives)

 

CoW Swap & 1inch Fusion

CoWSwap & 1inch Fusion are the two apps that, design-wise, are perhaps the closest examples of what trading apps on Anoma might look like. 

CowSwap is a protocol that trades via batch auctions and has a competitive marketplace of solvers competing to find the winning batch using their own unique strategies. Orders on CowSwap are crafted as intended. Solvers may execute these trades in part directly against each other off-chain via coincidence of wants (CoW) and in part by finding the optimal path to execute them against on-chain liquidity pools. While it may sound complex, the architecture is quite simple.

1. Users send their intents to the CoWSwap order book. For example, “I want to sell 2,000 USDC for at least 1 ETH”. Notice the “at least” here. The user is willing to accept 1 ETH, but would prefer higher if a solver can make it happen.
2. User orders are consolidated in the orderbook before being sent to the Driver who acts as the auctioneer. The driver initiates the auction and sends the trades to the solvers. Both the orderbook and driver are centralized components of the CoWSwap architecture that are yet to be decentralized.
3. Solvers compete to create a solution to a batch maximizing the total surplus for users (where surplus = execution price – limit price). Solvers send their results back to the driver who then sorts and ranks them.
4. Driver settles the winning batch on-chain.

For the solvers, it’s a winner-take-all auction. There’s no partial filling and sharing between solvers, you either have the winning batch or you do not. Solvers can use any liquidity source or strategy to complete the winning batch. This means using liquidity pools across Ethereum, flash loans, using their own inventory, and even (while somewhat undesirable) private orderflows. But where the CoW design really shines through is when we have a coincidence of wants between users. When you have a CoW you don’t need a pool, with users just matching between themselves.

To illustrate, we look at the order below from May 1st. Two users came to CoW Swap with intents that almost entirely overlapped. 

1. User 0xea wanted to sell 48,942 USDC and receive at least 26.66 ETH. They were willing to buy ETH up to a market price of $1,836/ETH
2. User 0x85 wanted to sell 30 ETH and receive at least 53,833 USDC. They were willing to sell ETH down to a market price of $1,794/ETH
3. The entire batch was able to be solved by crossing the user intents and filling the remaining balance of the trade for user 0x85 through a liquidity pool

The result is that both users got price improvement on where they were willing to trade. 0xea was able to buy ETH at $1,829/ETH and 0x85 was able to sell at $1,827/ETH. When CoWs are matched like this there’s no slippage or front-running to be concerned about. There is also no need to pay expensive gas fees to “stop the whole Ethereum blockchain” to have the chain execute orders one at a time, each incurring slippage in the process by buying up or selling down the curve.

While this batch highlights the benefits of how intents can be used, the challenge for CowSwap is that they live in an imperative ecosystem. The Ethereum mempool does not support the intent structure so CoW Swap has to develop and maintain their own off-chain architecture instead. It’s also reliant on users actually going through CoW Swap’s contracts/front-end as they don’t have access to intents from all Ethereum traders. Traders need to go use CoW Swap specifically. If CoW Swap was built in a declarative ecosystem their solvers would be able to tap into the generalized intent mempool and have access to a much wider supply of intents and in turn, be able to find more coincidence of wants and solvable ring trades. As a result, there are very few actual CoW’s on CoW Swap today, with CoW’s typically making up <1% of daily volume.

 With that being said, even without CoWs users can still get better execution on CoW Swap through the batching of like trades. If multiple users want to go through the same pool/assets then a solver can execute them in one batch, saving on gas and settling at a uniform price. These batches are sent as what is essentially a partial block to builders in a “fill or kill” manner. As the batches can include a significant amount of a block, builders are incentivized to include the batch.

When CoW Swap started the majority of the batches that won were actually by DEX aggregators like 1inch. CoW Swap has a 1inch API and their routing algo was able to win the majority of single trades without any actual effort on 1inch’s end. As time has gone on, solvers have entered who have been better at solving larger batches, and 1inch and other aggregators’ share has continued to decline. In April of 2022, solving was dominated by aggregators like 1inch, 0x, CoW’s aggregator, and paraswap. Today, it’s dominated by professional solvers like Barter, Otex, Laertes, Seasolver and more. We expect this trend to continue as solving becomes the game in town and where the majority of value in blockchains will accrue.

This did not go unnoticed by 1inch, however, and they responded by designing their own similar architecture in 1inch Fusion. Fusion is similar to CoW Swap, the main difference being that Fusion utilizes Dutch auctions vs. CoW Swap’s Single Block Batch Auctions. In Fusion, users sign off-chain orders (intents) which are then sent to a network of solvers who can fill the Dutch auction at any time. In a Dutch Auction, prices start high and then decline over time. The user here is the maker, and the first solver to take the order wins it. 1inch helps users craft these intents, automatically presenting them with an intent to sign based on prices from their DEX aggregator. Users can sign the auto intent, use another format or even create a custom one, with max, min, and time of auction configurations up to the user’s desire. Like CoW Swap, if two intents have a coincidence of wants they can be matched directly without going through liquidity pools.

Fusion went live at the end of 2022 and has become a larger part of 1inch’s volume since, now sitting at ~15% of the total 1inch volume. Part of the reason for this is that 1inch already has a large user base to tap into and Fusion defaults on their front-end. Another is the increased diversification and competition of solvers covering a larger part of on-chain liquidity.

Like CoW Swap, Fusion solving is a competitive game. While it started with just 1inch labs for the first few months, it has since been opened up. Some of these names overlap with CoW Swap as solvers look to compete in both domains. As we’ve said, we expect solving to become one of the most competitive games in the long run where value will accrue and 1inch’s switch to the Fusion model highlights this thesis well.

UniswapX

Recently announced at ETHCC, UniswapX is another signal that the industry is moving more towards this off-chain execution with an on-chain settlement model. UniswapX allows users to sign intents (e.g., swap 1 ETH for 2,000 USDC) and then have sophisticated fillers (AKA solvers, market makers, searchers) fill their order off-chain and settle them on-chain. This is a substantially different model from the Uniswap AMM, where users sign execution paths to swap through on-chain AMM pools. With UniswapX, users don’t go through AMMs, at least not themselves. Their orders are routed directly to fillers that utilize both on-chain (AMMs) and off-chain (CEXs, EOF) methods which compete to execute their trade in a Dutch auction.

The Dutch auction mechanism is similar to 1inch Fusion where fillers can execute at a higher price which declines to the user’s low limit over time. Crucially, and most importantly, UniswapX is agnostic to the method of execution the filler uses. They can swap through Uniswap pools, Balancer pools, Curve pools, aggregators, or even use their own inventory while hedging on centralized exchanges. It is entirely possible for a user to come to Uniswap’s front-end and have their order settled using entirely off-chain liquidity from centralized exchanges.

Also included in UniswapX will be an RFQ (request for quote) model with whitelisted quoters (with aims to be permissionless later). Users can receive quotes from these whitelisted entities (professional market makers) that they can accept to get filled on-chain. In both the Dutch auction and RFQ model, no on-chain liquidity is needed to fill an order, which in some aspects makes Uniswap a front-end for centralized exchange liquidity.

The other, maybe more exciting angle to UniswapX is the cross-chain swap functionality. UniswapX will allow users to, for example, swap ETH on Ethereum for AVAX on Avalanche, or MATIC on Polygon. Users will no longer need to go ETH on Ethereum → ETH on Polygon → swap ETH for MATIC on Polygon. They can have a filler complete the entire process on their behalf, reducing the operational steps in the process. In turn, this can have the effect of less idle native assets held in bridges, potentially resulting in smaller honeypots for exploits.

dYdX

While we’ve explained how intents are not just limit orders, then can of course be just limit orders, if that’s their intention. When we think of orderbook-based DEXs in crypto we think of dYdX. dYdX has stood alone (although with increasing competition) in the derivatives space and accounted for 63% of derivatives DEX volume over the past year.

Compared to spot exchanges or some of the other derivatives DEX’s, dYdX’s orderbook-based model is capital efficient, routinely turning over >2x their TVL on a daily basis. Limit orders as a tool for counterparty and price discovery require less idle/unutilized capital than alternatives and we would expect more DEX trading to move to this mode (for liquid non-stable pairs) as the infrastructure to support it improves.

The tradeoff to building an appchain of course is the time it takes to develop. dYdX has spent more than a year developing its standalone appchain and it has taken significant resources and efforts to make the transition. And while dYdX has dominated DEXs, it pales in comparison to the CEX volumes from the likes of Binance, OKX, and Bybit. Crypto traders clearly prefer this model, we just don’t have the infrastructure to support it on-chain. Anoma gives every application the ability to support limit orders by default.

OpenSea / Blur

NFT Marketplace apps like Opensea and Blur use the same permissionless Seaport protocol to match & settle orders on-chain. Seaport is amongst the most widely adopted protocols in crypto. In 2022, the Seaport contract has been the third most gas-consuming contract on Ethereum. 

Seaport’s architecture carries many similarities with Anoma. This is of no coincidence as it’s design is heavily influenced by it’s ancestor Wyvern; a protocol originally developed by a member of the core Anoma team.

A Seaport order consists of, amongst other things, an “offer” and a “consideration”. Offer is an array of “items” an offerer is willing to give up in exchange for the “consideration”; an array of items with named recipients. Items can consist of both fungible and non-fungible tokens.

Unless specified otherwise by the application, anyone can fulfill an order. Fulfillment happens atomically; offer items are accepted if and only if consideration items are transferred to their named recipients. 

Much like Anoma intents, Seaport orders can be matched with other compatible orders w/o the need for a global order of execution. Orders can be surfaced off-chain; users don’t have to spend gas to place an order, just have to sign it. 

Typically, order discovery is facilitated through centralized servers of user-facing applications like OpenSea and Blur. These applications, help users craft their orders in correct syntax and as they intended. They also facilitate counterparty discovery through their centralized APIs.

Seaport fulfillers are akin to Anoma solvers. They can fulfill orders in many ways. They can bring their own liquidity to become a direct counterparty or find CoWs amongst active orders and settle them atomically. They can also partially fill orders if the order allows them to. The bottom line is the path isn’t important. As long as all the consideration items in involved orders are sent to their respective recipients, all offer items can be collected. 

The expressivity of a Seaport order can be extended through “zones”. Zones are external accounts (typically smart contracts) that users can optionally specify to assert certain restrictions to their orders. Such restricted orders can only be fulfilled if they adhere to their zone’s validation rules. Zones can extend Seaport’s use cases. For example, they can be used to place orders for a particular class of NFTs with custom traits, implement fancy auction mechanics on order fulfillment, white/blacklisting collections or fulfillers, etc.

Notice how Zones are similar to Anoma predicates. Just like predicates, they get to have the final say on order fulfillment. They check if order fulfillment satisfies their constraints and return a boolean; giving a thumbs up or down for settlement. 

Li.Fi / Socket

In DEX / Bridge aggregators such as Li.Fi and Socket, users sign and send their bridge and/or swap to intent to a centralized server. The server then checks the latest on-chain state and runs an algorithm to find the optimal execution path based on the liquidity available on DEXs and the bridges they support. Once it finds a solution, it crafts and prompts the user with a valid tx reflecting this solution. The user then can sign the tx to execute it on-chain. 

As can be inferred, the optimal path is computed off-chain. This is expected as the amount of data and computation these servers process would be completely infeasible to run on-chain via smart contracts. Furthermore, aggregators retain their competitive edge by using closed-source proprietary algorithms.

Off-chain solving enables aggregators to optimize paths and offer competitive rates. As a result, a substantial amount of cross-chain bridge volume today goes through bridge aggregators. 

Across

Cross-chain bridges are by default intent based. Commonly users express their cross-domain swap or bridge intent (e.g. [token type, token amount, dest chain, dest addr, fees] etc.) by placing a tx on the origin chain and rely on third party agents to execute the second leg of the exchange at the destination chain. 

Across is a bridge focused on Ethereum L2s and rollups. It has 2 modes of operation; fast and slow. Under fast mode, users don’t interact with an on-chain liquidity pool. The exchange is p2p between the relayer and the user. Users’ bridge intents are fulfilled via a permissionless set of relayers who watch incoming txs in the origin chain and quickly provide users with tokens at the destination chain. Relayers only use the on-chain liquidity pool after fact to rebalance their inventory. 

Across has an optimistic settlement mechanism. Once the relay is done, relayers submit proofs of the relay to UMA’s (fraud proof based) optimistic oracle for settlement. Upon oracle’s verification, they get compensated for their services on the origin chain. 

Across’ fast fill mode is known to be the fastest bridge option, with users typically receiving their desired tokens at their destination in ~1 min. This is thanks to high competition amongst relayers. Relayers compete with each other to be the first to fulfill user intents, assuming risks of re-org, cost of capital, software bugs etc. Alternatively, users can always fallback to slow fill mode and directly interact with an on-chain pool. This might be desired in cases where user’s intent is being censored by relayers for whatever reason.

ERC 4337 / AA

The ERC4337 standard also squarely fits into the intent discourse. ERC 4337’s main purpose is to improve UX.

The single biggest limitation of smart contracts wallets on Ethereum is that they can’t initiate txs on their own. Users have to own EOAs to initiate tx and operate their smart contract wallet. Practically this means smart contract wallets always rely on EOAs and therefore can never be first-class citizens.

ERC 4337 abstracts the complexity of operating a smart contract wallet away from the user by adding a new “user intent layer” upstream/on top of the existing transaction flow.  

Instead of the user flow starting with users signing valid Ethereum txs, users sign a new user action called “user operation” (in short userOp). Formally, userOps are like normal Ethereum tx, except their nonce and signature fields aren’t defined by the protocol. This allows users to generate them w/o an EOA. Users send their userOps to a separate userOps mempool where they get gossipped and picked up by “bundlers” who fulfill the role of an EOA and execute them on-chain on behalf of users. 

The protocol has additional components such as the EntryPoint contract to prevent DoS vectors, userOps aggregation for gas optimizations, and paymasters for gas sponsorship, but this is the gist of it.

Note that ERC 4337 makes no protocol-level changes. From the perspective of the Ethereum protocol, it’s still EOAs invoking smart contracts. The tx submitted by the bunder is identical in format to any other Ethereum tx. 

While ERC 4337 is a standard (and not an app) it’s not designed to be very generic. It primarily focused on smart contract wallets; particularly on a number of features that have been desperately needed such as gasless / gas-sponsored txs, multi-sigs, spending limits, session keys, etc. 

As of today, ERC 4337 adoption on Ethereum is negligible compared to overall user activity yet it’s still the early days. 

Arbitrum / Optimism

In an EVM rollup such as Arbitrum and Optimism, users sign fully fledged tx, authorizing an execution path. In this sense, these rollups are quite different from how an intent-based application on Anoma would look like. That said, if we squint, we can also acknowledge some similarities between rollups and intent-based apps. 

For example, in rollups, counterparty discovery (which just means tx ordering in this special case) is facilitated off-chain through (centralized) sequencer(s), who then submit a batch of txs to a rollup settlement contract which settles them atomically. The settlement contract can be argued to emulate the role of a predicate as it’s purpose is verification and not execution.

Why Anoma?

The TLDR takeaway here is that many powerful applications today are already intent-based. The wide adoption of these apps encourages us to think that intents are the right abstraction for users. In addition to existing user traction, current efforts on ERC 4337, SUAVE, CoWSwap Hooks can be seen as early signs of a broader trend to generalize intents. 

The question now becomes where does Anoma fit into this picture? Or more specifically, what is Anoma’s unique value proposition? To answer this question we reflect back on our findings and walk through the limitations faced by these apps to understand what value Anoma is set to bring. 

Centralized / Fragmented Counterparty Discovery

While some of these apps rely on centralized servers others build out their own distributed solutions. Generally speaking, the decision here may not impact safety (cross-domain apps being an important exception) but drastically changes liveness assumptions. 

Opensea is a prime example of an app that facilitates CD via its centralized server. While OpenSea’s server can’t steal funds or tamper signed orders it can trivially censor them. Indeed, it’s common for OpenSea to censor certain types of orders either due to regulatory concerns or business-related motivations.

In the second camp lies some exceptionally ambitious teams such as CoWSwap, Arbitrum / Optimism, and dYdX. Building out a distributed network for CD and solving requires progressive decentralization with multi-year roadmaps. This naturally slows down the rate of innovation at the application layer.

Crucially, as apps move CD and solving to their custom siloed off-chain networks, they give up composability at the intent layer. CoWSwap, 1inch Fusion, and OpenSea, despite all being trading applications, all have non-overlapping “intent” pools. As such, solvers of these applications miss out on aggregation and matching opportunities that would otherwise result in gas & slippage savings. 

Fragmentation also kills network effects when bootstrapping the supply side of the network. Intent networks rely on solvers competing against each other to solve intents in exchange for fees. The more intents gossipped, the more incentives there are for new solvers to join the network, which is key to improving the execution quality of user intents. 

Put another way, “intent-specific apps don’t scale. intents do.” 

Anoma’s vision is to build out a global intent gossip network where nodes can observe and process intents across many apps. The architecture allows intents to easily compose with each other at the intent layer, before even hitting the on-chain settlement layer. 

The Anoma intent network is sparse; not all nodes observe all intents. Nodes are expected to subscribe and listen to a subset of intents of their interest. There will be a natural tendency for nodes to subscribe to intents that are likely to be compatible with each other. As market dynamics change over time, nodes may unsubscribe from certain types of intents and subscribe to new ones. 

Domain Abstraction

Ideally, we want intents to utilize the same architecture, regardless of which application they belong to or domain they get settled on. This leads us to Anoma’s second design principle; homogeneous architecture, heterogenous security! 

Existing intent-based apps have programming languages and tx semantics tied to the underlying VMs. In a heterogenous multi-chain world this implies that nodes in CD and solving network have to parse and interpret intents based on their VM. Anoma, on the other hand, is language neutral; the intent format and semantics are decoupled from VMs of the underlying settlement layers. 

The goal here is to abstract intents away from the settlement layer. The Anoma architecture doesn’t really care where intents get settled. Intents may want to settle on any blockchain or even a centralized server. This is left out as a user/application choice.

This doesn’t mean intents magically solve inherent limitations of cross-domain communication. Intents are bound by the same cross-chain risks such as finality risk, trusted counterparties, etc.

However, intents have the potential to drastically improve the UX. In an intent-centric future, users may never have to directly interact with a cross-chain bridge. They can instead fully rely on solvers who assume and price these risks. This can be a more appealing tradeoff for the vast majority of users. 

While intents alone don’t remove any cross-chain risks, Typhon – a major component of the Anoma architecture – is quite special in this regard. Typhon promises a novel way for independent chains to atomically communicate, reducing the risks of cross-chain communication. We will dive into Typhon in Part 3, the final part of this series.

Emulation Is Inefficient

The intent-based apps we’ve overviewed have been emulated on top of imperative architectures. This leads to a number of notable inefficiencies. 

1. Txs and smart contracts are fundamentally expensive and inefficient tools to express intents. First off, txs are put in a total order which is often unnecessary. If you want to sell an NFT and I want to purchase a username on a name service, we shouldn’t really care how our txs are ordered with respect to each other. When we use txs and smart contracts to express our intent we are overpaying for a total global order which we don’t really need.
2. When using smart contracts to express intent (like a smart contract wallet or a Seaport zone), we first have to pay to store the code on-chain before we can run it, which is once again quite expensive. With Anoma, in most cases, the intent logic can be coded at runtime as stateless predicates, which dramatically reduces the costs of execution.
3. In an imperative world, developers assume the role and motivations of different participants (lenders and borrowers, LPs and swappers, etc.) of an application, encode them as a smart contract, and deploy it on-chain. Roles of counterparties are therefore known even before they get to engage with each other. This restricts the future behavior of participants and limits their ability to adapt to changing market conditions. Iterations in-app logic often require deployments of new versions of the application, with users migrating their liquidity from one version to another. In contrast, an application dev on Anoma doesn’t need to predict the roles and motivations of counterparties in the future. Intents are ephemeral expressions and can be easily adapted to change the application logic in the face of changing market conditions.
4. Another inefficiency of imperative execution is that it assumes the signer of a commitment and its performer is the same. For example, in EVM, txs always originate from an EOA. This puts the burden of counterparty discovery on users. For example, a user looking to bridge some tokens is expected to be aware of and compare existing bridges based on liquidity, latency, trust assumptions, etc. This is a dead-end for the vast majority of current and future users.

The bridge aggregators, while a significant improvement on UX, aren’t a panacea. They are still bound by the limitations of an imperative architecture. Even though aggregators compute the optimal execution path off-chain, users have to still know their counterparty a priori; this time the best-performing aggregator app on a particular chain.

The Anoma architecture, from the ground up, decouples the roles of those who sign commitments (users) and those who perform them (solvers). This clear separation enables flexibility for both users and solvers. Users can sign commitments w/o even caring about who their counterparties are/will be and solvers can be selective with which intents they want to process and how they want to process them. Solvers may develop their own competitive strategies and quickly adapt them in the face of changing market conditions.

Information Flow Control

Last but not least, the lack of user ability to control information flow (ie. who gets to see what information) fundamentally limits the use cases that decentralized applications promise today. Privacy is the key to unlocking the use cases to actually bring masses (businesses and retail users) to crypto, yet it still remains a mostly ignored challenge. As we mentioned in Part 1, Anoma’s intent-based architecture enables information flow control at the intent layer. Users can be selective about which nodes in the intent gossip layer can see and process their intents. 

For those interested in a complete overview of the privacy landscape we recommend our “Everybody Needs Privacy” report.

Conclusion

In this part, we have overviewed intent-based apps widely used today and the benefits that the Anoma architecture can provide.  In Part 3, the final part of this series, we will dive into the mysterious world of Typhon and chimera chains and see how Anoma intents may possibly be settled across multiple chains atomically.