This EIP is more relevant than ever, particularly with the advent of EIP-7702.
As @chaitanyapotti and @naivesheep point out, the text no longer matches the specification.
For what it’s worth, I think adding chainId at the “call” level rather than the “request” level introduces quite a lot of complexity, and I am not sure what the upside is. Are there motivating use cases which might help?
I think there is value in standardising the identifier, even if it’s just based on a hash of the calls plus some salt. I don’t think it’s a hard requirement that any wallet needs to be able to fetch the status - in the current setup, wallets already only see transactions initiated by other wallets once they’ve landed onchain as a txhash (some may monitor the mempool, but I don’t know how much that works). But I do think it is helpful if the identifier is somewhat predictable.
A salt / nonce-equivalent might also prove useful for wallets - the current specification doesn’t seem to have many guardrails preventing accidental replays / allowing for idempotency, and it might be useful if the wallet has an easy way to say “you already submitted this bundle” (of course sometimes you might want to repeat the same calls)
In terms of callStatus, I don’t think the current spec is that helpful. Why wouldn’t we specifically report the receipt per call, something like:
type GetCallsResult = {
status: 'PENDING' | 'CONFIRMED';
calls: {
call: {
to?: `0x${string}` | undefined;
data?: `0x${string}` | undefined;
value?: `0x${string}` | undefined; // Hex value
chainId?: `0x${string}` | undefined; // Hex chain id
};
receipt: `0x${string}` | undefined; // Note that multiple calls might have the same receiptId
}[]
receipts?: {
// receipt fields
}[];
};
Relatedly, I think there should be more specification of the expected failure behaviour:
- If a call fails in simulation, should the bundle be submitted?
- What happens if one of the calls fails onchain? (e.g. if it reverts / runs out of gas)
I think in either case we need a “Status” to handle those cases.
I don’t really see the value of the showCallsStatus, I think that wallets should already be displaying the in progress calls in their existing UI, and I think if the GetCallsResults returns the info per call that gives apps enough to provide a meaningful UI themselves.
There is some discussion in the thread already around atomicity, I think it’s reasonable to provide this is a capability, but I note that the other capability example in the spec (paymasterService?) is maybe more of a “hint” than a requirement, so I think it’s worth clarifying where capabilities in sendCalls fall on that spectrum.
A final note is that “version” appears a couple of times in the spec, I think a wallet should also be able to specify what “version” of the spec it supports (maybe that is part of capabilities?)
I am excited to see innovation at the app / wallet interface, so would love to see progress on this EIP!