ERC-7683: Cross Chain Intents Standard

ERCs
, , ,
49

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?

50

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.

51

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.

2 Likes
52

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?

53

What is the story/plan here for the chainId and originChainId of chains that arenā€™t Ethereum L2s? Like, what if we want to submit an intent on Ethereum towards a L2 on Cosmos, on Sui or on Solana, or vice-versa?

It looks like weā€™d need some sort of namespace or some sort of standardized way to get a canonical chainId for any kind of chain in any ecosystem, with negligible risks of collisionā€¦

Thankfully using a uint256 leaves us with a lot of flexibility there.

My initial idea for my own custom services would be to use the hash of something deterministic relying on human-readable namespaces, such as:

  • Hash("Ethereum-EIP155-1") for Ethereum mainnet
  • Hash("Cosmos-cosmosevm-1-EVMChainID-9000") for Cosmos mainnet which has a dual chain id principle

The advantage being: chances of a clash are then negligible.

Any thoughts on that front?

It seems there have been some other proposals out there that have the same issue and tried to solve it with for example the chainagnostic one, CAIPs/caip-2.

But I havenā€™t found any concrete or ā€œuniversalā€ way of doing this.

54

Weā€™re working on an iteration of this ERC that builds on ERC-7930: Interoperable Addresses, which builds on CAIP-2.

ERC-7786 is also using the same address format.

1 Like
55

As part of the Open Intents Framework weā€™re discussing significant changes to this ERC, in order to address problems that various implementers have identified.

Are you implementing or integrating with this ERC or do you plan to? If so please comment below and/or DM me contact details.

56

Wrote up a little interface based off off ERC-7683 that I think would potentially work for cross-VM cross-chain intents. I should add that Iā€™m strongly in favour of singular standards barring the case where a single standard is much more inefficient, I do think the case for an eXtended version is becoming much more palatable hence positing this as an idea. XERC7683/src/IXERC7683.sol at master Ā· QEDK/XERC7683 Ā· GitHub

57

What happens if an intent has expired or is not processed by the filler?

58

The de-facto assumption is that itā€™s a developer concern. ERC-7683 serves as a baseline and liberal in terms of actual implementation details.

59

Just to clarify, do you mean ERC7683 defines the structs and interfaces for cross-chain intents, while different protocols or use cases can have their own implementations? In that scenario, solvers would then declare which implementations they support, correct? Iā€™m only trying to better understand the intention behind this ERC.

60

Hi all, Iā€™ve opened a CAIP draft that complements 7683 for a wallet-signed envelope with a stable qHash. Thereā€™s live code and tests. Would love some eyes on this and feedback.

CAIP PR:

Reference (open source):

61

Following up on the research presented in

Together with the original ERC authors weā€™re publishing a redesign of the ERC:

2 Likes
62

The standardā€™s proof-agnosticism is one of its best design decisions ā€” but it leaves one leg structurally unserved: Bitcoin. Every verification primitive settlement contracts use today (messaging bridges, optimistic oracles, attestation committees) connects EVM-style chains to each other. None of them can verify a native Bitcoin payment, so intents that begin or end in actual BTC fall back to MPC committees or wrapped assets ā€” reintroducing exactly the trust the intent architecture tries to remove.

Iā€™ve built the module that fills that slot: Keystone ā€” a Bitcoin settlement module designed to sit underneath ERC-7683 as the verification primitive for the Bitcoin leg. A solver locks the destination asset bound to a unique per-order Bitcoin address; the user pays native BTC; settlement is released by verification (optimistic single-round fraud proofs today; a measured succinct path ā€” 37 s core proof on CPU, 225,820 gas Groth16 verification on-chain ā€” for the trustless version). No custody, no committee, no wrapped token at any point.

Code, differential test suite against a Rust reference verifier, and a one-command demo: GitHub - keystone-settlement/keystone Ā· GitHub ā€” full write-up with trust model and related work: keystone/docs/ANNOUNCEMENT.md at main Ā· keystone-settlement/keystone Ā· GitHub

Feedback from folks whoā€™ve implemented 7683 settlers would be especially valuable ā€” particularly on whether the order-binding pattern (unique scriptPubKey per order enforced on-chain) composes cleanly with existing origin-settler flows.