Skip to content

Commit

Permalink
Adding missing paymasterData field to erc (#446)
Browse files Browse the repository at this point in the history
  • Loading branch information
shahafn authored Feb 8, 2024
1 parent 32b6d96 commit 12898d4
Showing 1 changed file with 6 additions and 5 deletions.
11 changes: 6 additions & 5 deletions erc/ERCS/erc-4337.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,6 +70,7 @@ To avoid Ethereum consensus changes, we do not attempt to create new transaction
| `paymaster` | `address` | address of paymaster contract, (or empty, if account pays for itself) |
| `paymasterVerificationGasLimit` | `uint256` | The amount of gas to allocate for the paymaster validation code |
| `paymasterPostOpGasLimit` | `uint256` | The amount of gas to allocate for the paymaster post-operation code |
| `paymasterData` | `uint256` | data for paymaster (only if paymaster exists) |
| `signature` | `bytes` | Data passed into the account to verify authorization |

Users send `UserOperation` objects to a dedicated user operation mempool. The are not concerned with the packed version.
Expand Down Expand Up @@ -132,7 +133,7 @@ The account:
* authorizer - 0 for valid signature, 1 to mark signature failure. Otherwise, an address of an authorizer contract. This ERC defines "signature aggregator" as authorizer.
* `validUntil` is 6-byte timestamp value, or zero for "infinite". The UserOp is valid only up to this time.
* `validAfter` is 6-byte timestamp. The UserOp is valid only after this time.

An account that works with aggregated signature, should return its signature aggregator address in the "sigAuthorizer" return value of validateUserOp.
It MAY ignore the signature field.

Expand Down Expand Up @@ -362,7 +363,7 @@ Each of these contracts is also restricted in its storage access, to make sure U
To simulate a `UserOperation` validation, the client makes a view call to `simulateValidation(userop)`.
The EntryPoint itself does not implement the simulation methods. Instead, when making the simulation view call,
The EntryPoint itself does not implement the simulation methods. Instead, when making the simulation view call,
The bundler should provide the alternate EntryPointSimulations code, which extends the EntryPoint with the simulation methods.
The simulation core methods:
Expand All @@ -377,7 +378,7 @@ struct ValidationResult {
AggregatorStakeInfo aggregatorInfo;
}
function simulateValidation(PackedUserOperation calldata userOp)
function simulateValidation(PackedUserOperation calldata userOp)
external returns (ValidationResult memory);
struct ReturnInfo {
Expand Down Expand Up @@ -427,7 +428,7 @@ However, there might be use-cases where specific paymasters (and signature aggre
(through manual auditing) and verified that they cannot cause any problem, while still require relaxing of the opcode rules.
A bundler cannot simply "whitelist" request from a specific paymaster: if that paymaster is not accepted by all
bundlers, then its support will be sporadic at best.
Instead, we introduce the term "alternate mempool": a modified validation rules, and procedure of propagating them to other bundlers.
Instead, we introduce the term "alternate mempool": a modified validation rules, and procedure of propagating them to other bundlers.

The procedure of using alternate mempools is defined in [ERC-7562](./erc-7562.md#Alt-mempools-rules)

Expand Down Expand Up @@ -506,7 +507,7 @@ Note that this stake is never slashed, and can be withdrawn any time (after unst

Unstaked entities are allowed, under the rules below.

When staked, an entity is less restricted in its memory usage.
When staked, an entity is less restricted in its memory usage.

The stake value is not enforced on-chain, but specifically by each node while simulating a transaction.

Expand Down

0 comments on commit 12898d4

Please sign in to comment.