-
Notifications
You must be signed in to change notification settings - Fork 0
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
AA-429: Create ERC-5792 "capabilities" ERC for Account Abstraction #12
base: master
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,201 @@ | ||
--- | ||
eip: | ||
title: Set of Wallet Capabilities for Account Abstraction Applications | ||
description: A way for apps and Account Abstraction wallets to communicate more advanced parameters of Account Abstraction operations | ||
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 | ||
|
||
## Specification | ||
|
||
### Shared configuration | ||
|
||
All actions in Account Abstraction within the context of EIP-5792 must be done on a single chain and atomically. | ||
This means all requests to the `wallet_sendCalls` methods MUST be done: | ||
|
||
1. With the `atomicBatch` capability enabled | ||
2. With the `chainId` set to the same value in all calls | ||
|
||
### Static Paymaster Configuration Capability | ||
|
||
Note that use of Paymasters managed by a "paymaster web service" is described in [ERC-7677](./eip-7677). | ||
|
||
Identifier: | ||
|
||
`staticPaymasterConfiguration` | ||
|
||
Interface: | ||
|
||
```typescript | ||
type StaticPaymasterConfigurationCapabilityParams = Record< | ||
`0x${string}`, // Chain ID | ||
{ | ||
paymaster: string; | ||
paymasterData: string; | ||
paymasterValidationGasLimit: `0x${string}`; | ||
paymasterPostOpGasLimit: `0x${string}`; | ||
} | ||
>; | ||
``` | ||
|
||
### On-chain Query Paymaster Configuration Capability | ||
|
||
Identifier: | ||
|
||
`onChainQueryPaymasterConfiguration` | ||
|
||
Interface: | ||
|
||
```typescript | ||
type OnChainQueryPaymasterConfigurationCapabilityParams = Record< | ||
`0x${string}`, // Chain ID | ||
{ | ||
target: `0x${string}`, // contract to query for Paymaster configuration | ||
context: `0x${string}`, // hex-encoded byte array to pass to the configuration provider | ||
} | ||
> | ||
``` | ||
|
||
We then define the following Solidity interface: | ||
|
||
```solidity | ||
|
||
struct PaymasterConfiguration { | ||
address paymaster; | ||
bytes paymasterData; | ||
uint256 paymasterValidationGasLimit; | ||
uint256 paymasterPostOpGasLimit; | ||
} | ||
|
||
interface IPaymasterConfigurationResolver { | ||
function getPaymasterConfiguration(bytes operation, bytes context) external; | ||
forshtat marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
|
||
``` | ||
|
||
The wallet MUST perform an ABI-encoding of the entire `operation` object and make a view call | ||
to the `getPaymasterConfiguration` function of the `target` address. | ||
|
||
If the view call fails or returns an invalid data, the `wallet_sendCalls` method must fail and return with an error. | ||
|
||
### Validity Time Range Capability | ||
|
||
Identifier: | ||
|
||
`validityTimeRange` | ||
|
||
Interface: | ||
|
||
```typescript | ||
type ValidityTimeRangeCapabilityParams = Record< | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand the time-range: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wouldn't wallets want to allow dapps to specify the validity range? Seems like artificially limiting a feature we worked hard to add. |
||
`0x${string}`, // Chain ID | ||
{ | ||
validAfter: `0x${string}`, // operation valid only after this timestamp, in seconds | ||
validUntil: `0x${string}` // operation valid only before this timestamp, in seconds | ||
} | ||
> | ||
``` | ||
|
||
The wallet must then 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. | ||
|
||
### Multidimensional Nonce Capability | ||
|
||
Identifier: | ||
|
||
`multiDimensionalNonce` | ||
|
||
Interface: | ||
|
||
```typescript | ||
type MultiDimensionalNonceCapabilityParams = Record< | ||
`0x${string}`, // Chain ID | ||
{ | ||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The wallet MAY specify a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We probably need such an API. However, it can be hacked by calling the Nonce Manager directly, but that also gets very version - specific. |
||
|
||
### Account Abstraction Gas Parameters Override Capability | ||
|
||
Identifier: | ||
|
||
`accountAbstractionGasParamsOverride` | ||
|
||
Interface: | ||
|
||
```typescript | ||
type AAGasParamsOverrideCapabilityParams = Record< | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a kind of low-level field override. better separate it to a different ERC. |
||
`0x${string}`, // Chain ID | ||
{ | ||
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. | ||
|
||
In case `paymasterVerificationGasLimit` or `paymasterPostOpGasLimit` are provided, | ||
wallets should warn the users about this happening but use these values instead of | ||
the ones generated by any other capability. | ||
Wallets may choose to reject such configurations or request the user input in this case. | ||
Such a combination of features is only expected to be used in development and is very risky to use in production. | ||
|
||
### Set Externally Owned Account Code Capability | ||
|
||
This capability is designed to use with [EIP-7702](./eip-7702) transactions. | ||
|
||
Identifier: | ||
|
||
`setCodeForEOA` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i don't think we need this at all - this is exactly what the wallet should do, and not the application. There is no way the wallet can protect the app from a malicious contract. a wallet defines an account (address). |
||
|
||
Interface: | ||
|
||
```typescript | ||
type SetCodeForEOACapabilityParams = Record< | ||
`0x${string}`, // Chain ID | ||
{ | ||
codeAddress: `0x${string}`, // implementation code address | ||
} | ||
> | ||
``` | ||
|
||
Wallets should generate an EIP-7702 compatible transaction that sets a code of a `from` EOA address | ||
to the code of `codeAddress` specified in the request. | ||
|
||
## Rationale | ||
|
||
## Reference Implementation | ||
|
||
## Security Considerations | ||
|
||
## Copyright | ||
|
||
Copyright and related rights waived via [CC0](../LICENSE.md). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this paymaster is version-specific: e.g. the app has to know whether the account is 4337v6, v7 or 7560, and based on that knowledge, select the right paymaster address
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That means we need something like a
aa_getAccountDetails
API, doesn't it?