Update EIP-5792: add missing 6xx category for status code 600

EIPS/eip-5792.md

@@ -22,7 +22,7 @@
 
 The current methods used to send transactions from the user wallet and check their status do not meet modern developer demands and cannot accommodate new transaction formats. Even the name–- `eth_sendTransaction`-– is an artifact of a time when nodes served as wallets.
 
 Today, developers want to send multiple calls batched together in a single RPC call, which many smart accounts can, in turn, execute atomically in a single transaction. Developers also want to make use of features afforded by new transaction formats, like paymasters in [ERC-4337](./eip-4337.md) transactions. `eth_sendTransaction` offers no way to do these things.
 
 In updating to a new set of `wallet_` RPCs, our main goals are to enforce a clean separation of wallet and app concerns, enable developers to make use of things like paymasters and batch transactions, and to create a clear way for more safely discoverable features to be added over time with minimal coordination.
 
@@ -37,7 +37,7 @@
 with `0x` prefix and no leading zeroes for the `chainId` value.
 The items in the `calls` field are simple `{to, data, value}` tuples.
 
 The capabilities field is how an app can communicate with a wallet about capabilities a wallet supports. For example, this is where an app can specify a paymaster service URL from which an [ERC-4337](./eip-4337.md) wallet can request a `paymasterAndData` input for a user operation.
 
 Each capability defined in the "capabilities" member can define global or call specific fields.
 These fields are set inside this capability's entry in the `capabilities` object.
@@ -167,7 +167,7 @@
 * The receipts in the `receipts` field MUST be in the order that they are included onchain.
 * If a wallet executes multiple calls **atomically**, `wallet_getCallsStatus` MAY return an object with a `receipts` field that contains a single transaction receipt or an array of receipts, corresponding to how the batch of transactions were included onchain. It also MUST be explicit and return an `atomic` field set to `true`.
 * If a wallet executes multiple calls **non-atomically**, `wallet_getCallsStatus` MUST return an object with a `receipts` field that contains **an array of receipts** for all transactions containing batch calls that were included onchain. This includes the batch calls that were included on-chain but eventually reverted. It also MUST be explicit and return a `atomic` field set to `false`.
 * The `logs` in the receipt objects MUST only include logs relevant to the calls submitted using `wallet_sendCalls`. For example, in the case of a transaction submitted onchain by an [ERC-4337](./eip-4337.md) bundler, the logs must only include those relevant to the user operation constructed using the calls submitted via `wallet_sendCalls`. I.e. the logs should not include those from other unrelated user operations submitted in the same bundle.
   * Similarly, if a user upgrades their wallet to support atomicity before submitting a batch of calls from an app, the logs MUST NOT include those emitted as part of the upgrade process.
 
 #### `wallet_getCallsStatus` RPC Specification
@@ -208,6 +208,7 @@
 * 2xx: Confirmed states
 * 4xx: Offchain failures
 * 5xx: Chain rules failures
+* 6xx: Partial chain rules failures
 
 | Code | Description                                                                                                                       |
 |------|-----------------------------------------------------------------------------------------------------------------------------------|
@@ -398,7 +399,7 @@
 
 We considered modifying `eth_sendTransaction` to add support for these new capabilities, but the method is ultimately an artifact of when nodes were used to sign transactions. We decided it is better to move forward with `wallet_`-namespaced methods that better describe what they are used for.
 
 We also debated whether the methods should be called `wallet_sendTransaction`, `wallet_sendCalls`, or something else. We ultimately landed on `wallet_sendCalls` because in the case of EOA wallets the `wallet_send*` method might send more than one transaction. Similarly, we decided against `wallet_sendTransactions` because in the case of other wallet implementations (e.g. [ERC-4337](./eip-4337.md)) multiple calls could result in a single transaction.
 
 ### Call Execution Atomicity
 
@@ -410,7 +411,7 @@
 
 ### Call Gas Limit
 
 Our initial proposal included an optional `gas` field for each call in the `calls` field accepted by the `walletSendCalls` method. However, we realized this could be misleading because in the case of [ERC-4337](./eip-4337.md) wallets you cannot specify a gas limit per call, only a single gas limit for all calls in the user operation. We then proposed a single `gas` value that would apply to all of the calls. This works for [ERC-4337](./eip-4337.md) wallets, but not for EOA wallets. When we decided that EOA wallets should be able to handle multiple calls, the common `gas` field became untenable across use cases and we removed it altogether.
 
 ## Backwards Compatibility