XERC-7683: An extended ERC-7683 for cross-VM intents

Research & Explorations
1

Before we delve into the actual implementation details, I posit two ideas:

  • A unified interface that amalgamates cross-chain and cross-VM intents is required
  • A singular standard is the preferred method of resolution in almost all cases – barring if the single standard would be inefficient, or the general populace is unlikely to come to a definite conclusion on a unified standard

Aligning ourself with existing best standards is the baseline expectation, hence I propose an extended version of ERC-7683, namely XERC-7683 (i.e. eXtended ERC-7683).

The primary point of contention in the existing standard is the expectation of uint256 chainId as origin or destination chain IDs. There has been some level of conversation as to how non-EVM chains can be parsed as chain IDs, ranging from keccak256(namespace-reference) to designating uint256(chainId) <= type(uint64.max) as EVM chain IDs and assigning rest of the chain IDs for non-EVM chains. I think both are OK approaches but both are fundamentally inferior to simply making the ERC CAIP-2 compliant. Hypothetically, by making addresses CAIP-10 compliant, we can get rid of extra fields relating to domains altogether but since we expect a lot of functionality to revolve around domains and addresses – such as based on a particular domain we can gain knowledge of how to parse a particular recipient address (the most notable of which are EVM addresses which use 20 bytes instead of 32); in the long run, it’s better to preserve a separate domain field and 32-byte addresses.

The extended functionality itself is simple and just requires developers and solvers to integrate with being able to parse either or or both ERCs. A simple table to understand the trade-offs can look like this:

Standard Cross-VM support EVM support
ERC-7683 Possible, with some considerations De-facto, preferential
XERC-7683 First-class Inclusive, non-preferential

To round it off, we can practically talk about the costs and benefits of adopting either standard. The primary cost of adopting XERC-7683 is slightly increased gas costs for each transaction, either an xopen() or fill(), primarily due to the nature of strings being a dynamic data type. The direct benefit of which is that you can reuse the same interface for cross-VM or EVM intents. However, if you know your protocol will permanently interact with EVM chains, it is probably better to pick ERC-7683 and avoid the extraneous hassle.

See XERC-7683 usage in practice in the Nexus contracts repository (WIP): GitHub - availproject/nexus-contracts

4 Likes
2

How do the solver determine the address type of the user if they are not aware of a domain? Do they have to store maps of all domains to their address types? I’m curious of a case where the intents may reach solvers who can perform an action on the destination chain, but are not aware of the origin chain details.

2 Likes
3

How do the solver determine the address type of the user if they are not aware of a domain?

CAIP-10 addresses have pre-determined namespace information as part of the account ID.

account_id:        chain_id + ":" + account_address
chain_id:          [-a-z0-9]{3,8}:[-_a-zA-Z0-9]{1,32} (See [CAIP-2][])
account_address:   [-.%a-zA-Z0-9]{1,128}

That said, the current proposal explicitly requires a domain and is intentionally not CAIP-10-compliant.

Do they have to store maps of all domains to their address types?

No, see above. But also not relevant for XERC-7683.

I’m curious of a case where the intents may reach solvers who can perform an action on the destination chain, but are not aware of the origin chain details.

This does not apply since intents are opened on a single origin chain. For fills, since some or all order data is included as filler data, the contract can trivially know whether the actual order is fillable.