ERC-7683: Cross Chain Intents Standard

ERCs
, , ,
1

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.

PR:

5 Likes
2

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

A few technical questions

  1. 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?
  2. on the other hand, assuming this standard just wanna solve crosschain token settlement, how does ResolvedCrossChainOrder include attestants from the settlement chain?
3

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

  1. 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.
  2. 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
2 Likes
4

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

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!

1 Like
5

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

1 Like
6

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

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

1 Like
7

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

1 Like