This proposal defines complementary JSON-RPC methods to EIP-5792's wallet_sendCalls to enable an Application to sign over a call bundle (instead of the Wallet). Methods defined in this proposal are purposed for the Application to sign over calls and submit them to the Wallet with an accompanying signature. This is in contrast to wallet_sendCalls, where a Wallet itself signs over the call bundle.
Applications are increasingly seeking to use session keys and scoped permissions to make transactions on a user's behalf, without the user having to approve and sign each transaction in their wallet's interface. One example is an application that automates a user's decentralised exchange trading. As Smart Contract Accounts (SCAs) contain arbitrary execution interfaces that lead to varying calldata formats, it is not possible for an Application to know how to sign over an action for any arbitrary Account implementation, without maintaining a mapping of Account implementations to their signing logic. Apps need a simple way to request the payload that their session keys should sign, given a call or set of calls they wish to make, and a way to execute the calls once signed.
In this specification, we define two new JSON-RPC methods: wallet_prepareCalls and wallet_sendPreparedCalls.
wallet_prepareCallsInstructs a Wallet to prepare a call bundle according to the Account's implementation. It returns a digest of the call bundle to sign over, as well as the parameters required to fulfil a wallet_sendPreparedCalls request (ie. capabilities, chainId, context, and version).
After calling
wallet_prepareCalls, consumers are expected to sign over thedigestand submit thesignatureand prepared calls to the Wallet viawallet_sendPreparedCalls.
The request is identical to that of
wallet_sendCalls.
The response is intended to be forwarded to
wallet_sendPreparedCalls(minus thedigest).
wallet_sendPreparedCallsInstructs a Wallet to execute a prepared call bundle (response of wallet_prepareCalls) with an accompanying signature.
The request is identical to the response of
wallet_prepareCalls, except that it includes asignature.
The response is identical to that of
wallet_sendCalls.
These endpoints extend the interface established by EIP-5792, given the emergent needs of application developers.
Adding new endpoints for this specific use case is simpler than adding additional options to the wallet_sendCalls endpoint.
Surfacing the prepared calls should be relatively simple for wallets, who already need to do preparation internally in order to support wallet_sendCalls, and who then submit signed calls on chain.
This specification is currently compatible with EIP-5792 and does not introduce breaking changes to existing wallet_sendCalls flows.
wallet_sendCalls; wallets compliant with EIP-5792 continue to work unchanged.wallet_prepareCalls mirrors the wallet_sendCalls request shape and returns values intended to be forwarded to wallet_sendPreparedCalls, preserving field formats such as capabilities, chainId, context, and version.wallet_sendPreparedCalls consumes the same data the wallet would otherwise construct internally for EIP-5792, with the addition of an externally produced signature.Key authorization and scope: Wallets MUST verify that the provided key.publicKey is authorized for the account and that the requested capabilities are within that key’s permissions (scopes, limits, validity windows).
Prehashing consistency: Honor key.prehash consistently. A mismatch between signer and verifier (e.g., double-hashing vs prehashed input) can cause verification failures. Wallets SHOULD fix the hash function per key type.
Preparation-to-execution linkage: Wallets SHOULD ensure wallet_sendPreparedCalls corresponds to a digest they could have produced (e.g., by recomputing it) and MAY track a preparation identifier and/or validity window to mitigate long-lived replay.
WebAuthn/origin considerations: For webauthn-p256, prefer user-verification and origin-bound credentials. Applications SHOULD keep session keys non-extractable and hardware-backed where available, and avoid presenting opaque digests for end-user approval.
Resource usage and DoS: Wallets MAY rate-limit wallet_prepareCalls, cap bundle sizes, and validate inputs early to avoid expensive context generation for malformed or adversarial requests.
Copyright and related rights waived via CC0.