# Announcing ERC7683: The Cross Chain Intents Standard

*This article is the final draft of the article that was eventually published [here](https://archetype.mirror.xyz/aV7c1hoVjy48RlhaaJJiGDAaoLGXkiDWMIMmkdJDDLQ).*

This post is split up into two sections. First, I describe my belief that chain-abstraction infrastructure is vital for consumer adoption of crypto and that intents-based architecture is the best way to engineer chain-abstraction. Secondly, I describe the main obstacle toward broader adoption of intents: solver-network liveness.

I end the piece with a solution and introduce the [standard](https://github.com/ethereum/ERCs/pull/375) that Across and Uniswap have collaborated on, using feedback derived from the [CAKE working group](https://frontier.tech/cake-working-group). This standard is designed to optimize for the solver UX and lower barriers to entry to a universal solver network that most intents can be routed to.

## Agenda

#### The problem:
0. Defining the end state: what makes crypto applications "usable"
1. Why "chain abstraction" is a solution to a UX problem that arises out of the fundamental topology of modular blockchains
2. Why usable crypto applications must be built on top of chain abstraction infrastructure

#### The solution space:
3. How intents-based architecture will give rise to chain abstraction
4. Understanding that intent marketplaces perform best when the solver network is large and competitive
5. Bootstrapping the intent solver network requires onboarding more applications that will produce intents

#### The proposal:
6. Why we need a cross chain intents standard that prioritizes "solver UX" to grow the solver and intent marketplace to large enough scale to achieve network effects

# Usable crypto applications cannot be built without chain abstraction

### Are our best and brightest building redundant infra?


Many have lamented that the best crypto engineers and most based thinkers are overallocating attention and energy toward offering more blockspace to end users. This criticism has merit; there are too many L2s available for end users relative to the demand for them.

However, I don't accept the argument that the existing crypto product offering is fundamentally useless. Decentralized finance offers individuals the ability to self-custody digital assets, allowing them to work around draconian service providers and use their digital assets to buy things valued in the real world. The promise of self-custodied data also offers a legitimately utopian alternative for individuals that are becoming increasingly taken advantage of by FAANG monopolies.

The real problem in my opinion is not lack of useful crypto applications but friction for end-users trying to access them. End users should be able to experience the following when interacting with crypto applications:
- **speed**: applications should feel as fast as web2 applications
- **cost**: unlike web2, all web3 interactions must incur some cost, but the "cost per click" should be negligible
- **censorship-resistance** ("permissionless-ness"): anyone with a wallet should be able to interact with the application if they can afford to click
- **security**: clicks should do what users expect them to do and not revert--all web3 updates should be permanent

These are the properties of *"usable"* crypto applications.

### We've been trying to build usable crypto for a long time

The modular blockchain solutions today offer consumers all of these properties today, but they are not all available in the same place.

In 2020, blockchains were monolothic, offering two of three properties to end-users: speed, cost, or security. We then envisioned a [rollup-centric or modular future](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) that would unlock all three properties simultaneously.

Today, we have built the groundwork for this rollup-centric infrastructure. All [L2s](https://hackmd.io/yrZU2Qd6QAiGaXy1fIxqvg#What-does-blockchain-infrastructure-mean) offer cheap and fast block-space, and most of them offer permissionless block-space. Conversely, L1 offers WW3-resistant, secure block-space. These L2s connect securely to L1 via canonical message paths, laying the foundation for a modular yet interoperable network today. In four years, we've built the optical fiber between blockchains that will one day support useful crypto applications. But why are modular blockchains so unusable?


**The inevitability of modular blockchain networks is that capital assets will accrue at the most secure layers while user clicks will manifest at the faster and cheaper layers**

Modular blockchain topology encourages secure block-space to be offered on a different layer than fast and cheap block-space. Users will naturally prefer to store their value on the most secure networks, but they will demand to interact most frequently with cheap and fast networks. [By design](https://hackmd.io/yrZU2Qd6QAiGaXy1fIxqvg#Sequencers-versus-Bridges), the canonical paths between L2s and L1 are slow and/or expensive. These phenomena explain why users must traverse these canonical pathways to pay for L2 interactions using L1 assets. This results in "unusable" crypto UX.


*[Vitalik on different types of L2s](https://vitalik.eth.limo/general/2023/10/31/l2types.html)*

The goal of chain abstraction is to abstract the friction of sending value across these in-protocol paths away from the user. [Chain abstractors](https://frontier.tech/cake-working-group) assume that users prefer to specify their desired end-state to dApps as "intents" and it is the responsibility of the dApp to fulfill their intents. Users should not have to compromise secure custody of their assets in order to access low fees and latency.

Therefore, [Chain abstraction](https://pages.near.org/blog/why-chain-abstraction-is-the-next-frontier-for-web3/) depends critically on users being able transfer value across networks **securely, cheaply and fast**. A common user flow today is that a user with a USDC balance on a "secure" chain like Ethereum wants to mint an NFT or go shitcoining on a newer chain like Blast or Base. The way to do this in as few steps as possible is to sequentially execute a Bridge --> Swap (or Swap --> Bridge) --> Mint series of transactions.

In this example, the user's intent is to use their USDC on the secure chain to mint an NFT on another chain. The user will be satisfied as long as they receive the NFT and their USDC balance is charged wherever they choose to custody.

# Intent-based architecture is the only way to build chain abstraction

Chain Abstraction relies on cross-chain value transfer but sending value via canonical messaging paths is either expensive or slow. "Fast Bridges" offer cheap and fast alternatives for users to send value across networks, but they introduce new trust assumptions. Message passing is the most intuitive way to build a fast bridge because it is modeled off of the TCP/IP architecture; it relies on a bridge protocol acting as the TCP Router to connect two chains.


Value transfer via message passing involves the bridge protocol sending messages between its contracts on the origin and destination chains. This message is triggered on the origin side by a user transaction and relayed to the destination side once the message's "validity" is verified.

A message can only be verified after the origin-chain transaction initiating the message has finalized. This verification can be completed as a validity-proof proving consensus inclusion of the transaction on the origin chain, as an optimistic proposal, or after a threshold of witness signatures attesting to its inclusion have accumulated on the origin side. Once the message is relayed to the Bridge contract on the destination chain, tokens are released to the user.


There are several fundamental issues with this architecture:
* The verification mechanism must wait for full finality before the sending message to the destination chain protocol contract
* One cross-chain message is sent per bridge transaction OR
* Messages are batched together, but the batch can only be sent after the last message in the batch is finalized
* The bridge has limited ability to source external liquidity to give user price improvements because it must be declarative about the fulfillment path of the user intent

Message passing fast bridges are going to be either unsecure, slow, or expensive depending on the verification mechanism. Intent marketplaces are an alternative architecture for fast bridging that arise from a key insight:

## Value is fungible and it shouldn't matter to the recipient how the value is transferred as long as they receive the $$

Can a bridge outsource the value transfer to a sophisticated agent to gain speed and cost? Liquidity is dynamic on and off-chain and price improvement can be realized if the bridge mechanism has flexibility to choose an optimal execution path *at the time of the bridge transfer*.


Intent mechanisms allow users to specify precise conditions or covenants under which their *value transfer* transaction can be executed. A minimal viable intent is an order to pay X token from chain A to receive Y token on chain B. The bridge protocol does not need to send a message between domains *per bridge-transaction* to fulfill a user's cross-domain intent. Instead, the protocol outsources the value transfer to an agent drawn from a permissionless solver network, and the individual solver will seek repayment later by the bridge protocol. In comparison, message-passing mechanisms specify exactly how their transactions should be executed and do not need to rely on the availability of an agent.

## Intent settlement protocols
Intent-based bridge protocols can be labeled more precisely as *intent settlement protocols* that are responsible for ensuring that solvers do not violate the user-specified conditions. Intent settlement protocols offer solvers security that they will be repaid and rewarded for fulfilling user intents. To do so, intent settlement protocols need to appeal to an oracle to verify the authenticity of the intent-fulfillment. The oracle's security can be grounded in an optimistic challenge period, a witness threshold, or be zk validity-proof based, for example. In addition to securely settling intents, intent settlement networks can offer additional degrees of freedom that users can use to specify their cross-chain intents (more on this [here](#The-value-proposition-of-intent-settlement-networks-is-offering-security-to-solvers-as-well-as-other-features-that-would-affect-the-solvers-ability-to-fill-an-intent))

## Intent settlement protocols offer fast and cheap value transfer because individual solvers can take on finality risk and identify optimal execution paths

Message passing bridges can only communicate as quickly as finality is reached by the originating chain. Finality times are seven days on optimistic rollups and one hour on zk rollups today. Even though these finality times should trend down following broader adoption of zk-light client technology and advancements in shared-sequencing [pre-confirmation](https://ethresear.ch/t/based-preconfirmations/17353) technology, it is unlikely that finality times for all blockchains will ever feel "instant" for users, suggesting a persistent need for fast bridging solutions. It is impossible to relay a message faster than the finality period without assuming finality risk, which is outside the scope of a message-passing bridge, unless the bridge wants to add an additional trusted agent to the relay path who will backstop losses due to chain reorganizations.

**The speedup offered by intents-based archicture arises because individual solvers within a heterogenous solver network can assume more finality risk than a message-passing protocol can and can fill a user's intent before chain-reorg risk completely disappears.** Solvers will subsequently charge users for this finality risk they assume, in exchange for faster fill times.

Outsourcing cross-chain intent fulfillment to an agent also leads to price improvement on average for users. In intents-based bridges, solvers who front user orders on the desired destination chain are repaid later by the system after their fulfillment is validated. These intent settlements can be batched together to amortize cost. Fillers, unlike users, do not demand instant repayment and will charge users accordingly for fronting them capital. Batch settlement is not unique to intent-based architecture, but the architecture is more synergistic with batch settlement becuse it separates the repayment step from the intent fulfillment step.

The larger source of price improvement comes from the intuition that value is fungible, and finding the best path just-in-time will usually outperform value transfer (However, some paths will be impossible to beat on cost just-in-time, for example when bridging USDC --> USDC over CCTP). Message passing bridges must encode how they will transfer value to the user. Some elect to send tokens out of a liquidity pool at a predetermined exchange rate, while others mint representative tokens to recipients who need to then swap for the desired canonical token asset. When fulfilling a user's intent, an agent can source liquidity from a combination of on-chain and off-chain liquidity venues, or even [net user orders off](https://blog.cow.fi/what-are-cows-on-cow-swap-e72baaa4678a). In practice, solvers today often run out of inventory and need to rebalance frantically as volume trends in certain directions during high volatility market settings, but competitive solver networks offer users unlimited sources of liquidity in theory.


*Submitting a cross-chain order as an intent allows solvers to internalize the order's generated MEV as price-improvement*

## Intents-based architecture is fundamentally designed to be secure


Intent-based bridges can be built securely because they separate the urgent demands of the user from the complex demands of the settlement network. Solvers can wait for repayment, unlike users. They will charge users for the amount of time that the settlement protocol makes them wait for repayment. Therefore, **intent settlements can be validated using very robust mechanisms without a strict time constraint**. This is preferable from a security standpoint because verifying an intent fulfillment is intuitively complex.

As an example of intent verification in production, Across validates and repays fillers in batches following a 90-minute optimistic challenge period. Of course, settlement networks should strive to repay fillers as quickly as possible to reduce end-user fees. An improvement on the optimistic challenge mechanism would be a zk validity-proof mechanism, which would require encoding the intent validation logic into a zk circuit. In my opinion, its an inevitability that validity proving mechanisms will replace optimistic challenge mechanisms and allow intent settlement networks able to repay users faster.

## So, how does chain abstraction arise out of intents-based architecture?

Recall that chain abstraction requires fast and cheap cross-chain value transfer. It also shouldn't require the user to submit an on-chain transaction on the network where their assets are stored.


A user's intent does not need to be submitted on-chain by the user if it includes a [Permit2](https://github.com/dragonfly-xyz/useful-solidity-patterns/blob/3c33e0743c9d43ec239a32f82e7c9e9882e6da6d/patterns/permit2/README.md) or [EIP3074](https://twitter.com/lightclients/status/1371911248816738306) signature. This is true for both message-passing and intents-based bridges. Both architectures can take advantage of the Permit2 pattern to allow the user to sign off-chain the amount of tokens that they are willing to pay from their origin chain wallet.

Intent marketplaces best support chain abstraction because they offer cheap and fast cross-chain value transfer. Imagine a world where a user could request a solver to give them a quote to enter into a WETH staking position on Arbitrum, using their USDC on Optimism as payment. The user could send this intent off-chain to an RFQ auction where solvers could bid on this intent. The winning solver of the auction could then receive the user's signed intent, containing a Permit2 allowance to spend their USDC on Optimism, their desired amount of WETH to receive on Arbitrum, and the calldata needed to deposit this WETH into a staking position on Arbitrum. The solver could subsequently submit this Permit2 transaction on Optimism to initiate the cross-chain intent and pull USDC from the user's Optimism wallet. Finally, the solver could fill the user's intent on Arbitrum by sending them WETH and forwarding the calldata to enter the user into the on-chain staking position.


Building chain abstraction infrastructure means making this user flow feel instantaneous, cheap, and not require them to submit an on-chain transaction. Let's conclude this article by discussing obstacles to broader adoption of intents.

# For the best case user experience to materialize out of intents-based chain-abstraction, we need a competitive network of solvers.

Bridging with intents depends on solver network effects to perform better than message passing variants. This is the core tradeoff of intent versus message-passing architectures. Realistically, not all applications producing intents will need access to a *perfectly* competitive set of solvers, and some might prefer routing their intents to [oligopolistic solver networks](https://arxiv.org/pdf/2403.02525.pdf). However, the current state of solver networks is [immature](https://blog.li.fi/the-untold-trade-offs-in-intent-based-bridges-1c7e5cdd0ac0) and isn't close to fulfilling the assumptions of solver network liveness that intent-marketplaces depend on.


We don't want a world where each dApp is routing intents to isolated solver networks. The best case for UX is that many dApps communicate with the same solver pools, and all dApps have the freedom to change which solver pools they send their intents to.

## How do we bootstrap the solver network?

We must prioritize solver UX.

Running an intent solver is complicated and it requires expertise in building highly-performant software as well as managing cross-chain inventory risk. Naturally, there will be limited parties interested in paying the startup cost to run this code. In the best case scenario, a solver written for one dApp, like a UniswapX solver, could be reused to solve for other intent-producing dApps like Across and CowSwap.

We really need to increase the aggregate capital efficiency of the solver network for all intent-based dApps. This will require addressing the barriers to running a solver.

For this, we'll need dApps producing intents to be visible to any solver as well as giving all solvers access to many differentiated and competitive intent settlement networks. This would give confidence to solvers that they could choose to route their intent fulfillments to a settlement network that they trust. The competition between settlement networks would also lower costs for solvers.

### The value proposition of intent settlement networks is offering security to solvers as well as other features that would affect the solver's ability to fill an intent.


The solver's choice of intent settlement network will affect their ability to offer fees and execution-time guarantees to users. Some settlement networks might offer solver exclusivity periods, which would support the development of off-chain auctions where solvers and users could negotiate and commit to relay fees. *(These intent auctions might moreover offer economically bonded pre-confirmations--further enhancing UX. To learn more about a user flow featuring intent discovery via auctions and pre-confirmations I recommend this [talk by Karthik of Sorella](https://youtu.be/vr_8VL8yJbw?si=p9nHPfGb_E7r8InF&t=840))* Some settlement networks might offer intent expiry (i.e. sending value back to users after some fulfillment deadline is passed), or intent backstopping (i.e. the settlement network using its own balance sheet to fulfill a user's intent if no solver does), or flexible repayment chain (i.e. allowing the solver to get repaid on their chain of choice).

In the end, settlement networks will compete ferociously to repay solvers quickly and cheaply without compromising on security. In turn, solvers will send their orderflow to the settlement networks that allow them to offer the cheapest fees to users so that they can win the dApp orderflow. Competition in settlement and solver networks depends on all parties in the intent supply-chain coordinating to speak the same language, and competition will lead to the best UX for cross-chain value transfer.


# It is clear that we need a standard for cross chain intents

If solvers can assume that intents will share common elements, then they can reuse their code to solve intents originated by different dApps and subsequently lower their setup costs. If different dApps create intents that conform to the same standard, then they can all route their intents to the same solver pools. This would help onboard the next generation of dApps by giving them the ability to plug-in their cross-chain intents directly to an existing and mature solver pool. New dApps would not have to individually on-board solvers and instead would get access to cheap, fast, secure, and permissionless value transfers.

Third party tracking software would also be more easily able to track intent statuses for any new dApp if they conform to a standard.

## This intent standard *should* allow the intent principal or the solver to specify which settlement network they wish to settle their intent.

I envision competing settlement protocols like SUAVE, Across, Anoma and Khalani offering differentiated features to intent solvers. Depending on which settlement network would be repaying the solver, the solver can offer different price and time guarantees to the owner of the intent. The dApp and solver could agree to route a user's intent to a settlement network they trust to avoid censorship, maintain data privacy, and also be secure enough to be trusted to repay the solver.

By enshrining the choice of settlement network into the intent order itself, the solver could bake this certainty into the quote that they would show to the user. The solver and user would eliminate upfront uncertainty about bridge pricing before submitting the intent on-chain, reducing costs.

# In collaboration with Uniswap and based on feedback from the [CAKE working group](https://frontier.tech/cake-working-group), we propose the following cross chain intent standard prioritizing solver UX:

/// @title CrossChainOrder type
/// @notice Standard order struct to be signed by swappers, disseminated to fillers, and submitted to settlement contracts
struct CrossChainOrder {
    /// @dev The contract address that the order is meant to be settled by.
    /// Fillers send this order to this contract address on the origin chain
    address settlementContract;
    /// @dev The address of the user who is initiating the swap,
    /// whose input tokens will be taken and escrowed
    address swapper;
    /// @dev Nonce to be used as replay protection for the order
    uint256 nonce;
    /// @dev The chainId of the origin chain
    uint32 originChainId;
    /// @dev The timestamp by which the order must be initiated
    uint32 initiateDeadline;
    /// @dev The timestamp by which the order must be filled on the destination chain
    uint32 fillDeadline;
    /// @dev Arbitrary implementation-specific data
    /// Can be used to define tokens, amounts, destination chains, fees, settlement parameters,
    /// or any other order-type specific information
    bytes orderData;
}

This standard is intentionally minimal because it needs to be generalizable. One opinionated choice it makes is supporting Permit2/EIP3074 natively with the `nonce` and `initiateDeadline` and it gives fillers some guarantees such as the amount they will be refunded from the settlement network and the format of the user intent that they can track.

Any intent settlement system implementing this standard should create a custom sub-type `ResolvedCrossChainOrder` that can be parsed from the arbitrary `orderData` field. This may include information such as the tokens involved in the swap, the destination chain(s), and other fulfillment constraints. A `resolve` function is included in the standard to make it easier for dApps to understand how to display intent statuses to users and for solvers to know how to work with specific settlement networks.

/// @title ResolvedCrossChainOrder type
/// @notice An implementation-generic representation of an order
/// @dev Defines all requirements for filling an order by unbundling the implementation-specific orderData.
/// @dev Intended to improve integration generalization by allowing fillers to compute the exact input and output information of any order
struct ResolvedCrossChainOrder {
    /// @dev The contract address that the order is meant to be settled by.
    address settlementContract;
    /// @dev The address of the user who is initiating the swap
    address swapper;
    /// @dev Nonce to be used as replay protection for the order
    uint256 nonce;
    /// @dev The chainId of the origin chain
    uint32 originChainId;
    /// @dev The timestamp by which the order must be initiated
    uint32 initiateDeadline;
    /// @dev The timestamp by which the order must be filled on the destination chain(s)
    uint32 fillDeadline;
    /// @dev The inputs to be taken from the swapper as part of order initiation
    Input[] swapperInputs;
    /// @dev The outputs to be given to the swapper as part of order fulfillment
    Output[] swapperOutputs;
    /// @dev The outputs to be given to the filler as part of order settlement
    Output[] fillerOutputs;
}
/// @notice Tokens sent by the swapper as inputs to the order
struct Input {
    /// @dev The address of the ERC20 token on the origin chain
    address token;
    /// @dev The amount of the token to be sent
    uint256 amount;
}
/// @notice Tokens that must be receive for a valid order fulfillment
struct Output {
    /// @dev The address of the ERC20 token on the destination chain
    /// @dev address(0) used as a sentinel for the native token
    address token;
    /// @dev The amount of the token to be sent
    uint256 amount;
    /// @dev The address to receive the output tokens
    address recipient;
    /// @dev The destination chain for this output
    uint32 chainId;
}

A compliant settlement contract implementation MUST implement the `ISettlementContract` interface:

/// @title ISettlementContract
/// @notice Standard interface for settlement contracts
interface ISettlementContract {
    /// @notice Initiates the settlement of a cross-chain order
    /// @dev To be called by the filler
    /// @param order The CrossChainOrder definition
    /// @param signature The swapper's signature over the order
    /// @param fillerData Any filler-defined data required by the settler
    function initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;
    /// @notice Resolves a specific CrossChainOrder into a generic ResolvedCrossChainOrder
    /// @dev Intended to improve standardized integration of various order types and settlement contracts
    /// @param order The CrossChainOrder definition
    /// @param fillerData Any filler-defined data required by the settler
    /// @returns ResolvedCrossChainOrder hydrated order data including the inputs and outputs of the order
    function resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);
}

The design goals of this standard were to enhance solver UX to make it easier for them to support multiple settlement networks and deterministically compute their rewards. I believe that this will allow them to give more accurate and tighter quotes to users. You can read more details about this standard [here](https://x.com/AcrossProtocol/status/1778434193288249636) and the discussion surrounding it [here](https://ethereum-magicians.org/t/erc-7683-cross-chain-intents-standard/19619).

# Closing thoughts

"Intents" are confusing because they are not defined, and this lack of a definition is creating real UX defects.


Everyone wants everyone else to use their standard definition of an intent, so I fully acknowledge that standards are practically impossible to establish. The way I see it playing out is that dApps that originate user intents like UniswapX and Across will agree to conform to some minimal standard that many solvers adopt. These dApps will route their intents to the solvers via some aggregation layer like Enso or Khalani, and they will select a settlement protocol like Across or UniswapX to repay them after successfully filling the user intent. The key prediction (and hope) here is that the aggregate solver balance sheet can be re-used across different intent-originating dApps, providing a boon for users.

To get us kickstarted, Across and Uniswap are proposing a standard for all intent supply-chain parties to use when handling user orders to send X tokens from chain A and receive Y tokens on chain B. The big unlock for Across and Uniswap is that fillers will be able to be re-used. UniswapX (having a comparative advantage in auction design and originating intents) and Across (having a comparative advantage in settling intent fulfillments) are synergistic in coalescing around this design.

This article was inspired by many IRL and online discussions with the following folks building actively within the intents supply chain:
- [Ankit](https://twitter.com/ankitchiplunkar) from frontier.tech
- [Mark](https://twitter.com/MarkToda), [Alice](https://twitter.com/hensha256), and [Emily](https://twitter.com/crypt0glitter) from Uniswap
- [Arjun](https://twitter.com/arjunnchand) from Li.Fi
- [Karthik](https://twitter.com/ksrini_) from Sorella
- [Kevin](https://twitter.com/knwang) from Khalani
- [tumilet](https://twitter.com/tumilett) from The Spartan Group
- [Matt](https://twitter.com/mrice32), Ryan and [Hart](https://twitter.com/hal2001) from Across
- [Benji](https://twitter.com/0xFunk) and [Dmitriy](https://twitter.com/dberenzon) from Archetype
- [Will](https://twitter.com/willkantaros) from Decent
- [Francesco](https://twitter.com/fulminmaxi) from Flood

Finally, the ideas in this article are summarized in the following ETH Denver talks that Hart and I gave:

<iframe width="560" height="315" src="https://www.youtube.com/embed/qoDJxl7AR48?si=c0kRBf6PRBgSqLSf" title="Hart Lambur: Across' Take on Intents" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

<iframe width="560" height="315" src="https://www.youtube.com/embed/S3WV_eBF45w?si=RxEK49s37itoUJPc&amp;start=2" title="Nick Pai: How Intents Solve Interoperability" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

# Where to learn more about intents and chain abstraction

1. [UniswapX](https://uniswap.org/whitepaper-uniswapx.pdf)
2. [CAKE Framework by frontier.tech](https://frontier.tech/the-cake-framework)
3. [Anoma blog on Intents](https://anoma.net/blog/towards-an-intent-centric-topology)
4. [Intents, Suave, AA, XChain Bridging are all the same thing - Uma Roy](https://www.youtube.com/watch?v=G0nFyq9DDPw)
5. [Intent-based Architectures and their Risks](https://www.paradigm.xyz/2023/06/intents)