Title: ERC_7683__Cross_Chain_Intents_Standard
Category: ERCs

Author: marktoda
Date: 2024-04-11T14:25:10.555Z

The Cross Chain Intents Standard is meant to unify off-chain messages and on-chain settlement smart contracts to enable sharing of infrastructure, filler networks, and orders across cross-chain bridging and trading systems.
ERC:

github.com


ethereum/ERCs/blob/master/ERCS/erc-7683.md
---
eip: 7683
title: Cross Chain Intents
description: An interface for cross-chain trade execution systems.
author: Mark Toda (@marktoda), Matt Rice (@mrice32), Nick Pai (@nicholaspai)
discussions-to: https://ethereum-magicians.org/t/erc-cross-chain-intents-standard/19619
status: Draft
type: Standards Track
category: ERC
created: 2024-04-11
---

## Abstract

The following standard allows for the implementation of a standard API for cross-chain value-transfer systems. This standard provides generic order structs, as well as a standard set of settlement smart contract interfaces.

## Motivation

Intent-based systems have become the preeminent solution for end-user cross-chain interaction by abstracting away the complexity and time constraints of traditional bridges. One of the key difficulties for cross-chain intents systems is accessing sufficient liquidity and a network of active fillers across chains. This challenge may be exacerbated as the number of distinct chains increases over time. The end result of this is a poor experience for users including higher costs, longer wait times and higher failure rates than necessary.





  This file has been truncated. show original

Author: xinbenlv
Date: 2024-04-11T17:21:04.203Z

Hi @marktoda, cross-chain intents, this is an important space to solve on. Thanks for proposing it!
A few technical questions

settlement, swap etc seems assuming a specific token or token standard and a clearing / settling enivronment, have we think about making it something more general like a UserOps / general contact call?
on the other hand, assuming this standard just wanna solve crosschain token settlement, how does ResolvedCrossChainOrder include attestants from the settlement chain?

Author: nicholaspai
Date: 2024-04-11T18:02:54.481Z

hey @xinbenlv i’ll try to chime in here.

I think the  generalized message problem is very different from the token swap standard. I think smart contract systems that support this token standard (like Bridges and Cross Chain DEX’s) will be built on top of some sort of messaging network that uses a message standard in some way. The goal we had with proposing this token standard is to shrink the scope of the problem so that Bridges and DEX’s can use the standard today today while maintaining composability with existing messaging networks.
I think the idea of “attestants” is an opinionated feature that some intent settlement networks might use but others may not. I’m assuming you are defining an attestant as someone who claims “I saw an intent sent on X origin chain and I want to fulfill it” or perhaps someone who claims “I saw an intent sent on X origin chain and it was fulfilled by Alice on Y destination chain”. If an attestant is the former role, then I think they are a “filler” in the standard’s language, which is not included in the standard as it is not required for the intent principal to define when initiating an intent. However, some settlement systems might allow the intent to whitelist a specific filler for a specific intent. If an attestant is the latter role, then they are an intent settler or settlementContract in the standard. One of the goals of the standard is to allow intent settlement contracts to be opinionated about how they refund fulfilled intents while also committing to some shared language and feature-set. The standard allows fillers to define who they want to decide whether their fulfillment was valid or not, which helps them to give more accurate pricing to users who submit cross chain intent orders

Author: xinbenlv
Date: 2024-04-12T12:57:38.526Z

nicholaspai:

I think the generalized message problem is very different from the token swap standard. I think smart contract systems that support this token standard (like Bridges and Cross Chain DEX’s) will be built on top of some sort of messaging network that uses a message standard in some way. The goal we had with proposing this token standard is to shrink the scope of the problem so that Bridges and DEX’s can use the standard today today while maintaining composability with existing messaging networks.


Agreed, in that case please update the title and summary to reflect this scope



 nicholaspai:

I think the idea of “attestants” is an opinionated feature that some intent settlement networks might use but others may not. I’m assuming you are defining an attestant as someone who claims “I saw an intent sent on X origin chain and I want to fulfill it” or perhaps someone who claims “I saw an intent sent on X origin chain and it was fulfilled by Alice on Y destination chain”.


It’s less opinionated than you think: it’s more about future compatibility. If there is an attestation field predefined, anyone (future contract implementing your ERC) who doesn’t care about attestation can just leave it unfilled, contracts can ignore them: the behaves like a naive optimistism without challenging mechanism, pretty much centralized trust is the only way. yet anyone (future contract implementing your ERC) who cares about attestation can fill them with challengable optimistism commitments or zkproofs.
Opens up a lot of future compatibility for you.
That said, this is a great idea to work on. congrats on drafting it!

Author: heuer
Date: 2024-04-12T15:38:41.176Z

have we think about making it something more general like a UserOps / general contact call

I think what you are proposing here is done by Anoma (see also Anoma: a unified architecture for full-stack decentralised applications, or the recent ethresear.ch post).

Author: FakeZL
Date: 2024-04-23T02:44:16.849Z

Should we consider not only EVM chains but also NO-EVM chains?
0. orderData is a good design for support no-evm chain

in the difine ResolvedCrossChainOrder：input

/// @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;
}

adress token should not be type address

Author: xinbenlv
Date: 2024-04-25T04:06:25.557Z

Hi authors of ERC-7683, this is Victor, an EIP editor and current operator of AllERCDevs.
I like to invite you to our next AllERCDevs meeting (online) to present for 10min of your ERCs if you are interested!
AllERCDevs is a bi-weekly meeting for ERC authors, builders and editors to meet and help the drafting and adoption of an ERC. The next one is 2024-04-30 UTC 2300, let us know if this time works for you, I can put this ERC in the agenda, or you can add a response directly at S2E4 AllERCDevs Agenda 2024-04-30 Tuesday UTC2300 (APEC friendly time) · Issue #22 · ercref/AllERCDevs · GitHub

Author: ss-sonic
Date: 2024-05-21T08:55:13.828Z

The value proposition of EIP-7683, which aims to standardize cross-chain trade execution, is indeed compelling. The potential to streamline cross-chain interactions by providing a unified interface is a significant step forward. However, there are several areas where this proposal could be further enhanced:


Title and Scope:

The title “Cross Chain Intents” is somewhat misleading. The term “intent” is highly generalized and can encompass a wide range of actions beyond just token trades. In the context of blockchain, intents can represent any programmable action, from complex financial transactions to staking and governance activities. A more precise title could help set accurate expectations.



Current Limitations:

As it stands, the proposal primarily facilitates cross-chain token trades using a Request for Quote (RFQ) mechanism. While this is useful, it does not significantly differentiate itself from existing primitives. The current demand in the ecosystem is for more generalized standards that can support a broader range of cross-chain activities. For instance, enabling users to purchase a token on one chain and automatically stake it in a protocol on another chain would provide greater utility.



Scalability and Security Considerations:

The proposal should address how it will scale for Rollups, considering their unique security and finality challenges. Rollups often have delayed transaction finality, and understanding how disputes and resolutions will be handled in the case of rollbacks is crucial. Clarifying these mechanisms will be vital for ensuring robustness and user trust.



Potential for Expansion:

There is a promising opportunity for this standard to evolve into something more sophisticated. Allowing users to express complex intents and having these intents executed by fillers (entities with the necessary funds and capabilities) can open up a myriad of possibilities. Fillers, essentially acting as service providers, could execute a wide range of instructions, from simple swaps to intricate financial operations, in exchange for fees and potential refunds.



Generalized Intent Execution:

The vision should expand towards enabling fillers to carry out a broader set of user-defined actions. This could involve complex transactions that span multiple protocols and chains, thereby significantly enhancing the user experience and the functional scope of cross-chain interactions.



We at Router Protocol are tirelessly trying to solve for chain-abstraction, which is our key area of focus. We are happy to ideate and collaborate to make web3 more simple and usable. In conclusion, while EIP-7683 lays a solid foundation for cross-chain trade execution, its true potential lies in broadening its scope to encompass a wider range of blockchain activities. Addressing scalability and security for Rollups and enabling more complex intent executions could transform this proposal into a cornerstone of cross-chain interoperability.

Author: frangio
Date: 2024-05-23T16:22:41.744Z

Cross-chain execution systems implementing this standard SHOULD create a custom sub-type that can be parsed from the arbitrary orderData field.

If this struct is to be signed as EIP-712 data (the ERC doesn’t specify), the orderData will show up as uninterpreted bytes (i.e. a hex string) to the end-user, resulting in bad security (verifiability) and usability.
This kind of pattern is useful though, and it has come up before in the context of making EIP-1271 signatures account-bound and replay-protected. I believe an EIP-712 extension may be necessary to properly address this.

Author: frangio
Date: 2024-05-23T22:18:34.604Z

I’ve proposed an extension of EIP-712 that would enable better support for implementation-specific orderData:




EIP: Box types for EIP-712 messages EIPs


    A special type box is defined for EIP-712 messages. A box value is a value of an arbitrary struct type whose underlying type is encapsulated from the containing struct, but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a box value, but this type is not erased and can be verified on-chain if necessary.

Author: nicholaspai
Date: 2024-05-24T18:21:57.588Z

The current demand in the ecosystem is for more generalized standards that can support a broader range of cross-chain activities. For instance, enabling users to purchase a token on one chain and automatically stake it in a protocol on another chain would provide greater utility

We designed ERC7683 on the assumption that the majority of cross chain user intents are to (1) do some arbitrary action on the origin chain and then (2) swap into a token on the destination or vice versa. We therefore left room in the bytes orderData to encode arbitrary action. For example, the arbitrary data to execute (2) could be encoded like so into the CrossChainOrder struct:
// Bytes field from CrossChainOrder struct containing the ERC7683-compliant ResolvedCrossChainOrder data along with extra data.
bytes orderData = order.orderData;
struct DestinationAppData {
    address target; // contract I wish to call on the destination chain after my intent is fulfilled
    bytes targetData; // calldata I want to execute on target contract on destination chain
}
(DestinationAppData appData, ResolvedCrossChainOrder crossChainOrder) = abi.decode(order.orderData, (ImplementationData));

Now, I can support a user flow where my user submits an intent containing the above target and targetData in addition to the intent-specific parameters like {input}/{output}{Token}/{Amount}, destinationChainId, originChainId, initiateDeadline, depositor, etc. The user’s chosen intent settlement network would then need to ensure that when a solver fulfills the user’s intent, that the fulfillment triggers a call to target with targetData on behalf of the depositor.
In my opinion, enabling these generalized cross chain user flows is a feature that intent settlement networks can choose to offer or not, and there is room in ERC7683 to support this if the intent principal chooses a supporting settlementContract. The Across network supports this, for example.

Allowing users to express complex intents and having these intents executed by fillers (entities with the necessary funds and capabilities) can open up a myriad of possibilities. Fillers, essentially acting as service providers, could execute a wide range of instructions, from simple swaps to intricate financial operations, in exchange for fees and potential refunds.

Now, this does not handle the case naturally where someone just wants to send a message, involving no token transfers, cross-chain. But you and I both seem to agree that all cross chain user intents will involve a token swap in some way
So, our long term vision is very much aligned with supporting generalized intent execution but we acknowledge that the biggest use case of intents will be to do (1) and (2) above. Therefore this ERC was written to contain the minimum set of parameters to support this cross-chain swaps plus arbitrary action without being too generalized as to be meaningless.
On the rollup security issue, I do not agree that rollup security is not addressed in the ERC parameters, though it is not obvious. By including the settlementContract in the CrossChainOrder struct, the user (or realistically, dApp) has freedom to decide which mechanism will settle their intent and therefore ensures that their intent is fulfilled. In my opinion it is the settlement contract’s responsibility to handle rollup liveness securely. By forcing users to specify the settlement contract, this ERC provides a foundation for a settlement marketplace where settlement protocols compete to abstract rollup security away from users. In my opinion the most successful settlement networks will be the ones who most efficiently remove finality risk while fulfilling user intents and also refund honest solvers.

Author: anna-carroll
Date: 2024-06-04T18:46:07.328Z

Hey y’all, small point of feedback - in the resolve function, why does the return type ResolvedCrossChainOrder repeat all of the fields on the parameter CrossChainOrder? is there ever a circumstance where the repeated fields would or should change between the input CrossChainOrder and the output ResolvedCrossChainOrder? in practice, copying these fields from the input type to the return type makes developing smart contracts that implement this standard unnecessarily uglier to write.
repeated fields:
    /// @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;

I would cut the repeated fields from ResolvedCrossChainOrder to change the type to something like ResolvedOrderData:
/// @title ResolvedOrderData 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 ResolvedOrderData {
    /// @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;
}


then
    /// @notice Resolves a specific CrossChainOrder into ResolvedOrderData
    /// @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
    /// @return ResolvedOrderData hydrated order data including the inputs and outputs of the order
    function resolve(CrossChainOrder order, bytes fillerData)
        external
        view
        returns (ResolvedOrderData);

of course, we still need to pass in the entire CrossChainOrder and fillerData as parameters (not just the raw orderData bytes) as ResolvedOrderData resolution may depend on additional fields

Author: nicholaspai
Date: 2024-06-10T19:49:14.429Z

Hey @anna-carroll thanks for taking a look at this, I think this is a very fair response. I think the idea behind ResolvedCrossChainOrder is that any user of a settlement protocol could glance at this struct in isolation to determine the shape of their intent order with respect to the settlement protocol. The expected user in this case would be a dApp developer or filler.
But I also think its expected that this same user would already know the shape of the CrossChainOrder, having just created/filled an intent order using it, and then would only want to know the additional new params in ResolvedCrossChainOrder that are relevant for the specific settlement contract.

Author: chainchampion
Date: 2024-06-15T13:47:29.628Z

Does this standard enforce / assume that the settlement contract has to live on the source chain of the intent?
What about a settlement model where the intent can be settled on the destination chain or maybe an arbitrary chain which acts as the source of truth for both intent order as well as settlement

Author: nambrot
Date: 2024-06-24T23:30:03.769Z

Thanks for pushing standardization on this very important topic! Here are some of my notes as part of conversations that I had with various folks over the last couple weeks about this topic:

I agree that arbitrary post-fill actions with the tokens are a highly desired feature for cross-chain intents. What do you think about making it an explicit field on CrossChainOrder so that the intent has more standardized fields and requires less divergent tooling for parsing?
While different intent generation and settlement systems could require vastly different orderData schema, I was wondering if there is opportunity for standardization without preventing experimentation. I was thinking of a mechanism like in EIP191 that has a version byte that allows the EIP to formalize orderData like a simple limit order, or an exact order.

Another benefit of pushing for more standardization on orderData is to have less variability in permit2 witnesses and type strings, and allow UIs/wallets to optimize the experience for the standard ones.


Probably doesn’t need to be in the EIP itself, but the high generality of the standard made it a bit hard to wrap your head around it for folks who are not in the weeds. Pseudo-code examples of orderData and settlementContracts I imagine would be helpful in conveying the power of this standard.
I’m curious if you thought about a standard function for filling? I.e. a function fill(CrossChainOrder order, bytes fillerData). I suspect that there are systems where there is no need to change contract state to record the fill which is why it was omitted, but I’d imagine that standardizing this for the settlement systems that do would be still beneficial?

Author: mrice32
Date: 2024-06-26T21:02:19.580Z

Wouldn’t you still need some contract to process the intent on the origin chain since that’s where the user’s tokens reside? The standard only imposes that some contract exists on the origin to process the intent, not that that’s the only point of interaction or validation.

Author: mrice32
Date: 2024-06-26T21:30:00.044Z

I agree that arbitrary post-fill actions with the tokens are a highly desired feature for cross-chain intents. What do you think about making it an explicit field on CrossChainOrder so that the intent has more standardized fields and requires less divergent tooling for parsing?
While different intent generation and settlement systems could require vastly different orderData schema, I was wondering if there is opportunity for standardization without preventing experimentation. I was thinking of a mechanism like in EIP191 that has a version byte that allows the EIP to formalize orderData like a simple limit order, or an exact order.

Another benefit of pushing for more standardization on orderData is to have less variability in permit2 witnesses and type strings, and allow UIs/wallets to optimize the experience for the standard ones.




The way the standard is currently designed, the explicit fields are only the ones that would apply to all implementing protocols. It is intentionally minimalist to ease the burden on implementing protocols and fillers. Adding post-fill actions would mean that some protocols might not implement part of the official standard and be forced to reject intents with that field, which might be confusing. Alternatively, if that field was required to be handled by all protocols implementing the standard, it would be limited to protocols that support it.
Jumping off your points, maybe the right path is to have an extension specification, where extensions that take advantage of orderData could be built and encoded in a specific way whereby each extension is, by default, not mutually exclusive with other extensions. For instance, maybe there’s an extension to encode a limit order and another extension to do post-fill actions. The former could be assigned identifier 0x01 and the latter assigned the identifier 0x02. If my protocol supports both, it could parse the order data to identify the data for each extension using the identifier. If my protocol doesn’t support one of them, it could fail during the parsing process. While something like this is doable, it is complex to specify and implement. Maybe it belongs in a separate ERC.
Thoughts? In my opinion minimalist ERCs often have the best chance of gaining adoption and being useful.


Probably doesn’t need to be in the EIP itself, but the high generality of the standard made it a bit hard to wrap your head around it for folks who are not in the weeds. Pseudo-code examples of orderData and settlementContracts I imagine would be helpful in conveying the power of this standard.


Totally agree. More can and should be added there.


I’m curious if you thought about a standard function for filling? I.e. a function fill(CrossChainOrder order, bytes fillerData). I suspect that there are systems where there is no need to change contract state to record the fill which is why it was omitted, but I’d imagine that standardizing this for the settlement systems that do would be still beneficial?


Definitely. It’s something I’m still wrestling with. The issues I see with a fill function:

Most of the time, a filler does not need to pull in the entire Order/ResolvedOrder to do the fill. Only a fraction of that information is needed at fill time. However, because different protocols will need different pieces of the order (especially different pieces of the orderData), I can’t see how you could avoid requiring the entire order to be passed in and re-parsed. This would be very inefficient for implementing protocols.
Some protocols or order types may depend on the state of the blockchain at the time of the initiation call to determine the exact parameters for the fill. For instance, imagine a dutch auction where the pricing of the order depends on the block.timestamp at initiation time. This would mean that you would need some mechanism by which the filler could a) get this information and b) communicate this information to the destination chain. You could just add an arbitrary bytes field and leave it up to the filler/protocol to figure all of this out, but then that means the standard isn’t really saving the filler/protocol much in that case, while imposing this bytes field on all the protocols that don’t need this contextual info. Note: fillerData isn’t this data, because fillerData in your example is presumably the same filler data submitted to initiate. The contextual info I’m referencing isn’t known until the initiate call is complete.

Author: qinyu
Date: 2024-06-26T22:19:18.467Z

Thanks for pushing a standard for cross-chain transaction, we (paywithglide.xyz) are looking to adopt this standard to work with our cross-chain execution system
Per the Input struct and signature based initiate function, it seems the standard assumes the input token is always ERC20? Curious if this standard can work with native token as swapper input token?

/// @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;
}

Author: nambrot
Date: 2024-06-30T01:01:56.834Z

I definitely sympathize with the desire in keeping the EIP simple and understand that additional specificity, even if for optional extensions can be counter-productive. I admit that I generally bias towards the technical implementation considerations of standards, and less so the social aspects of them.

Adding post-fill actions would mean that some protocols might not implement part of the official standard and be forced to reject intents with that field, which might be confusing.

Wouldn’t that already be the case if post-fill actions are specified in orderData, i.e. they have to reject the intent since they do not know about the orderData schema?

maybe the right path is to have an extension specification

I do rather like the idea. To be honest, it doesn’t even have to be in the official specification, even a loose place for coordination I think would help implementors a lot to be compatible with each other. I do think it’s going to be hard to find a easily composable way of doing so. I.e. how do you express both an intent’s orderData implements both 0x01 and 0x02? You would probably have to then abi.encode both the identifiers and the data itself which can be a lot of data wrangling. We at Hyperlane had a somewhat similar problem when designing our HookMetadata which are also arbitrary bytes that different hooks can interpret differently, choosing the right trade-off between simplicity and expressiveness was definitely pretty hard.

Only a fraction of that information is needed at fill time.

Thanks for the context on this one. Now seems obvious in hindsight 

You could just add an arbitrary bytes field and leave it up to the filler/protocol to figure all of this out but then that means the standard isn’t really saving the filler/protocol much in that case, while imposing this bytes field on all the protocols that don’t need this contextual info

That’s kind of the case already if this is not specified in the spec, right? The filler will need protocol/settlement contract specific context to know how to fill on the destination chain. This does seem very similar to the above orderData question. I think in this case, an empty bytes field seems maybe worth the cost for protocols that don’t need this info, but you are right that the benefit from slightly more structural prescription might still not be worth it.
I think for both cases, maybe enough standardization at the tooling level is sufficient, and does not need to reflect itself in the spec itself.

Author: ankitchiplunkar
Date: 2024-07-15T12:38:35.767Z

Why is the chainID not part of the Input struct (in ResolvedCrossChainOrder) and is a top level variable?
In a chain abstracted world user balances will be pulled parallely from several chains for the same order. So it makes sense have different chainIDs available for different inputs.
For context, ERC-5792 is also updating where they will specify chainID on a per-call basis and not use the same chainID for all the batches. Quote from “Update EIP-5792: make atomicBatch chain-specific per-batch, not per-call (both in protocol messages and in normative prose) by bumblefudge · Pull Request #8626 · ethereum/EIPs”

Author: nicholaspai
Date: 2024-07-24T16:38:19.580Z

I’ve thought about how to respond to this a lot and I think ultimately I favor keeping originChainId at the top level of the Order struct.
The reason why is I think this standard is really designed to enable gasless cross chain intent orders and that means supporting AA frameworks with social momentum like Permit2 or 7702. I think using a single originChainId fits in best with these AA frameworks and is the easiest to support technically.
Also, I’m not sure in a vacuum how much I agree with this:

In a chain abstracted world user balances will be pulled parallely from several chains for the same order.

I think supporting multiple input chain ids makes the filler’s job (i.e. of handling input chain finality, tracking input chain accounts, tracking input chain market prices, etc.) exponentially more difficult and my instinct is this won’t be a large enough use case. If 7683 gets widely adopted and it becomes very common for users to be able to declare intents gasless-ly, then wouldn’t they be more likely to consolidate all of their funds on to a single “home” chain and use it to fund actions on arbitrary destination chains?
Thoughts?

Author: vaibhavchellani
Date: 2024-08-13T23:23:57.737Z

Thanks for putting in the work here and appreciate the open collaboration opportunity
Have been discussing this proposal with a few people and wanted to highlight a few important problems:

goal of making it easy for fillers is not fulfilled: The order and settlement contract are generic and impact essential details required by fillers to operate, meaning every filler will have to understand each order and how it impacts fulfillment anyway, the bytes while generic(add gas overhead) are important for fillers to interpret in order to make sure operations are done as user intended
fulfillment flow is non standardised: as someone pointed out above, the standard addresses only source-side of operations and not fulfillment breaking the loop, fillers will need to work with order specific fulfillment flows
the standard order is application specific: while the proposal attempts at being as generic as possible still constrains the application developer in a couple of ways already, the proposal is limit order based which tend to be fragile in async environments as highlighted here + order is incompatible with authorisations that span multiple input chains which makes it un-desireable to get to the desired UX

Ultimately, it seems like while making things easier for fillers is the intention here it doesnt get us there, fillers need to still interpret each order-type to fill it + it adds gas overhead due to additional bytes encoding/decoding that is needed. While at it, the standard order while being minimal is incompatible with upcoming applications which might not want to do limit orders and want to accept input tokens from multiple chains to provide the best experience
Keen to discuss and find solutions to above, it does seem like standardising at this layer is hard due to the tradeoff between finding a good enough standard interface while also making fillers generic.
curious to hear what others might think and again huge props for starting the discussion on this

Author: monokh
Date: 2024-08-14T08:32:36.832Z

Agree with @vaibhavchellani, the impact of gas is underestimated. While the standardisation of the data will help make cross chain orders readable through a wide variety of scenarios, The reality will be that intent systems will tend to optimise call data and specialise their contracts in order to provide competitive execution and features. An example of specialisation alluded to in the spec is permit2 which has a rough definition but you can also consider standard permit which is unrepresented.
A more verbose representation of intents that covers all scenarios which extends with time may be useful for off chain consumption. Where intent systems can publish their data optionally in this format.

Author: aureliusbtc
Date: 2024-08-14T18:14:14.914Z

vaibhavchellani:


goal of making it easy for fillers is not fulfilled: The order and settlement contract are generic and impact essential details required by fillers to operate, meaning every filler will have to understand each order and how it impacts fulfillment anyway, the bytes while generic(add gas overhead) are important for fillers to interpret in order to make sure operations are done as user intended



Wanted to echo this – In the way the generic bytes exist today, the proposed standard effectively serves as a thin framework for fillers. Fillers needing to interpret the bytes per implementation creates significant burden (orderData contains pretty essential details).
Keen to hear how people are thinking about fillers dealing with the numerous orderData types. This is obviously a tough balance to strike between standardization and allowing implementations to still create new interesting features while matching the standard.

Author: yyd106
Date: 2024-08-15T03:15:01.517Z

nicholaspai:

If 7683 gets widely adopted and it becomes very common for users to be able to declare intents gasless-ly, then wouldn’t they be more likely to consolidate all of their funds on to a single “home” chain and use it to fund actions on arbitrary destination chains?


I’m skeptical about this. Most users move assets for the sake of yield events, but they won’t consolidate assets back to their original locations just for the sake of consolidation. I believe that yield opportunities on different chains will cause users’ assets to be scattered all over the place.

Author: yawey92859
Date: 2024-08-21T08:43:08.827Z

Yikes, talking about fillers when stealing $ARB token incentives to run your centralized relayer versions?

Author: defi_moses
Date: 2024-08-22T18:33:23.101Z

An open standard makes sense for very simple scenarios (such as a cross-chain swap between USDC <> USDC), but for more complex actions may crowd out innovation, and may be counter-productive. Much of the innovation around cross-chain intents is packaging additional complexity with varying tradeoffs (gas etc.).
If relayers opt-into a singular standard for more generalized use cases, I worry that innovation from protocols like Klaster, who bundles a series of txns together, will suffer. Specificically defining, and likely reducing the scope would be a helpful activity

Author: Firekeeper
Date: 2024-09-03T22:26:51.311Z

uint32 for chain id won’t work for a lot of popular ones

Author: mrice32
Date: 2024-09-30T21:04:22.082Z

In response to feedback, we’re proposing some additions and changes to the standard as written. The draft PR is here: Updates to ERC 7683 by mrice32 · Pull Request #1 · across-protocol/ERCs · GitHub. We’ll be proposing this to the official ERC repo soon, but wanted to get public feedback here first.
Please take a look and let us know what you think.

Author: alexhooketh
Date: 2024-10-02T06:35:39.477Z

Hey Matt!
Should we use this version for building on 7683 instead?
A few feedbacks about it:

I think all interfaces and types pushed to the standard should be tried to be compiled first. Almost all of them are syntactically incorrect and/or supplied with incorrect Natspec. We fixed this internally, but not sure if we did it as designed ; )
It looks like Output is meant to show minimum inflows for the intent to be considered fulfilled. Would it make sense to introduce a bool fixedOutput that requires some inflows to be exactly the number specified in Output, rather than at least it? This is certainly a feature we’d want in our workflow, but not sure if we should implement it outside the struct.
Continuing this logical chain, Input might need to implement this flag too. In case some kind of Dutch auction is used, how will the filler know how much they’ll receive without knowing anything about the settlement contract (other than its 7683-compliance)?
I’m not sure if it makes sense for anyone but us given EVM-standardized destination settlement contract, but in case the destination chain is not fully/not EVM-compliant and does not use Ethereum’s 60’ SLIP-44 coin ID, would it make sense to store chain ID in a uint32, where EVM chain IDs must be < 0x80000000, and non-EVM chain IDs (SLIP-44 coin IDs) must be >=0x80000000? According to Chainlist, virtually all live EVM networks have their chain IDs fit to this requirement.
I believe that ERC-7683 will come outside the EVM environment fairly quickly, thanks to alt-VM rollups, and it seems that at least SVM, Starknet, and Fuel are using SLIP-44 for their key derivation.
If you go with implementing the feature above, destination settlement contract should not be enforced to comply with provided interface in case destinationChainId is >= 0x80000000. However, it’s not clear to me how to exactly enforce standardization of DSCs in a non-EVM environment. Maybe, you’ll have some thoughts about this.

Otherwise, everything looks good to me. I’m very excited about this standard and look forward to building on it.

Author: mrice32
Date: 2024-10-16T03:43:15.601Z

@alexhooketh


I think all interfaces and types pushed to the standard should be tried to be compiled first. Almost all of them are syntactically incorrect and/or supplied with incorrect Natspec. We fixed this internally, but not sure if we did it as designed ; )


Sorry about that. I’ve been making a bunch of changes recently based on comments on the PR, but haven’t actually compiled it in a while. Should be fixed.

It looks like Output is meant to show minimum inflows for the intent to be considered fulfilled. Would it make sense to introduce a bool fixedOutput that requires some inflows to be exactly the number specified in Output , rather than at least it? This is certainly a feature we’d want in our workflow, but not sure if we should implement it outside the struct.

I don’t think this is how the standard is intended to work (which may mean we may need to add some clarification). Meeting the minSpent  is not sufficient for an intent to be considered fulfilled. The DestinationSettler’s fill method will revert if the requirements for fulfillment aren’t satisfied. So, if the actual amount that’s needed to be paid to satisfy the intent depends on some state on the destination chain, for instance, the DestinationSettler can take that into account and revert if the filler doesn’t satisfy that requirement.
Does that make sense?


I’m not sure if it makes sense for anyone but us given EVM-standardized destination settlement contract, but in case the destination chain is not fully/not EVM-compliant and does not use Ethereum’s 60’ SLIP-44 coin ID, would it make sense to store chain ID in a uint32, where EVM chain IDs must be < 0x80000000, and non-EVM chain IDs (SLIP-44 coin IDs) must be >=0x80000000? According to Chainlist, virtually all live EVM networks have their chain IDs fit to this requirement.
I believe that ERC-7683 will come outside the EVM environment fairly quickly, thanks to alt-VM rollups, and it seems that at least SVM, Starknet, and Fuel are using SLIP-44 for their key derivation.


Yeah, the chainId question is hard because there’s no universal set of identifiers. Originally, I was thinking 64 bits where you reserve >=0x8000.... for non EVM chains, but I think there is some desire to support chainIds that are hashes of chain names, so it may make sense to go back to a 256 bit field, as is common outside of 7683.
Thoughts?


If you go with implementing the feature above, destination settlement contract should not be enforced to comply with provided interface in case destinationChainId is >= 0x80000000. However, it’s not clear to me how to exactly enforce standardization of DSCs in a non-EVM environment. Maybe, you’ll have some thoughts about this.


The interfaces described in the standard only apply if that contract exists on an EVM chain. If it’s a non-EVM chain, then the requirement does not apply, and the cross-compatible standard for that ecosystem would apply instead.
Maybe we could make that clearer, though. Thoughts?

Author: alexhooketh
Date: 2024-10-25T09:56:28.302Z

Does that make sense?

Hmm yes I think so. I’m thinking if 7685 needs some very basic elaborations in the workflow of intents and what use cases it tries to cover. Currently, it’s pretty complicated to dive into using it as an external team, as you need to guess what a certain thing was added for by the proposal’s creators.
Honestly, we’re not an intents-native team unlike, say, Across, so there might be some things that are necessary for more expressive usage of intents, just not ours. Hence why I don’t get them😅

Thoughts?

Yes, I think using 256-bit slot would be the best approach, especially given the recent ERC-7785 proposal.
Regarding your take on destination settlers, I think there should be some elaboration, like “if the settler contract == bytes32(0), then the intent can be filled through any logic”. However here comes a race condition issue, and I’m not sure if fixing it with temporary exclusivity (as in Across) is a good idea.

Author: Hugo0
Date: 2024-11-01T07:28:22.128Z

Hi! This looks really great. We have a super clear use case for this, at Peanut we do send-anything-receive-anything payments. I’d love to add support for 7683.
Is any solver actually live with this? Or any liquidity layer considering adding support any time soon?

Author: Jsg
Date: 2024-11-21T16:50:52.691Z

It will be good to understand if with Cross Chain intents we could achieve nearly free transactions across chains with no token swap?
From a payments processing point of view we need free transactions even if they are cross rollups. So Bob can pay Alice Flowers with USDC on Base and Alice can get in the chain she wants with virtually no cost. For more background you can read this article: hackmd (dot) io/@sprintcheckout/L1-L2-chain-fragmentation
Thanks.

Author: sanjaysb-okto
Date: 2024-12-16T07:47:53.808Z

/// @dev The max outputs that the filler will send. It's possible the actual amount depends on the state of the destination
	///      chain (destination dutch auction, for instance), so these outputs should be considered a cap on filler liabilities.
	Output[] maxSpent;
	/// @dev The minimum outputs that must be given to the filler as part of order settlement. Similar to maxSpent, it's possible
	///      that special order types may not be able to guarantee the exact amount at open time, so this should be considered
	///      a floor on filler receipts.
	Output[] minReceived;

I would like some clarifications in this part. The user is generating the intents. Filler will be accepting the intents and fulfilling them by fronting liquidity. So I assume the user’s funds should be locked in the source chain settlement contract. So the user should specify how much funds the contract can lock right? I think whatever amount we lock, the filler is not likely to get any more as if we do not lock, the user can just prevent the contract from getting more funds. So the max amount they are willing to spend for this intent should be specified upfront by the user, right? Am I missing something?

Author: eawosika
Date: 2024-12-17T23:09:36.851Z

https://research.2077.xyz/erc-7683-unifying-ethereum-with-cross-chain-intents
ERC-7683 simplifies multichain interactions by creating a unified framework for intent-based actions like token transfers and swaps. Many (including Vitalik) consider ERC-7683 a critical component of the plan to make L2s less fragmented and improve cross-chain UX for users.
This article (from 2077 Research explores how ERC-7683 aims to streamline execution, boost liquidity access, and enhance interoperability. We also discuss the challenges/considerations associated with ERC-7683 as well as the implications of adopting the standard for the wider ecosystem.
Hope you enjoy reading!
PS: Twitter thread summarizing the article: https://x.com/2077Research/status/1867232529696391650

Author: nicholaspai
Date: 2024-12-18T01:02:05.072Z

So I assume the user’s funds should be locked in the source chain settlement contract.

I think this is true for most settlement systems today but its not prescribed by the ERC.

So the user should specify how much funds the contract can lock right?

So the user doesn’t need to set the minReceived, in fact this should ideally be set by the settlement contract where the 7683 is open-ed. A very simple vanilla settlement system might return the exact amount input by the user as the minReceived, while others might charge a fee.
Similarly with maxSpent, its up to the settlement system to signal to the filler the maximum of outputs that the filler will owe to the user on the destination chain settlement system.
Also, the settlement system should ideally respect whatever the minReceived and maxOutputs values are set to, otherwise fillers won’t be able to trust the system or use it reliably.

So the max amount they are willing to spend for this intent should be specified upfront by the user, right?

In summary, I think most settlement systems would set the max amount that the filler should be expected to spend based on the user’s input amount, however the settlement system chooses this input amount.

Author: sanjaysb-okto
Date: 2024-12-18T07:22:41.206Z

makes sense. However I want to understand, in this scenario isn’t there a minimum that the user need to specify on the output. Here we are specifying the maxSpent. We do not specify any minimum value the filler needs to fulfil on the destination chain.
How will the settlement system know whether the fulfilment is satisfying the user intent. The filler should fulfil some minimum amount for the user right?

Author: 0xbuzzlightyear
Date: 2024-12-18T10:14:15.896Z

I believe we should try to standardize subtypes via ERCs. This may already be the goal when saying a subtypes repository, but this specification is better in my opinion.
Instead of:

All sub-types SHOULD be registered in a subtypes repository to encourage sharing of sub-types based on their functionality.
I suggest for it to be changed to something like what is in EIP-7786:
Sub-types SHOULD be standardize by publishing them as ERCs to encourage sharing of sub-types based on their functionality.

Author: nicholaspai
Date: 2024-12-18T17:27:26.480Z

How will the settlement system know whether the fulfilment is satisfying the user intent. The filler should fulfil some minimum amount for the user right?

This is where the settlement-specific logic comes into play. Settlement systems might force the order to contain a settlement-specific struct including information like outputAmount.
The ERC is designed primarily for improving filler experience.

Author: sanjaysb-okto
Date: 2024-12-19T04:33:44.762Z

I agree that different settlement systems can have different settlement logics. And I am also aligned with filler experience improvement.
As I understand, ResolvedCrossChainOrder  which is the response of resolve and resolveFor functions should contain the terms of settlement for filler to know how he can successfully fulfil this intent.
There is no room for settlement specific metadata in that struct right now. If we add the additional settlement specific metadata the struct would change and no longer adhere to the standard, isn’t it?

Author: sanjaysb-okto
Date: 2024-12-31T05:30:25.485Z

I think the recommendation here is to make use of the fill Instruction to define terms of settlement. This can work. But I think the terminology is a bit confusing here.

Author: harsh132
Date: 2024-12-31T09:12:03.941Z

Shouldn’t the fill function in the destination settler be payable?
Current:
function fill(bytes32 orderId, bytes calldata originData, bytes calldata fillerData) external;

Proposing:
function fill(bytes32 orderId, bytes calldata originData, bytes calldata fillerData) external payable;

Rationale: This will provide the filler to pass native tokens to be used in the fulfilment of the request.

Author: kombi
Date: 2025-02-18T11:17:05.995Z

GM, Kombi here.
How does the filler prove they have indeed made payment?
The EIP doesn’t cover exactly how settlement is done.
Can you point me to resources that explain how filling is verified and settlement done?