# EIP-5792

> Next-gen wallet RPCs

## Getting Started

### For Wallets

To implement support for the new RPC methods, wallets need to:

1. Implement `wallet_getCapabilities` to indicate support for atomic execution and other capabilities
2. Implement `wallet_sendCalls` to process batches of calls
3. Implement `wallet_getCallsStatus` to allow checking the status of submitted calls
4. Implement `wallet_showCallsStatus` to display call information to users

#### wallet\_getCapabilities

This method allows wallets to indicate their support for various capabilities, including atomic execution. The atomic capability can have three states:

* `supported`: The wallet will execute all calls atomically and contiguously
* `ready`: The wallet is able to upgrade to `supported` pending user approval (e.g. via [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702))
* `unsupported`: The wallet does not provide any atomicity or contiguity guarantees

Example response:

```json
{
  "atomic": "supported",
  "paymasterService": {
    "supported": true
  }
}
```

#### wallet\_sendCalls

This method processes a batch of calls. If `atomicRequired` field is set to `true`, the wallet must execute all of the calls atomically, otherwise it may execute them atomically or sequentially.

Example request:

```json
{
  "method": "wallet_sendCalls",
  "params": [
    {
      "version": "2.0.0",
      "chainId": "0x1",
      "from": "0x...",
      "calls": [
        {
          "to": "0x...",
          "data": "0x...",
          "value": "0x0"
        }
      ],
      "capabilities": {
        "atomic": {
          "required": true
        }
      }
    }
  ]
}
```

Example response:

```json
{
  "id": "0x00000000000000000000000000000000000000000000000000000000000000000e670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331",
  "capabilities": {
    "atomic": {
      "status": "supported"
    }
  }
}
```

The response includes:

* `id`: A unique identifier for the batch of calls (up to 4096 bytes)
* `capabilities`: Optional capability-specific metadata from the wallet

#### wallet\_getCallsStatus

This method allows checking the status of submitted calls. The status codes follow these categories:

* 1xx: Pending states
* 2xx: Confirmed states
* 4xx: Offchain failures
* 5xx: Chain rules failures

| Code | Description                                                                                                                       |
| ---- | --------------------------------------------------------------------------------------------------------------------------------- |
| 100  | Batch has been received by the wallet but has not completed execution onchain (pending)                                           |
| 200  | Batch has been included onchain without reverts, receipts array contains info of all calls (confirmed)                            |
| 400  | Batch has not been included onchain and wallet will not retry (offchain failure)                                                  |
| 500  | Batch reverted **completely** and only changes related to gas charge may have been included onchain (chain rules failure)         |
| 600  | Batch reverted **partially** and some changes related to batch calls may have been included onchain (partial chain rules failure) |

Example response:

```json
{
  "status": 200,
  "receipts": [
    {
      "logs": [],
      "status": "0x1",
      "blockHash": "0x...",
      "blockNumber": "0x...",
      "gasUsed": "0x...",
      "transactionHash": "0x..."
    }
  ]
}
```

#### wallet\_showCallsStatus

This method displays call information to users. It can be used to show the status of submitted calls, including any errors or confirmations.

Example request:

```json
{
  "method": "wallet_showCallsStatus",
  "params": [
    {
      "chainId": "0x1",
      "calls": [
        {
          "to": "0x...",
          "data": "0x...",
          "value": "0x0"
        }
      ],
      "status": 200,
      "receipts": [
        {
          "logs": [],
          "status": "0x1",
          "blockHash": "0x...",
          "blockNumber": "0x...",
          "gasUsed": "0x...",
          "transactionHash": "0x..."
        }
      ]
    }
  ]
}
```

### For Apps

The easiest way for apps to start using EIP-5792 is to use a library which has implemented support for EIP-5792:

* [Wagmi](https://wagmi.sh/react/api/hooks/useCapabilities)
* [Viem](https://viem.sh/docs/actions/wallet/sendCalls)
* [thirdweb](https://portal.thirdweb.com/references/typescript/v5/hooks#eip5792)

For example, the following fetches the connected wallet's capabilities using wagmi's `useCapabilities` hook:

```ts twoslash [App.tsx]
// @filename: App.tsx
import React from 'react'
// ---cut---
import { useCapabilities } from 'wagmi'

function App() {
  const { data: capabilities } = useCapabilities() // [!code hl]
// @log:   {
// @log:     "0x0": {
// @log:       "flow-control": {
// @log:         "supported": true
// @log:       }
// @log:     },
// @log:     "0x1": {
// @log:       "atomic": true,
// @log:       "auxiliaryFunds": {
// @log:         "supported": true
// @log:       }
// @log:     }
// @log:   }

  return <div />
}
```

While not all wallets are EIP-5792 compliant, apps can call `wallet_sendCalls`, falling back to a legacy method if they encounter an `4200 Unsupported Method` error.

See the following example using Viem's `sendCalls` implementation, falling back to `sendTransaction` if the connected wallet doesn't support EIP-5792:

```ts twoslash [executeTransactions.ts]
import 'viem/window'

// ---cut---
// [!region imports]
import { createWalletClient, custom, parseEther } from 'viem'
import { mainnet } from 'viem/chains'
// [!endregion imports]

export const walletClient = createWalletClient({
  chain: mainnet,
  transport: custom(window.ethereum!),
})

const [account] = await walletClient.getAddresses()

// Define our transaction calls
const calls = [
  {
    to: '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045' as const,
    value: parseEther('1')
  },
  {
    data: '0xdeadbeef' as const,
    to: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48' as const,
  },
]

async function executeTransactions() {
  try {
    const { id } = await walletClient.sendCalls({ 
      account, 
      calls,
      forceAtomic: true // Force atomic execution, sets `atomicRequired`: true
    })
    return id
  } catch (error) {
    // Check for EIP-5792 unsupported method error (code 4200)
    const err = error as { code?: number; message?: string }
    if (err.code === 4200 || (err.message && err.message.includes('Unsupported Method'))) {
      
      const results = []
      for (const call of calls) {
        try {
          const hash = await walletClient.sendTransaction({ account, ...call })
          results.push({ hash, success: true })
        } catch (txError) {
          results.push({ error: txError, success: false })
        }
      }
      
      return results
    }
    
    throw error
  }
}

executeTransactions()
  .then(result => console.log('Transaction result:', result))
  .catch(error => console.error('Transaction failed:', error))
```


## Introduction

### What is EIP-5792?

[EIP-5792](https://eips.ethereum.org/EIPS/eip-5792) enables applications to ask a wallet to process a batch of onchain write calls and to check on the status of those calls. These calls can be enhanced by `capabilities` (such as atomic execution or paymasters), if they are supported by the wallet.

More specifically, this introduces a `wallet_sendCalls` method (with additional methods to check the status of submitted calls and display call information). Apps can specify whether they require atomic execution of calls using the `atomicRequired` field, and wallets can indicate their support for atomic execution through the `atomic` capability.

Meanwhile `wallet_getCapabilities` can be called by applications to establish what capabilities are supported by the wallet. These capabilities can then be passed by applications when sending calls to be executed by the wallet.

### What does that mean for users?

End users will no longer need to manually execute multiple transactions one by one. The canonical example is the "approve and transfer" flow for ERC-20 tokens, which currently requires two transactions, and necessitates a disorienting UI, particularly for users who are new to the space. User interfaces can be simpler and more intuitive.

This obviously also simplifies things for app developers and designers, who will no longer need to create those complex interfaces. And app developers will no longer need to "guess" what a given wallet is capable of.

For wallets, batched calls provide more context on the application's intent, enabling richer and more informative confirmation dialogs, rather than looking at each transaction one by one. Wallets can also indicate their support for atomic execution of batches through the `atomic` capability, which can have three states:

* `supported`: The wallet will execute all calls atomically and contiguously
* `ready`: The wallet is able to upgrade to `supported` pending user approval (e.g. via [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702))
* `unsupported`: The wallet does not provide any atomicity or contiguity guarantees

For both sides, capabilities establish a foundation for iteratively adding new functionality over time to further improve and streamline the user experience.

### Why now?

The approaching [Pectra](https://ethereum.org/en/roadmap/pectra) upgrade includes [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), which will enable Externally Owned Accounts (EOAs) to set their address to be represented by a code of an existing smart contract. This means that any account on Ethereum will be able to make batched calls (assuming the EOA's designated smart contract supports it).

This is a transformative unlock for user experience, but for end-users to benefit, applications need to access that new capability. That is where EIP-5792 comes in.

The time is now!

### What is the status of this EIP?

This EIP is currently in "Last Call", with a deadline of May 5, 2025. There is already significant support for the EIP across [wallets](/ecosystem/wallets) and [tools](/ecosystem/tools).

### How can I get involved?

Review the [EIP](https://eips.ethereum.org/EIPS/eip-5792), and join the conversation on [Ethereum Magicians](https://ethereum-magicians.org/t/eip-5792-wallet-function-call-api/11374).


## Apps

Below are some apps that leverage EIP-5792 today.

:::info
This list is not exhaustive. If you know of an app that leverages EIP-5792, please [open a PR](https://github.com/lukasrosario/eip-5792-site/blob/main/docs/pages/ecosystem/apps.mdx) to add it.
:::

* [revoke.cash](https://revoke.cash/)
* [Lido](https://lido.fi/)
* [LI.FI](https://li.fi)
* [Jumper.Exchange](https://jumper.exchange/)
* [Ekubo](https://evm.ekubo.org)
* [Uniswap](https://app.uniswap.org/)
* [NFTs2Me](https://nfts2me.com/)
* [Fibrous](https://app.fibrous.finance/)
* [Lighthouse.one](https://lighthouse.one/)
* [Relay](https://relay.link/)
* [Splits](https://splits.org/)


## Tools

The following developer tools support EIP-5792.

:::info
This list is not exhaustive. If you know of a tool that supports EIP-5792, please [open a PR](https://github.com/lukasrosario/eip-5792-site/blob/main/docs/pages/ecosystem/tools.mdx) to add it.
:::

* [Wagmi](https://wagmi.sh/)
* [Viem](https://viem.sh/)
* [thirdweb SDK](https://portal.thirdweb.com/references/typescript/v5/functions#eip5792)
* [Porto](https://github.com/ithacaxyz/porto)
* [WalletKit](https://reown.com/walletkit)
* [Coinbase Wallet SDK](https://github.com/coinbase/coinbase-wallet-sdk)
* [Alloy](https://docs.rs/alloy/latest/alloy/)
* [Onchainkit](https://onchainkit.xyz/)
* [Drift](https://github.com/delvtech/drift)
* [RainbowKit](https://rainbowkit.com/)


## Wallets

The following wallets support EIP-5792.

:::info
This list is not exhaustive. If you know of a wallet that supports EIP-5792, please [open a PR](https://github.com/lukasrosario/eip-5792-site/blob/main/docs/pages/ecosystem/wallets.mdx) to add it.
:::

* [Coinbase Smart Wallet](https://www.base.org/builders/smart-wallet)
* [Safe\{Wallet}](https://github.com/safe-global/safe-wallet-web)
* [Ambire Wallet](https://www.ambire.com/)
* [Metamask](https://metamask.io/)
* [Reown AppKit Embedded Wallet](https://reown.com/appkit)
* [thirdweb In-App and Smart Wallets](https://portal.thirdweb.com/typescript/v5/inAppWallet)
* [Openfort](https://openfort.xyz)
* [Abstract Global Wallet](https://abs.xyz)
* [TokenPocket](https://tokenpocket.pro)
* [Splits Teams](https://splits.org/teams/)


## `atomic` Capability

The `atomic` capability specifies how a wallet will execute batches of transactions requested through the `wallet_sendCalls` method. This capability is expressed separately for each chain and should be interpreted as a guarantee only for batches of transactions on that chain.

### Specification

#### Wallet

The `atomic` capability has a `status` field that can take one of three values:

* `supported`: The wallet will execute all calls atomically and contiguously
* `ready`: The wallet is able to upgrade to `supported` pending user approval (e.g. via [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702))
* `unsupported`: The wallet does not provide any atomicity or contiguity guarantees

If the `atomic` capability is not present for a given chain, it means that the wallet does not support batching for that chain.

##### Example

```ts twoslash
// @noErrors
provider.request({
  method: 'wallet_getCapabilities',
  params: ['0xd46e8dd67c5d32be8058bb8eb970870f07244567']
})
// @log: {
// @log:   "0x2105": {
// @log:     "atomic": {
// @log:       "status": "supported"
// @log:     }
// @log:   },
// @log:   "0x14A34": {
// @log:     "atomic": {
// @log:       "status": "unsupported"
// @log:     }
// @log:   }
// @log: }
```

#### App

When sending a batch of calls using `wallet_sendCalls`, apps can specify their atomicity requirements using the `atomicRequired` field:

* If `atomicRequired` is set to `true`:
  * The wallet MUST execute all calls atomically and contiguously
  * The wallet MUST reject the request if it cannot guarantee atomic execution
  * If the wallet's `atomic` capability is `ready`, it MUST upgrade to `supported` before proceeding
* If `atomicRequired` is set to `false`:
  * The wallet MUST execute calls sequentially (one after another)
  * The calls need not be contiguous (other transactions may be interleaved)
  * Some calls may fail independently
  * The wallet MAY still execute the batch atomically if it supports it

Apps should check the wallet's capabilities using `wallet_getCapabilities` before sending requests with `atomicRequired: true` to ensure the wallet supports atomic execution on the target chain.

#### Relationship with EIP-7702

The `ready` status is particularly relevant for wallets that can upgrade to support atomic execution through [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702). When a wallet indicates `status: "ready"`, it means:

1. The account is an EOA (Externally Owned Account)
2. It can upgrade to a smart account that supports atomic execution via an EIP-7702 delegation
3. The upgrade requires user approval
4. Once upgraded, the wallet will support atomic execution of batches for that EOA

This allows apps to request atomic execution even from EOAs, as long as the wallet is capable of upgrading to support it.


## `auxiliaryFunds` Capability

:::warning
This capability is not finalized and might change.
:::

Allows wallets to indicate to apps that they have access to funds beyond those that can be accounted for by looking up balances onchain given the wallet's address.

Defined in [ERC-7682](https://ethereum-magicians.org/t/erc-7682-auxiliary-funds-capability/19599)

### Specification

#### Wallet

If a wallet can provide its users access to funds beyond those that can be accounted for by looking up balances onchain given the wallet's address, its response to a `wallet_getCapabilities` request should include, for each chain it can provide access to such funds on, an `auxiliaryFunds` object. This object shoud have a single field, `supported`, set to `true`.

##### Example

```ts twoslash
// @noErrors
provider.request({
  method: 'wallet_getCapabilities',
  params: ['0xd46e8dd67c5d32be8058bb8eb970870f07244567']
})
// @log: {
// @log:   "0x2105": {
// @log:     auxiliaryFunds: {
// @log:       supported: true,
// @log:     }
// @log:   }
// @log: }
```

#### App

If a wallet has indicated `auxiliaryFunds` support as described above, your app should not block users from taking actions on the basis of asset balance checks.


## `flowControl` Capability

:::warning
This capability is not finalized and might change.
:::

This is proposed in an open PR, [ERC-7867](https://github.com/ethereum/EIPs/pull/9259). This capability allows dapps to downgrade their required atomicity guarantees and control the behaviour after a failed/reverted call.

:::info
TODO: documentation for wallets and applications.
:::


## `paymasterService` Capability

:::warning
This capability is not finalized and might change.
:::

A capability for apps to communicate with wallets about ERC-4337 paymaster web services.

Defined in [ERC-7677](https://eips.ethereum.org/EIPS/eip-7677).

### Specification

#### App

If you want to sponsor your users' transactions, you can do so by passing a paymaster service URL along with `wallet_sendCalls` requests. Specifically, you will need to include a `paymasterService` object in `capabilities`. This object should have a single field, `url`, that points to your paymaster service.

It's important to note that the URL you provide must be ERC-7677-compliant. If a connected wallet supports paymaster services, it will communicate with the provided URL according to ERC-7677 to get paymaster-related user operation fields.

##### Example

```ts twoslash
// @noErrors
provider.request({
  method: 'wallet_sendCalls',
  params: [{
    version: '1.0',
    chainId: '0x01',
    from: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
    calls: [
      {
        to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
        value: '0x9184e72a',
        data: '0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675'
      },
      {
        to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
        value: '0x182183',
        data: '0xfbadbaf01'
      }
    ],
    capabilities: {
      paymasterService: {
        url: 'https://your-paymaster-service.xyz'
      }
    }
  }]
})
```

#### Wallet

To support the `paymasterService` capability, a wallet must do two things:

1. Indicate it can leverage paymaster services as part of its response to a `wallet_getCapabilities` request.
2. Communicate with the paymaster service according to ERC-7677 if a `wallet_sendCalls` request includes a paymaster service URL.

##### `wallet_getCapabilities` Behavior

If a wallet is able to make use of paymaster web services to sponsor a user's call bundle, it should indicate this as part of its response to a `wallet_getCapabilities` request. Specifically, for each chain the wallet can use paymaster services on, its response to `wallet_getCapabilities` should include a `paymasterService` object. This object shoud have a single field, `supported`, set to `true`.

##### Example

```ts twoslash
// @noErrors
provider.request({
  method: 'wallet_getCapabilities',
  params: ['0xd46e8dd67c5d32be8058bb8eb970870f07244567']
})
// @log: {
// @log:   "0x2105": {
// @log:     paymasterService: {
// @log:       supported: true,
// @log:     }
// @log:   }
// @log: }
```

##### `wallet_sendCalls` Behavior

As outlined above, apps that wish to sponsor their users' transactions will provide a `paymasterService` capability object in their `wallet_sendCalls` requests. This `paymasterService` capability will have a `url` field, which indicates where wallets should send ERC-7677 paymaster RPC requests to.

Wallets will need to make two RPC requests to this URL:

1. `pm_getPaymasterStubData`
   * Returns dummy paymaster values to be used during gas estimation.
2. `pm_getPaymasterData`
   * Returns real paymaster values to be used during user operation submission.


## `wallet_getCallsStatus`

Returns the status of a call batch that was sent via `wallet_sendCalls`. The `atomic` field indicates whether the wallet executed the calls atomically or not, which affects the structure of the `receipts` field.

### Example Usage

```ts twoslash
// @noErrors
provider.request({
  method: 'wallet_getCallsStatus',
  params: ['0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331']
})
// @log: {
// @log:   version: "1.0",
// @log:   chainId: "0x01",
// @log:   id: "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331",
// @log:   status: 200,
// @log:   atomic: true,
// @log:   receipts: [
// @log:     {
// @log:       logs: [
// @log:         {
// @log:           address: '0xa922b54716264130634d6ff183747a8ead91a40b',
// @log:           topics: ['0x5a2a90727cc9d000dd060b1132a5c977c9702bb3a52afe360c9c22f0e9451a68'],
// @log:           data: '0xabcd'
// @log:         }
// @log:       ],
// @log:       status: '0x1',
// @log:       blockHash: '0xf19bbafd9fd0124ec110b848e8de4ab4f62bf60c189524e54213285e7f540d4a',
// @log:       blockNumber: '0xabcd',
// @log:       gasUsed: '0xdef',
// @log:       transactionHash: '0x9b7bb827c2e5e3c1a0a44dc53e573aa0b3af3bd1f9f5ed03071b100bb039eaff'
// @log:     }
// @log:   ]
// @log: }
```

### Parameters

* `[string]`

An array with a single element: a call bundle identifier returned by a `wallet_sendCalls` call.

### Returns

* #### version
  * `string`
  * The version of the API being used. Currently "1.0".

* #### chainId
  * `string`
  * The chain ID in hexadecimal format.

* #### id
  * `string`
  * The call bundle identifier.

* #### status
  * `number`
  * Status code indicating the current state of the batch. Status codes follow these categories:
    * 1xx: Pending states
      * 100: Batch has been received by the wallet but has not completed execution onchain
    * 2xx: Confirmed states
      * 200: Batch has been included onchain without reverts
    * 4xx: Offchain failures
      * 400: Batch has not been included onchain and wallet will not retry
    * 5xx: Chain rules failures
      * 500: Batch reverted completely and only changes related to gas charge may have been included onchain
    * 6xx: Partial chain rules failures
      * 600: Batch reverted partially and some changes related to batch calls may have been included onchain

* #### atomic
  * `boolean`
  * Indicates whether the wallet executed the calls atomically or not. If `true`, the wallet executed all calls in a single transaction. If `false`, the wallet executed the calls in multiple transactions.

* #### receipts
  * `Receipt[]`
  * The receipts associated with a call bundle, if available. The structure depends on the `atomic` field:
    * If `atomic` is `true`, this may be a single receipt or an array of receipts, corresponding to how the batch was included onchain
    * If `atomic` is `false`, this must be an array of receipts for all transactions containing batch calls that were included onchain
  * Each receipt contains:
    * logs
      * `Log[]`
      * The logs generated by the calls. For smart contract wallets (e.g. ERC-4337), these should only include logs relevant to the specific calls, not infrastructure logs.
    * status
      * `'0x1' | '0x0'`
      * `0x1` for success, `0x0` for failure
    * blockHash
      * `Hash`
      * Hash of the block containing these calls
    * blockNumber
      * `Hex`
      * Block number containing these calls
    * gasUsed
      * `Hex`
      * The amount of gas used by these calls
    * transactionHash
      * `Hash`
      * Hash of the transaction containing these calls

* #### capabilities
  * `Record<string, any>`
  * Optional capability-specific metadata


## `wallet_getCapabilities`

Allows an application to query what capabilities a wallet supports. This method should return a `4100 Unauthorized` error if the user has not authorized a connection between the application and the requested address.

Note that the capabilities shown below are for illustrative purposes. We expect the community to align on the definition of additional capabilities in separate ERCs over time.

### Example Usage

```ts twoslash
// @noErrors
provider.request({
  method: 'wallet_getCapabilities',
  params: ['0xd46e8dd67c5d32be8058bb8eb970870f07244567', ['0x2105', '0x14A34']]
})
// @log: {
// @log:   "0x0": {
// @log:     "flow-control": {
// @log:       "supported": true
// @log:     }
// @log:   },
// @log:   "0x2105": {
// @log:     "paymasterService": {
// @log:       "supported": true
// @log:     },
// @log:     "sessionKeys": {
// @log:       "supported": true
// @log:     }
// @log:   },
// @log:   "0x14A34": {
// @log:     "auxiliaryFunds": {
// @log:       "supported": true
// @log:     }
// @log:   }
// @log: }
```

### Parameters

* `[Address, string[]]`

An array with:

1. The wallet address to query capabilities for
2. Optional array of chain IDs in hexadecimal format to query capabilities for

### Returns

* `Record<string, Record<string, any>>`

An object where:

* The top-level keys are chain IDs in hexadecimal format
* Chain ID "0x0" indicates capabilities supported across all chains
* The values are objects mapping capability names to capability-specific parameters
* Each capability's parameters are defined in that capability's specification


## Migrating to 2.0.0

During the EIP review process, there were changes to the initially proposed 1.0 version. This guide outlines the key changes between version 1.0 and the finalised 2.0.0 of EIP-5792, and provides guidance for migrating your implementation.

### Major Changes

#### 1. Version Number

The version number in requests has been updated from `"1.0"` to `"2.0.0"`. This change reflects the significant updates to the specification during the review phase. Subsequent updates will follow [SemVer](https://semver.org/).

#### 2. Atomic Capability

The `atomicBatch` capability has been replaced with a more expressive `atomic` capability that has three states:

* `supported`: The wallet will execute all calls atomically and contiguously
* `ready`: The wallet is able to upgrade to `supported` pending user approval (e.g. via [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702))
* `unsupported`: The wallet does not provide any atomicity or contiguity guarantees

Example response:

```json
{
  "0x1": {
    "atomic": {
      "status": "supported"
    }
  }
}
```

#### 3. Status Codes

The string-based status codes (`"PENDING"`, `"CONFIRMED"`) have been replaced with numeric status codes:

| Code | Description                                                                                                                       |
| ---- | --------------------------------------------------------------------------------------------------------------------------------- |
| 100  | Batch has been received by the wallet but has not completed execution onchain (pending)                                           |
| 200  | Batch has been included onchain without reverts, receipts array contains info of all calls (confirmed)                            |
| 400  | Batch has not been included onchain and wallet will not retry (offchain failure)                                                  |
| 500  | Batch reverted **completely** and only changes related to gas charge may have been included onchain (chain rules failure)         |
| 600  | Batch reverted **partially** and some changes related to batch calls may have been included onchain (partial chain rules failure) |

#### 4. Request Structure

The `wallet_sendCalls` request structure has been updated:

* `chainId` is now a top-level property instead of being per-call
* Added `id` field for batch identification
* Added `atomicRequired` field to specify atomic execution requirements
* Removed per-call `chainId` fields

Example request:

```json
{
  "version": "2.0.0",
  "chainId": "0x1",
  "from": "0x...",
  "calls": [
    {
      "to": "0x...",
      "data": "0x...",
      "value": "0x0"
    }
  ],
  "capabilities": {
    "atomic": {
      "required": true
    }
  }
}
```

#### 5. Response Structure

##### wallet\_sendCalls Response

The `wallet_sendCalls` response structure has been updated:

* Changed from returning a simple string identifier to returning a structured object
* Added `capabilities` field for capability-specific metadata
* The `id` field is now part of a structured response rather than being returned directly as a string

Version 1.0 response:

```json
"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
```

Version 2.0.0 response:

```json
{
  "id": "0x00000000000000000000000000000000000000000000000000000000000000000e670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331",
}
```

##### wallet\_getCallsStatus Response

The `wallet_getCallsStatus` response structure has been updated:

* Added `version` field
* Added `id` field
* Added `chainId` field
* Added `atomic` field to indicate how the batch was executed
* Changed status to numeric codes

Example response:

```json
{
  "version": "2.0.0",
  "id": "0x...",
  "chainId": "0x1",
  "status": 200,
  "atomic": true,
  "receipts": [...]
}
```

#### 6. Additional Changes

##### wallet\_getCapabilities Parameters

The `wallet_getCapabilities` method now accepts an optional array of chain IDs:

Version 1.0:

```json
["0xd46e8dd67c5d32be8058bb8eb970870f07244567"]
```

Version 2.0.0:

```json
["0xd46e8dd67c5d32be8058bb8eb970870f07244567", ["0x2105", "0x14A34"]]
```

This allows apps to query capabilities for specific chains, rather than getting all capabilities for all chains.

##### wallet\_getCallsStatus Response Fields

Additional fields have been added to the `wallet_getCallsStatus` response:

* `version`: Indicates the version of the response format
* `atomic`: Explicitly indicates whether the batch was executed atomically

These fields help apps understand the format of the response and how the batch was executed.

### Migration Guide

#### For Wallets

1. Update your version number to `"2.0.0"` in all responses
2. Replace `atomicBatch` capability with the new `atomic` capability
3. Update status codes to use numeric values
4. Implement the new request/response structures
5. Add support for the `atomicRequired` field in `wallet_sendCalls`
6. Ensure proper handling of the `id` field for batch identification
7. Update `wallet_sendCalls` to return a structured response with `id` and `capabilities` fields
8. Add support for chain-specific capability queries in `wallet_getCapabilities`
9. Include `version` and `atomic` fields in `wallet_getCallsStatus` responses

#### For Apps

> Note that Viem ^2.28.0 has been updated to support the latest specification

1. Update your version number to `"2.0.0"` in all requests
2. Update capability checks to use the new `atomic` capability format
3. Update status code handling to use numeric values
4. Update request/response structure handling
5. Add support for the `atomicRequired` field when requiring atomic execution
6. Implement proper handling of the `id` field for batch identification
7. Update handling of `wallet_sendCalls` response to expect a structured object instead of a string
8. Add support for chain-specific capability queries in `wallet_getCapabilities`
9. Handle new `version` and `atomic` fields in `wallet_getCallsStatus` responses

### Backward Compatibility

While version 2.0.0 introduces significant changes, wallets and apps should maintain backward compatibility where possible:

* Wallets should continue to accept version `"1.0"` requests and respond appropriately
* Apps should be prepared to handle both old and new response formats
* When in doubt, check the version number in responses to determine the format

### Example Migration

Here's an example of migrating a `wallet_sendCalls` request and response from version 1.0 to 2.0.0:

Version 1.0:

```json
// Request
{
  "version": "1.0",
  "from": "0x...",
  "calls": [
    {
      "to": "0x...",
      "data": "0x...",
      "value": "0x0",
      "chainId": "0x1"
    }
  ]
}

// Response
"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
```

Version 2.0.0:

```json
// Request
{
  "version": "2.0.0",
  "chainId": "0x1",
  "from": "0x...",
  "calls": [
    {
      "to": "0x...",
      "data": "0x...",
      "value": "0x0"
    }
  ],
  "capabilities": {
    "atomic": {
      "required": true
    }
  }
}

// Response
{
  "id": "0x00000000000000000000000000000000000000000000000000000000000000000e670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331",
  "capabilities": {
    "atomic": true
  }
}
```


## `wallet_sendCalls`

Requests that a wallet submits a batch of calls. The wallet may execute these calls atomically (in a single transaction) or non-atomically (in multiple transactions), depending on the wallet's capabilities and the `atomicRequired` parameter.

### Example Usage

```ts twoslash
// @noErrors
provider.request({
  method: 'wallet_sendCalls',
  params: [{
    version: '1.0',
    id: '0x123...',
    chainId: '0x01',
    from: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
    atomicRequired: true,
    calls: [
      {
        to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
        value: '0x9184e72a',
        data: '0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675'
      },
      {
        to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
        value: '0x182183',
        data: '0xfbadbaf01'
      }
    ],
    capabilities: {
      paymasterService: {
        url: "https://...",
        optional: true
      }
    }
  }]
})
// @log: {
// @log:   "id": "0x00000000000000000000000000000000000000000000000000000000000000000e670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
// @log: }
```

### Parameters

An array with a single object that contains the following fields:

* #### version
  * `string`
  * The version of the `sendCalls` API to use. Currently, '1.0' is the only version.

* #### id
  * `string` (optional)
  * A unique identifier for this batch of calls. If provided, must be a unique string up to 4096 bytes (8194 characters including leading `0x`). Must be unique per sender per app. If not provided, the wallet will generate a random ID.

* #### chainId
  * `Hex`
  * The chain ID to send the calls on. This is top level because all calls must be submitted on the same chain.

* #### from
  * `Address` (optional)
  * The address to send the calls from. If not provided, the wallet should allow the user to select the address during confirmation.

* #### atomicRequired
  * `boolean`
  * Specifies whether the wallet must execute all calls atomically (in a single transaction) or not. If set to `true`, the wallet MUST execute all calls atomically and contiguously. If set to `false`, the wallet MUST execute calls sequentially (one after another), but they need not be contiguous (other transactions may be interleaved) and some calls may fail independently.
  * If the wallet's `atomic` capability is `ready`, it MUST upgrade to `supported` before proceeding with atomic execution.

* #### calls
  * `Call[]`
  * The calls to submit. A `Call` is defined as an object that has the following fields:
    * to (optional)
      * `Address`
      * The address to send this call to. This field is optional because a call can be a contract creation.
    * value (optional)
      * `Hex`
      * Value in wei to send with this call.
    * data
      * `Hex`
      * The hash of the invoked method signature and encoded parameters OR the compiled code of a contract.
    * capabilities (optional)
      * `Record<string, Capability>`
      * Call-specific capability parameters

* #### capabilities
  * `Record<string, Capability>`
  * An object where the keys are capability names and the values are capability-specific parameters. The wallet MUST support all non-optional capabilities requested or reject the request.

### Returns

* `{ id: string, capabilities?: Record<string, any> }`

Returns an object containing:

* `id`: A call bundle identifier that can be used with `wallet_getCallsStatus` and `wallet_showCallsStatus`
* `capabilities`: Optional capability-specific response data


## `wallet_showCallsStatus`

Requests that a wallet shows information about a given call bundle that was sent with `wallet_sendCalls`. This method does not return anything.

### Example Usage

```ts twoslash
// @noErrors
provider.request({
  method: 'wallet_showCallsStatus',
  params: ['0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331']
})
```

### Parameters

* `[string]`

An array with a single element: a call bundle identifier returned by a `wallet_sendCalls` call.