DelphiDigital What are the intent-based applications and what makes Anoma unique?

What are intent-based applications and what makes Anoma unique?

Author: Delphi Creative; Translator: LianGuai0xjs

In previous articles, we outlined Anoma’s intentions and looked at how they compare to Ethereum-style transactions and smart contracts.

As a review, the goals of intents and predicates are fundamentally different from the goals of smart contracts and transactions. The former is designed for declarative programming, while the latter is designed for imperative programming. In this article, we will focus on the application layer.

However, before we proceed further, we share a key insight:

• Why is Binance in a hurry to sell its Russian business to a newly launched exchange?
• Variant Partner What are the benefits of bringing RWA onto the chain?
• SEC has been repeatedly ‘losing face’ in cryptocurrency cases. Is it because the US Department of Justice is intentionally balancing its power?

Although designed for different purposes, intents and predicates, as well as transactions and smart contracts, are theoretically equivalent in terms of capabilities. They can be used to simulate each other. After all, the EVM is a Turing-complete machine, and anything can be built on top of it.

In fact, if we roughly define intent-based applications as “applications where users express their preferences and allow third-party agents to implement them without permission,” we will quickly realize that many applications in Ethereum and other ecosystems today can already be considered intent-based.

This article “What Are Intent-Based Applications?” has two parts;

1. First, we take a look at existing intent-based applications across various verticals that fit the broad definition above. We will introduce these applications one by one, some in more detail and some less, to understand their intent-based features as well as their market size and user appeal.

2. Next, we argue that using smart contracts and transactions to simulate intent-based applications is suboptimal, highlighting some major drawbacks and inefficiencies of existing dapps.

What Intent-Based Applications Already Exist?

CoW Swap & 1inch Fusion

CoWSwap and 1inch Fusion are examples of trading applications on Anoma that are closest to its design.

CowSwap is a protocol for trading through batch auctions and has a competitive solver market, where solvers compete using their own unique strategies to find winning batches. Orders on CoWSwap are made based on intents. Solvers can either directly duel each other off-chain through coincidental wishes (CoW) or find the best path to execute these trades in on-chain liquidity pools. Although it may sound complex, the architecture is actually very 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.” Note the “at least” here. Users are willing to accept 1 ETH, but they prefer higher if the solver can achieve it.

2. User orders are merged in the order book before being sent to the Driver, who acts as an auctioneer. The Driver initiates the auction and sends the trades to the solvers. Both the order book and the Driver are centralized components of the CoWSwap architecture that have not been decentralized yet.

3. Solver competition to create solutions that maximize the total balance of users (where balance = execution price – limit price). The solver sends its results back to the driver, who then sorts and ranks them.

4. The driver settles the winning batch on the chain.

For the solver, this is a winner-takes-all auction. There is no partial filling or sharing, either you have the winning batch or you don’t. Solvers can use any liquidity source or strategy to fulfill the winning batch. This means using any liquidity pool on Ethereum, borrowing from FlashLoans, using their own inventory, or even (although not ideal) using private order flow. But when there is coincidence of wants between users, the CoW design really comes into play. When you have CoW, you don’t need a pool, just matching between users.

For example, let’s look at the orders from May 1st. Two users come to CoW Swap with almost completely overlapping intentions.

1. User 0xea wants to sell 48,942 USDC and receive at least 26.66 ETH. They are willing to buy ETH at a market price of $1,836 per ETH.

2. User 0x85 wants to sell 30 ETH and receive at least 53,833 USDC. They are willing to sell ETH at a market price of $1,794 per ETH.

3. The entire batch can be resolved by cross-matching the intentions of users and filling the remaining balance through a liquidity pool for User 0x85’s transaction.

The result is that both users get price improvements on the prices they are willing to trade. 0xea is able to buy ETH at a price of $1,829 per ETH, while 0x85 is able to sell at a price of $1,827 per ETH. When CoW matches like this, there’s no need to worry about slippage or front-running trades. There’s also no need to pay expensive gas fees to “stop the entire Ethereum blockchain” to have the chain execute orders once, every time generating slippage.

While this batch highlights the benefits of how intentions are used, the challenge for CowSwap is that they exist in an imperative ecosystem. The Ethereum mempool doesn’t support intention structures, so CoW Swap has to develop and maintain its own off-chain architecture. It also relies on users actually interacting with CoW Swap’s contract/front-end as they don’t have access to the intentions of all Ethereum traders. Traders need to specifically use CoW Swap. If CoW Swap were built in a declarative ecosystem, its solver would be able to leverage a generalized intention mempool and have access to a broader supply of intentions, enabling more coincidences of wants and resolvable ring trades. As a result, today there is actually very little CoW on CoW Swap, with CoW typically accounting for less than 1% of daily trading volume.

That being said, even without CoW, users can still achieve better execution on CoW Swap by batching similar trades. If multiple users want to transact through the same pool/asset, the solver can execute them in a batch, saving gas fees and settling at a unified price. These batches are sent to the builder as a “complete or cancel” partial block. Due to the fact that batches can contain quite a few blocks, the builder has an incentive to include that batch.

When CoW Swap started, most of the winning batches were actually won by DEX aggregators like 1inch. CoW Swap has a 1inch API, and its routing algorithm is able to win the majority of individual trades without any actual effort from 1inch. Over time, solvers entered and became better at solving larger batches, while the share of 1inch and other aggregators continued to decline. In April 2022, solvers were predominantly dominated by aggregators like 1inch, 0x, CoW’s aggregator, and LianGuairaswap. Today, it is mainly dominated by professional solvers like Barter, Otex, Laertes, Seasolver, etc. We expect this trend to continue as solving becomes a game for city dwellers and most of the value accumulates in the blockchain.

As solvers become more complex, DEX aggregators lose their share of CoW Swap.

1inch noticed this and responded by designing their own similar architecture called 1inch Fusion. Fusion is similar to CoW Swap, with the main difference being that Fusion uses a Dutch auction while CoW Swap uses a single-block batch auction. In Fusion, users sign off-chain orders (intents) and send them to a solver network that can fill the Dutch auction at any time. In the Dutch auction, the price starts high and decreases over time. Users act as market makers, and the first solver to accept the order wins. 1inch helps users formulate these intents and automatically presents them with a signed intent based on the prices provided by their DEX aggregator. Users can sign automatic intents, use other formats, or even create custom intents based on their desired maximum, minimum, and auction time. Like CoW Swap, if two intents have coinciding desires, they can be matched directly without going through a liquidity pool.

Fusion was launched at the end of 2022 and has since accounted for about 15% of 1inch’s total trading volume. One reason for this is that 1inch already has a large user base to leverage, and Fusion is set as the default on its front end. Another reason is the increased diversity and competition of solvers, which covers a larger portion of on-chain liquidity.

Steady upward trend of 1inch Fusion

Like CoW Swap, Fusion solving is a competitive game. While initially only 1inch labs were involved, it has since been opened up. Some of the names overlap with CoW Swap, as solvers are trying to compete in both areas. As we mentioned, we expect solving to become one of the most fiercely competitive games in the long run, with value accumulating in the blockchain, and 1inch’s switch to the Fusion model illustrates this point well.

1inch’s solving dominated by 1inch and T

UniswapX

UniswapX, announced recently at ETHCC, is another signal of the industry’s development towards more offline execution and on-chain settlement models. UniswapX allows users to sign intentions (e.g., exchange 1 ETH for 2,000 USDC) and then have complex traders (also known as solvers, market makers, searchers) fill their orders off-chain and settle them on-chain. This is different from the Uniswap AMM model, which requires users to sign execution paths and exchange through on-chain AMM pools. In UniswapX, users do not go through AMM, at least not themselves. Their orders are directly routed to fillers who use on-chain (AMM) and off-chain (CEXs, EOF) methods, and these fillers compete to execute their transactions in a Dutch auction.

The Dutch auction mechanism is similar to 1inch Fusion, where fillers can execute at prices that change over time above the user’s lower limit. The key point is that UniswapX is agnostic to the execution methods used by the fillers. They can exchange through Uniswap pools, Balancer pools, Curve pools, aggregators, or even use their own libraries. It is entirely possible for users to come to the front end of Uniswap and settle their orders using fully off-chain liquidity from centralized exchanges.

UniswapX will also include an RFQ (Request for Quote) model, which will involve whitelisted quote providers (which may become permissionless in the future). Users can receive quotes from these whitelisted entities (professional market makers) and accept them to fill their orders on-chain. In the Dutch auction and RFQ models, on-chain liquidity is not required to fill orders, making Uniswap a front end for centralized exchange liquidity in some respects.

Perhaps the most exciting aspect of UniswapX is its cross-chain exchange functionality. UniswapX will allow users to, for example, exchange ETH on Ethereum for AVAX on Avalanche, or exchange MATIC on Polygon for ETH on Ethereum. Users will no longer need to go through the process of converting ETH on Ethereum to ETH on Polygon and then exchanging ETH for MATIC on Polygon. They can have a filler represent them to complete the entire process, reducing operational steps. This could result in a decrease in idle native assets held in bridges, potentially reducing the risk of attacks.

dYdX

While we have explained that intentions are not just limit orders, they can certainly be limit orders. When we think of order book decentralized exchanges (DEXs) in the crypto space, we think of dYdX. In the past year, dYdX has dominated the derivatives space (although competition is increasing) and accounted for 63% of the derivatives DEX trading volume.

Compared to spot exchanges or some other derivatives DEXs, dYdX’s order book model performs well in terms of capital efficiency, with daily trading volume typically exceeding twice its total locked value (TVL). As a counterparty and price discovery tool, limit orders require less idle/unutilized capital, and with improvements to the infrastructure supporting it, we expect more DEX trading to move towards this model (applicable to non-stablecoin pairs with good liquidity).

Of course, the cost of building an application chain is the time required for development. dYdX spent more than a year developing its independent application chain, and the transformation process required a lot of resources and energy. Although dYdX dominates in DEX, its trading volume is still inferior to centralized exchanges such as Binance, OKX, and Bybit. Cryptocurrency traders obviously prefer this model, but we still lack the infrastructure to support this model on-chain. Anoma provides default support for limit orders for each application.

OpenSea / Blur

NFT market applications such as Opensea and Blur use the same permissionless Seaport protocol to match and settle orders on-chain. In 2022, the Seaport contract ranked third among the contracts that consumed the most gas on Ethereum.

Seaport has many similarities with Anoma in terms of structure. This is not a coincidence, as its design was greatly influenced by its predecessor Wyvern, a protocol initially developed by the core team members of Anoma.

Seaport orders include elements such as “offer” and “consideration”. The offer is a set of “items” that the offeror is willing to give up for the “consideration”; these “items” contain named recipients. The items can include fungible and non-fungible tokens.

Unless specified otherwise by the application, anyone can fulfill the order. Fulfillment is atomic; the offer is only accepted when the consideration is transferred to its named recipient.

Similar to Anoma’s intention, Seaport orders can be matched with other compatible orders without the need for global execution order. Orders can be displayed off-chain; users do not need to spend gas to place orders, just sign them.

Typically, order discovery is facilitated by centralized servers of user interface applications, such as OpenSea and Blur. These applications help users formulate orders with correct syntax and expected behavior. They also facilitate the discovery of counterparties through their centralized APIs.

Seaport fulfillers are similar to Anoma’s solvers. They can fulfill orders in many ways. They can provide their own liquidity as direct counterparties, or find matching orders in active orders and atomically settle them. They can also partially fill orders if allowed. Most importantly, the path does not matter. As long as all the consideration items in the order are sent to their respective recipients, all offer items can be collected.

The expressiveness of Seaport orders can be extended through “zones”. A zone is an external account (usually a smart contract) that users can choose to specify to assert certain restrictions on their orders. Only when the fulfillment of the order complies with the validation rules of its zone, can such restricted orders be fulfilled. Zones can expand the use cases of Seaport. For example, they can be used to implement complex auction mechanisms, whitelist/blacklist collections or fulfillers for specific categories of NFT orders with custom features.

Please note that zone and Anoma are similar to predicates. Like predicates, they ultimately have the power to determine the fulfillment of orders. They check whether the fulfillment of orders meets their constraints and return a boolean value; for settlement point or point of praise.

Li.Fi / Socket

In Li.Fi and Socket, as well as other DEX/bridge aggregators, users sign and send their bridge and/or swap intentions to a centralized server. The server then checks the latest status of the chain and runs an algorithm to find the best execution path based on the DEX and bridges they support. Once a solution is found, the server creates and presents the user with a valid transaction reflecting this solution. The user can then sign the transaction and execute it on the chain.

It can be inferred that the optimal path is computed off-chain. This is expected as the data and computation handled by these servers are not feasible to be run on-chain through smart contracts. Additionally, aggregators maintain their competitive advantage by using proprietary closed-source algorithms.

Off-chain computation enables aggregators to optimize paths and provide competitive rates. As a result, most of the transaction volume for cross-chain bridges is now routed through bridge aggregators.

Across

Cross-chain bridges are typically intent-based. Users usually express their cross-swap or bridging intentions by placing transactions on the source chain (e.g., [token type, token amount, target chain, target address, fee]).

Across is a bridge focused on Ethereum L2 and Rollups. It has two modes of operation: fast and slow. In fast mode, users do not interact with on-chain liquidity pools. Swaps are peer-to-peer exchanges between relayers and users. The user’s bridging intentions are facilitated by a set of permissionless relayers who monitor incoming transactions on the source chain and swiftly provide the tokens on the target chain to the user. Relayers only rebalance their inventory using on-chain liquidity pools afterwards.

Across has an optimistic settlement mechanism. After relaying is complete, relayers submit relay proofs to UMA’s (fraud-proof based) optimistic Oracle for settlement. Once verified by the Oracle, they are compensated on the source chain for their services.

Across’s fast mode is considered the fastest bridging option, with users typically receiving their desired tokens in about 1 minute. This is thanks to the high competition among relayers. Relayers compete with each other to be the first to fulfill user intentions, taking on risks such as reordering, capital costs, software errors, etc. Alternatively, users can always fall back to the slow mode and interact directly with on-chain pools. This may be useful when the user’s intentions are subject to review by relayers for some reason.

ERC 4337 / AA

The ERC4337 standard also clearly aligns with intentions. The primary aim of ERC 4337 is to improve user experience.

The biggest limitation of smart contract wallets on Ethereum is that they cannot initiate transactions on their own. Users must possess an EOA to initiate transactions and operate their smart contract wallets. In effect, this means that smart contract wallets always depend on EOAs and can never become first-class products.

ERC 4337 abstracts the complexity of operating smart contract wallets by adding a new “user intention layer” on top of the existing transaction flow. Instead of users signing valid Ethereum transactions, users sign a new user operation called “userOp”. UserOps are similar to normal Ethereum transactions in form, except that their nonce and signature fields are not defined by the protocol. This allows users to generate them without an EOA. Users send their userOps to a separate userOps memory pool, which are then propagated through “bundlers” and picked up by “bundlers” acting as EOA to execute them on-chain on behalf of the users.

The protocol also has other components such as EntryPoint contracts to prevent DoS, userOps aggregation for gas optimization, and LianGuaiymaster for gas sponsorship, but those are the key points.

Note that ERC 4337 does not make changes at the protocol level. From the perspective of the Ethereum protocol, it is still an EOA calling a smart contract. Transactions submitted by bundlers are in the same format as any other Ethereum transaction.

While ERC 4337 is a standard rather than an application, its design is not very general-purpose. It primarily focuses on smart contract wallets, especially some urgently needed features such as gasless/gas sponsorship transactions, multi-signature, spending limits, session keys, etc.

Although the adoption of ERC 4337 on Ethereum is negligible compared to overall user activity, it is still in the early stages.

Arbitrum / Optimism

In EVM Rollups such as Arbitrum and Optimism, users sign complete transactions authorizing the execution path. In this sense, these Rollups look very different from intent-based applications on Anoma. However, if we look closely, we can also recognize some similarities between Rollups and intent-based applications.

For example, in Rollups, finality (in this specific context, only meaning transaction ordering) is achieved through off-chain processing by a (centralized) sequencer, which then submits a batch of transactions to the Rollup settlement contract to settle them atomically. It can be said that the purpose of the settlement contract is to simulate the role of predicates, as its purpose is verification rather than execution.

Why is Anoma unique?

The key point here is that many powerful applications today are already intent-based. The wide adoption of these applications encourages us to believe that intent is the correct abstraction for users. In addition to the existing user appeal, the current efforts on ERC 4337, SUAVE, and CoWSwap Hooks can be seen as early signs of a broader trend towards generalizing intent.

The question now is, what role does Anoma play in this landscape? Or more specifically, what is Anoma’s unique value proposition? To answer this question, we review our findings and analyze the limitations faced by these applications to understand what value Anoma will bring.

Centralized/Decentralized Counterparty Discovery (CD)

While some applications rely on centralized servers, others have built their own distributed solutions. Generally, these decisions may not affect security (cross-domain applications being an important exception), but they can greatly alter the assumptions of liveliness.

OpenSea is a typical example of a centralized server facilitating CD. While OpenSea servers cannot steal funds or tamper with signed orders, they can easily review them. Indeed, OpenSea often reviews certain types of orders due to regulatory concerns or business-related motivations.

In the second camp, there are some ambitious teams such as CoWSwap, Arbitrum/Optimism, and dYdX. Building a distributed network for CD and settlement requires progressive decentralization and takes years of roadmap. This naturally slows down the pace of innovation at the application layer.

It is crucial that as applications move CD and settlement solutions to their custom isolated off-chain networks, they give up composability at the intent layer. CoWSwap, 1inch Fusion, and OpenSea, although all trading applications, have separate “intent” pools that do not overlap. As a result, the solvers of these applications miss out on aggregation and matching opportunities, which otherwise would save on gas and slippage.

Fragmentation also undermines network effects when bootstrapping network suppliers. Intent networks rely on solvers competing with each other to resolve intents in exchange for fees. The more propagation, the more incentives for new solvers to join the network, which is crucial for improving the quality of executing user intents.

In other words, “intent-specific applications do not scale. Intents scale.”

Anoma’s vision is to establish a global intent propagation network where nodes can observe and process intents from many applications. This architecture allows intents to easily combine with each other at the intent layer, even before settling on-chain.

Anoma’s intent network is sparse; not all nodes observe all intents. Nodes should subscribe and listen to subsets of intents they are interested in. Nodes have a natural tendency to subscribe to intents that may be compatible with each other. Over time, as market dynamics change, nodes may unsubscribe from certain types of intents and subscribe to new intents.

Domain Abstraction

Ideally, we want intents to utilize the same architecture regardless of which application they belong to or which domain they address. This brings us to Anoma’s second design principle; homogenous architecture, heterogeneous security!

Existing intent-based applications have programming languages and transaction semantics tied to the underlying VM. In a heterogeneous multi-chain world, this means that nodes in CD and settlement networks must parse and interpret intents based on their VM. On the other hand, Anoma is language-agnostic; intent formats and semantics are decoupled from the underlying settlement layer’s VM.

The goal here is to abstract intent from the settlement layer. The Anoma architecture doesn’t actually care where the intent is settled. Intent could be settled on any blockchain, or even on a centralized server. This is left for the user/application to choose.

However, this doesn’t mean that intent can magically solve the inherent limitations of cross-chain communication. Intent is subject to the same cross-chain risks as finality risk, trust counterparties, etc.

However, intent has the potential to greatly improve user experience. In a future centered around intent, users may never have to directly interact with cross-chain bridges. They can rely entirely on resolvers, which assume and price these risks. For most users, this may be a more attractive trade-off.

While individual intents alone cannot eliminate any cross-chain risks, Typhon in the Anoma architecture – an important component of the Anoma architecture – is unique in this regard. Typhon promises to provide a unique way for independent chains to communicate atomically, thereby reducing the risk of cross-chain communication. We will explore Typhon in depth in the third part of this series to see how Anoma intent graphs can settle atomically on multiple chains.

Simulations are inefficient

We have outlined how intent-based applications are simulated on top of imperative architectures. This leads to some significant inefficiencies.

1. Transactions and smart contracts used to express intent are fundamentally expensive and inefficient tools. First, it is often unnecessary to put our transactions in a total order. If you want to sell an NFT and I want to buy a username on a domain service, we shouldn’t actually care about the order of our transactions relative to each other. When we use transactions and smart contracts to express our intent, we are paying for a global order that we actually don’t need.

2. When using smart contracts to express intent (such as smart contract wallets or Seaport regions), we first have to pay the cost of storing the code on-chain before we can execute it, which is very expensive. In Anoma, in most cases, intent logic can be encoded as stateless predicates at runtime, greatly reducing the execution cost.

3. In the imperative world, developers play the roles and motivations of different participants (borrowers and lenders, LPs and traders, etc.) in the application and encode them as smart contracts that are deployed on-chain. Therefore, before participants interact, the roles and motivations of opponents are already known. This limits the possibilities for participants’ future actions and restricts their ability to adapt to changes in market conditions. Iterations performed in the application logic often require deploying a new version of the application, and users migrate their liquidity from one version to another. In contrast, application developers on Anoma do not need to predict the roles and motivations of future participants. Intent is an ephemeral expression that can easily adapt and change application logic in response to changing market conditions.

4. Another inefficiency of imperative execution is that it assumes the signers of the commitment are also the executors. For example, in the EVM, transactions always originate from an EOA. This imposes a burden on users to discover counterparties. For example, users who want to bridge some tokens need to understand and compare existing bridges based on factors such as liquidity, latency, trust assumptions, etc. This is a dead end for most current and future users.

Although bridge aggregators have significantly improved the user experience, they are not a panacea. They are still limited by imperative architecture. Despite aggregators calculating the best execution path off-chain, users still need to have prior knowledge of their counterparties; this is an aggregator application for a specific on-chain application.

The Anoma architecture fundamentally decouples the roles of commitment signers (users) and executors (solvers). This explicit separation provides flexibility for users and solvers. Users can sign commitments without even knowing who their counterparties are or will be, while solvers can selectively handle the intentions they want to process and how they want to process them. Solvers can devise their own competitive strategies and make quick adjustments when market conditions change.

Information Flow Control

Last but equally important, the inability of users to control the flow of information (i.e., who can see what information) fundamentally limits the use cases promised by decentralized applications today. Privacy is actually the key to unlocking the adoption of encryption by the masses (enterprises and retail users), yet it remains a challenge that most people overlook. As mentioned in the first part, Anoma’s intent-based architecture achieves information flow control at the intent layer. Users can selectively determine which nodes in the intent propagation layer can see and process their intentions.

Conclusion

This article outlines the intent-based applications widely used today and the benefits that the Anoma architecture may provide.

In the third and final part of this series, we will delve into the mysterious world of Typhon and nested chains to see how Anoma intents can settle atomically across multiple chains.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!