Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
201 changes: 201 additions & 0 deletions ERCS/erc-xxxx.md
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
{

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

Copy link
Author

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?

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<

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the time-range:
a wallet validation can return a time range, which is compared to "now".
what is the usage scenario of this property?

Copy link
Author

Choose a reason for hiding this comment

The 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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wallet MAY specify a nonceKey, (if it doesn't specify, then the default 0 is used)
nonceSequence is trickier: it requires an eth_getNonce API

Copy link
Author

Choose a reason for hiding this comment

The 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<

Choose a reason for hiding this comment

The 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.
NonceKey and Paymaster are generic, and don't expose the app directly to version-specific API
(paymaster does require protocol-specific paymaster, but it is encapsulated away from the app)
But this one is very specific. Also, it can't be used without a supporting view APIs to query these values

`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`

Choose a reason for hiding this comment

The 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).
when the app performs a "sendCall", the wallet should decide how to implement it. if the network supports 7702, it should submit it as a 7702 transaction. if that account already has a 7702 contract deployed (in a previous transaction), then just submit a batch call to use it.


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).
Loading