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?
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
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.
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.
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.
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