ERC-7683: Cross Chain Intents Standard

ERCs
, , ,
18
  • 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.
1 Like