Aa 429 new aa capabilities erc

ERCS/erc-xxxx.md

@@ -0,0 +1,201 @@
+---
+eip:
+title: Wallet Capabilities for Account Abstraction
+description: New Wallet Capabilities providing a way for dApps and Account Abstraction wallets to communicate
+author: Yoav Weiss (@yoavw), Alex Forshtat (@forshtat), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn)
+discussions-to:
+status: Draft
+type: Standards Track
+category: ERC
+created:
+requires: 5792, 7702
+---
+
+## Abstract
+
+[EIP-5792](./eip-5792) defines a baseline JSON-RPC API for a communication between wallets and dapps.
+With EIP-5792, apps and wallets can communicate about any advanced features using "capabilities" - extensions
+to the base protocol that must be defined in separate documents.
+
+This proposal defines a set of "capabilities" the wallets may want to implement in order to provide a
+comprehensive support for Account Abstraction.
+
+## Motivation
+
+[ERC-4337](./eip-4337.md) introduced Account Abstraction and enabling Smart Contract Accounts to function as first-class citizens in Ethereum.
+However, while [ERC-4337](./eip-4337.md) and [ERC-7769](./eip-7769.md) defines a low-level RPC API for Account Abstraction,
+it does 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 Account Abstraction dApps and Wallet Applications.
+
+It extends the [EIP-5792](./eip-5792) wallet capability model to encompass critical aspects of AA,
+ensuring dApps can seamlessly adapt to different AA Wallets without requiring custom solutions.
+
+## Specification
+
+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](./eip-7677).
+
+### Create [EIP-7702](./eip-7702) Authorization Capability
+
+This capability is designed to use with [EIP-7702](./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:
+
+```typescript
+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.
+
+Attention! Wallet Applications MUST maintain a strict shortlist of well-known and publicly audited Smart Contract Account
+implementations that can be 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`.
+
+### Static Paymaster Configuration Capability
+
+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:
+
+```typescript
+type StaticPaymasterConfigurationCapabilityParams = Record<
+  {
+    paymaster: string;
+    paymasterData: string;
+    paymasterValidationGasLimit: `0x${string}`;
+    paymasterPostOpGasLimit: `0x${string}`;
+  }
+>;
+```
+
+### Validity Time Range Capability
+
+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:
+
+```typescript
+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.
+
+### Multidimensional Nonce Capability
+
+The purpose of this capability is allowing the applications to explicitly specify the components of the
+multidimensional nonce as defined in [ERC-4337](./eip-4337.md).
+
+Identifier:
+
+`multiDimensionalNonce`
+
+Interface:
+
+```typescript
+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.
+
+### Account Abstraction Gas Parameters Override Capability
+
+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:
+
+```typescript
+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.
+
+## Rationale
+
+## Security Considerations
+
+### `eip7702Auth`
+
+This 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](./eip-7702).
+
+### `staticPaymasterConfiguration`
+
+This 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](./eip-20.md) 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
+
+Copyright and related rights waived via [CC0](../LICENSE.md).