-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update EIP-5792: make atomicBatch chain-specific per-batch, not per-call (both in protocol messages and in normative prose) #8626
base: master
Are you sure you want to change the base?
Conversation
File
|
Update eip-5792.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
requesting that we make the expected behavior for calls across chains clearer. specifically, do calls on one chain need to land before executing calls on the next chain? or can they be made closer to in parallel?
i would assume parallel but what do i know about defi. my intuition is that either way, it should be a SHOULD for now and future EIPs would extend the capability definition (or propose an alternative) to be more explicit or opinionated unless people working on such use cases or mechanisms want to speak up and argue one way or the other? |
Hey @lukasrosario that's a great question but I think it applies for both single-chain and multi-chain Atomic Batching What is the intended behavior for ordering even in a single-chain scenario? Should the Wallet respect the order of the items in the array? Ordering can be lost depending on the serialization and deserialization process involved I think the Atomic Batching needs to have clearer expectations even without the changes included in this PR |
i'm not sure how can you provide such behavior: there is no way to guarantee cross-chain atomic batch, so it is "Best effort" at best. It is an excellent feature to have - but not something we can provide at the wallet level API. |
This can be closed in favor of the already merged #8771 |
As per a conversation with @pedrouid and @jxom