diff --git a/erc/ERCS/erc-4337.md b/erc/ERCS/erc-4337.md
index f56d7170a..f52f138ef 100644
--- a/erc/ERCS/erc-4337.md
+++ b/erc/ERCS/erc-4337.md
@@ -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.
@@ -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.
 
@@ -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:
@@ -377,7 +378,7 @@ struct ValidationResult {
     AggregatorStakeInfo aggregatorInfo;
 }
 
-function simulateValidation(PackedUserOperation calldata userOp) 
+function simulateValidation(PackedUserOperation calldata userOp)
 external returns (ValidationResult memory);
 
 struct ReturnInfo {
@@ -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)
 
@@ -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.