EIP-5792 defines a baseline JSON-RPC API for a communication between wallets and dapps, and provides an ability to extend the base protocol with "capabilities".
This proposal defines a set of "capabilities" the wallets may want to implement in order to provide a comprehensive support for Account Abstraction (AA).
These "capabilities" enable passing any data that may be required when using a Paymaster contract, allows limiting the time range during which the UserOperation is considered valid, provides a way for the dApp to manually control the semi-abstracted nonce and AA-specific gas limits of the UserOp, and even allow the dApp to take part in selecting the EIP-7702 account implementation.
ERC-4337 introduced Account Abstraction, enabling Smart Contract Accounts to function as first-class citizens in Ethereum. However, while ERC-4337 and ERC-7769 define a low-level RPC API for Account Abstraction, they do not specify a way for advanced AA-aware dApps to communicate their supported features and parameters to the advanced AA Wallet Applications.
This ERC addresses the issue by defining a structured set of capabilities tailored for AA-aware dApps and Wallet Applications.
It utilises the EIP-5792 wallet capability model to express some of the critical aspects of AA, ensuring dApps can seamlessly adapt to different AA Wallets without requiring custom solutions.
All actions in Account Abstraction within the context of EIP-5792 must be done on a single chain and atomically.
We define the following list of new "capabilities" which together cover many features necessary for Account Abstraction. Note that use of Paymasters managed by a "paymaster web service" is described in ERC-7677.
This capability is designed to be used with EIP-7702 and requests the Wallet Application to provide an EIP-7702 authorization tuple for the specified address as part of the AA transaction.
Identifier:
eip7702Auth
Interface:
type SetCodeForEOACapabilityParams = Record<
{
account: `0x${string}`, // EOA address
delegation: `0x${string}`, // delegation address
}
>
Supporting Wallet Applications MUST generate an EIP-7702 compatible transaction that sets a code of the account EOA address
to the code of delegation specified in the request.
The purpose of this capability is allowing applications to integrate with Paymasters that do not require the Wallet Application to resolve any dynamic configuration.
The application may hard-code or resolve these parameters first and pass them with this capability.
Identifier:
staticPaymasterConfiguration
Interface:
type StaticPaymasterConfigurationCapabilityParams = Record<
{
paymaster: string;
paymasterData: string;
paymasterValidationGasLimit: `0x${string}`;
paymasterPostOpGasLimit: `0x${string}`;
}
>;
The purpose of this capability is allowing the applications to explicitly specify the time range during which the requested operations will be valid after signing.
Identifier:
validityTimeRange
Interface:
type ValidityTimeRangeCapabilityParams = Record<
{
validAfter: `0x${string}`, // operation valid only after this timestamp, in seconds
validUntil: `0x${string}` // operation valid only before this timestamp, in seconds
}
>
The Wallet Application MUST verify the time range [validAfter..validUntil] is valid and present it to the
user in a human-readable way for confirmation as part of the transaction information.
The Smart Contract Account MUST specify the time range [validAfter..validUntil] as the transaction validity range.
The purpose of this capability is allowing the applications to explicitly specify the components of the semi-abstracted nonce as defined in ERC-4337.
Identifier:
multiDimensionalNonce
Interface:
type MultiDimensionalNonceCapabilityParams = Record<
{
nonceKey: `0x${string}`,
nonceSequence: `0x${string}`
}
>
For Smart Contract Accounts that support multidimensional nonce values, the wallet must specify these parameters during the actual on-chain execution of the batch.
The purpose of this capability is allowing the applications to override the Wallet Application's suggested values for all gas-related parameters.
This capability provides very low-level access to the underlying Account Abstraction protocol and should only be used by applications closely coupled to a specific version of a specific protocol. It may also prove useful in the context of development and debugging.
It is generally recommended that production dapps rely on higher-level features of Wallet Applications instead.
Identifier:
accountAbstractionGasParamsOverride
Interface:
type AAGasParamsOverrideCapabilityParams = Record<
{
preVerificationGas?: `0x${string}`,
verificationGasLimit?: `0x${string}`,
callGasLimit?: `0x${string}`,
paymasterVerificationGasLimit?: `0x${string}`,
paymasterPostOpGasLimit?: `0x${string}`,
maxFeePerGas?: `0x${string}`,
maxPriorityFeePerGas?: `0x${string}`
}
>
Notice that all fields in the AAGasParamsOverrideCapabilityParams are optional.
Only the values that callers want to override must be provided.
Wallet Applications should warn the users about the overrides being supplied by the call and use these values instead.
Wallet Applications may choose to reject calls with conflicting configurations.
eip7702AuthThis is by far the most sensitive capability in the document. There is no limit to the damage that can be done by signing the wrong capability.
Wallet Applications MUST take extreme care when working with EIP-7702.
Wallet Applications MUST maintain a strict shortlist of well-known and publicly audited Smart Contract Account
implementations that are acceptable as delegation.
Authorization is an extremely sensitive operation and any vulnerability or malicious code in delegation will
result in complete draining of the account.
staticPaymasterConfigurationThis capability has an opportunity to provide the paymaster and paymasterData values for the call.
Incorrect or malicious values can be an attack vector.
For example, a Paymaster contract may hold approvals for ERC-20 tokens which may be drained this way.
The Wallet Applications MUST make sure the provided values correspond to user intent.
Fundamentally, this is not very different to how regular transactions' calldata must be verified.
Copyright and related rights waived via CC0.