Skip to content
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: multi-chain wallet_sendCalls #8771

Merged
merged 8 commits into from
Aug 7, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 13 additions & 8 deletions EIPS/eip-5792.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,13 +40,13 @@ The capabilities field is how an app can communicate with a wallet about capabil

The wallet:

* MUST send these calls in the order specified in the request
* MUST send the calls on the same chain identified by the request's `chainId` property
* MUST send the calls in the order specified in the request
* MUST send the calls on the same chain identified by the call's `chainId` property
* MUST NOT await for any calls to be finalized to complete the batch
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you explain why you think we should enforce this? I'd expect this to be up to the wallet, until we have the other capability we talked about which would enforce waiting for calls to be mined across chains.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that we would enforce the behavior to always be "parallel" by default

So the new capability would be "sequential" if available

But my take is that either way it should be deterministic by the spec rather than wallet-dependent

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm just seeing this. I do feel like generally order matters to devs, but trying to sequence multi chain calls is probably too difficult. Too hard to know when the output of one will land on the other chain, if I am, say, funding my account on chain A from chain B

* MUST NOT send any calls from the request if the user rejects the request
* MAY revert all calls if any call fails
* MAY send all the function calls as part of one transaction or multiple transactions, depending on wallet capability
* MAY send all calls as part of one or more transactions, depending on wallet capability
* SHOULD stop executing the calls if any call fails
* MAY reject the request if the request chain ID does not match the currently selected chain ID
* MAY reject the request if the from address does not match the enabled account
* MAY reject the request if one or more calls in the batch is expected to fail, when simulated sequentially

Expand All @@ -55,12 +55,12 @@ The wallet:
```typescript
type SendCallsParams = {
version: string;
chainId: `0x${string}`; // Hex chain id
from: `0x${string}`;
calls: {
to?: `0x${string}` | undefined;
data?: `0x${string}` | undefined;
value?: `0x${string}` | undefined; // Hex value
chainId?: `0x${string}` | undefined; // Hex chain id
}[];
capabilities?: Record<string, any> | undefined;
};
Expand All @@ -74,18 +74,19 @@ type SendCallsResult = string;
[
{
"version": "1.0",
"chainId": "0x01",
"from": "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
"calls": [
{
"to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
"value": "0x9184e72a",
"data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"
"data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
"chainId": "0x01",
},
{
"to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
"value": "0x182183",
"data": "0xfbadbaf01"
"data": "0xfbadbaf01",
"chainId": "0x01",
}
],
"capabilities": {
Expand Down Expand Up @@ -128,6 +129,7 @@ type GetCallsResult = {
topics: `0x${string}`[];
}[];
status: `0x${string}`; // Hex 1 or 0 for success or failure, respectively
chainId: `0x${string}`;
blockHash: `0x${string}`;
blockNumber: `0x${string}`;
gasUsed: `0x${string}`;
Expand Down Expand Up @@ -163,6 +165,7 @@ As with the return value of `wallet_sendCalls`, the batch identifier may be any
}
],
"status": "0x1",
"chainId": "0x01",
"blockHash": "0xf19bbafd9fd0124ec110b848e8de4ab4f62bf60c189524e54213285e7f540d4a",
"blockNumber": "0xabcd",
"gasUsed": "0xdef",
Expand Down Expand Up @@ -246,6 +249,8 @@ The capabilities below are for illustrative purposes.

Like the illustrative examples given above and other capabilities to be defined in future EIPs, the capability to execute calls delivered via the above-defined methods in a single transaction can be attested by the wallet in boolean form.

This capability is expressed separately on each chain and should be interpreted as a guarantee only for batches of transactions on that chain; batches including calls to multiple chains is out of scope of this capability and this specification.
pedrouid marked this conversation as resolved.
Show resolved Hide resolved

If a wallet has affirmatively expressed this `atomicBatch` capability to a calling application, it MUST submit calls submitted with `wallet_sendCalls` as part of a single transaction.

#### `atomicBatch` Capability Specification
Expand Down
Loading