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:
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:
Hi @marktoda, cross-chain intents, this is an important space to solve on. Thanks for proposing it!
A few technical questions
hey @xinbenlv iâll try to chime in here.
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 ordersAgreed, 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!
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).
Should we consider not only EVM chains but also NO-EVM chains?
0. orderData is a good design for support no-evm chain
/// @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
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