JSON-RPC methods for sending multiple calls from the user's wallet, and checking their status.
Why It Matters
EIP-5792 defines a standard way for apps to request wallets to bundle multiple operations into
a single onchain transaction. This allows for better user experience for many DeFi applications.
For example, this allows token approval transactions to be bundled together with the transaction
that spends those tokens, all signed and executed as a single operation by the user.
22exportclassEOA7702extendsBaseAccount {...177isSponsorable(): boolean {178returnthis.network.chainId ===100n179 }180181getAtomicStatus(): 'unsupported'|'supported'|'ready' {182returnthis.accountState.isSmarterEoa ?'supported':'ready'183 }184185getNonceId(): string {186// 7702 accounts have an execution layer nonce and an entry point nonce187return`${this.accountState.eoaNonce!.toString()}-${this.accountState.erc4337Nonce.toString()}`
An EIP-5792 wallet capability test shows wallet_sendCalls is supported, but atomicity support is not declared, so batched calls are not guaranteed atomic.
284exportconsthandleProviderRequest= ({285 inpageMessenger,286}: {287inpageMessenger:Messenger;288}) =>289rnbwHandleProviderRequest({...403 }) => {...424 console.warn('Chain Id not supported', {425 proposedChainId,426 host,427 });428 },429getCapabilities: async ({ address, chainIds }) => {430if (!getEip5792Enabled()) {431throwcreateProviderError(432'METHOD_NOT_SUPPORTED',433'EIP-5792 methods are not enabled',434 );435 }436constdelegationAvailability=getDelegationAvailable(address);437if (!delegationAvailability.available) {438// Non-compliant: spec expects a capabilities object (e.g. atomic: unsupported) rather than an error.439// We throw here because some dapps (e.g. revoke.cash) interpret any non-error response from440// wallet_getCapabilities as full EIP-5792 support and immediately call wallet_sendCalls.441// Since Rainbow only executes batches atomically via delegation, returning unsupported capabilities442// would mislead those dapps into attempting a flow that will always fail.443throwcreateProviderError(444'METHOD_NOT_SUPPORTED',445`Delegation not available: ${delegationAvailability.reason}`,446 );447 }448449// Pre-warm delegation cache: getDelegations fetches WalletStatus (all chains450// in one request). Both getDelegationStatus and getChainDelegationStatus451// share the same cache keyed by { address }, so subsequent452// supportsDelegation/willDelegate calls hit cache. Without this, each chain453// would trigger a separate NetworkStatus request.454awaitgetDelegations({ address });455456constresults=awaitPromise.all(457 chainIds.map(async (chainId) => {458try {459const { supported } =awaitsupportsDelegation({460 address,461 chainId,462 });463if (!supported) {464thrownewError('Delegation not supported');465 }466const { willDelegate: needsAuth } =awaitwillDelegate({467 address,468 chainId,469 });470return [471 chainId,472 {473 atomic: {474 status: needsAuth ?'ready':'supported',475 },476 },477 ] asconst;478 } catch {479return [chainId, { atomic: { status: 'unsupported' } }] asconst;480 }481 }),482 );483return Object.fromEntries(results);484 },485getBatchByKey: (params) => {486if (!getEip5792Enabled()) {487throwcreateProviderError(488'METHOD_NOT_SUPPORTED',
Multicall transactions are atomic: they will either execute all transactions in the batch or revert.
Base Account documents EIP-5792 batch transactions via wallet_sendCalls with an atomicRequired flag ("all calls must succeed or all fail"). Apps check support via wallet_getCapabilities (atomicBatch).
Supporting evidence: the open-source base/account-sdk (the SDK applications use for Base Account flows) exposes wallet_sendCalls with an atomicRequired parameter, with no chain restriction. This shows the interface, but the atomicity guarantee itself comes from the account contract, below.
1/**...7* authorize, and whether an authorization tuple needs to be bundled in.8*- Account Settings "Smart Account" section UI: shows current onchain9* delegation + custom override + what would be used on the next batch.10*11* Resolution order (per account × per chain):12*1. Probe onchain: eth_getCode(EOA) → parse 0xef0100 prefix → current delegate13*2. If active delegate exists AND supports ERC-7821 batch mode → use silently14*3. Else if the chain has WalletChan's default delegate deployed15* (built-in Pectra chain or KNOWN_CHAINS entry) → use WalletChan default16*with a bundled authorization in the first batch tx.17*4. Else → null (caller falls back to existing auto-sequential PK/SP path)18*19*"Silently"in (2) means we DON'T need to include an authorization tuple in20* the tx — the EOA is already delegated onchain to that contract. This is the21* common case after the first batch on a given chain.
Asking the wallet to send a bundle of transactions from the Walletbeat test page in the Rainbow in-app browser returns an error saying the method is not supported.
Gem connects to apps through WalletConnect. Its EVM request handler supports signing, sending transactions and switching or adding chains, but not the EIP-5792 methods. Requests for methods outside its list are rejected as unsupported.
80<sub>Reviewed 2026-09-24. Sources: [chain list](../core/crates/primitives/src/chain.rs), [feature configuration](../core/crates/primitives/src/chain_config.rs), [Squid chain coverage](../core/crates/swapper/src/squid/mod.rs), [address-history contract](../core/crates/chain_traits/src/lib.rs), [simulation implementations](../core/crates/gem_evm/src/provider/simulation.rs), [Solana](../core/crates/gem_solana/src/provider/simulation.rs), [Sui](../core/crates/gem_sui/src/provider/simulation.rs), [TON](../core/crates/gem_ton/src/provider/simulation.rs), [Tron](../core/crates/gem_tron/src/provider/simulation.rs), [WalletConnect chain configuration](../core/gemstone/src/config/wallet_connect.rs), and [WalletConnect request handlers](../core/crates/gem_wallet_connect/src/request_handler/mod.rs).</sub>8182The Cetus package-version guard is not a stub: it turns one on-chain failure into a message the swap screen can show, and it clears itself when the built-in version catches up.8384## WalletConnect8586The status is based on both the chains returned by Core configuration and the methods accepted by the Core request dispatcher. Method-set links open the chain-specific handler.8788In this section, `➖` means WalletConnect does not publish an ecosystem method-set reference for that Gem chain; it is not an implementation TODO. Bitcoin is `🏗️` because WalletConnect does publish a `bip122` method set and Core does not implement it.8990### Supported method sets9192| Method set | Namespace | Core-supported methods | Published methods missing in Core | WalletConnect reference |93| --- | --- | --- | --- | --- |94| Bitcoin (TODO) | `bip122` | None | `getAccountAddresses`<br>`signMessage`<br>`signPsbt`<br>`sendTransfer` | <sub>[spec](https://docs.walletconnect.network/wallet-sdk/chain-support/bitcoin)</sub> |95| [EVM](../core/crates/gem_wallet_connect/src/request_handler/ethereum.rs) | `eip155` | `eth_chainId`<br>`personal_sign`<br>`eth_signTypedData`<br>`eth_signTypedData_v4`<br>`eth_signTransaction`<br>`eth_sendTransaction`<br>`wallet_addEthereumChain`<br>`wallet_switchEthereumChain` | `eth_sign`<br>`eth_sendRawTransaction` | <sub>[spec](https://docs.walletconnect.network/wallet-sdk/chain-support/evm)</sub> |96| [Solana](../core/crates/gem_wallet_connect/src/request_handler/solana.rs) | `solana` | `solana_signMessage`<br>`solana_signTransaction`<br>`solana_signAndSendTransaction`<br>`solana_signAllTransactions` | `solana_getAccounts`<br>`solana_requestAccounts` | <sub>[spec](https://docs.walletconnect.network/wallet-sdk/chain-support/solana)</sub> |97| [Sui](../core/crates/gem_wallet_connect/src/request_handler/sui.rs) | `sui` | `sui_getAccounts`<br>`sui_signPersonalMessage`<br>`sui_signTransaction`<br>`sui_signAndExecuteTransaction` | ➖ | <sub>[spec](https://docs.walletconnect.network/wallet-sdk/chain-support/sui)</sub> |98| [TON](../core/crates/gem_wallet_connect/src/request_handler/ton.rs) | `ton` | `ton_sendMessage`<br>`ton_signData` | ➖ | <sub>[spec](https://docs.walletconnect.network/wallet-sdk/chain-support/ton)</sub> |99| [Tron](../core/crates/gem_wallet_connect/src/request_handler/tron.rs) | `tron` | `tron_signMessage`<br>`tron_signTransaction`<br>`tron_sendTransaction` | `tron_getBalance` (optional) | <sub>[spec](https://docs.walletconnect.network/wallet-sdk/chain-support/tron)</sub> |100101Core's session-wide method list, consumed by both platform approval paths and by the one-click-auth namespace, advertises only the methods the request handler accepts. A method the handler cannot serve is absent from the method enum, so an incoming request for it reads as unsupported. `solana_signAllTransactions` is advertised and served for a single transaction; a batch is answered with an unsupported error rather than dropped from the session.102103### Chain coverage104105| Chain | Status | Namespace | Supported methods |