wallet_addFunds

Show the receive screen: the chains the account accepts deposits on, a QR code, and the address itself.

Authentication Required: No (uses an ephemeral signer if not authenticated)

Request

await jaw.provider.request({
  method: 'wallet_addFunds',
  params: [
    {
      chainId: 8453, // Chain the QR code pins
      chains: [8453, 10], // Chains the screen offers to deposit on
    },
  ],
});

Parameters

Both are decimal (8453), matching the chain IDs in your SDK config. Hex quantities ('0x2105') are also accepted.

The two answer different questions and can be sent together: chainId is where the QR code points, which EIP-681 allows only one of, while chains is the set the screen presents. Send chains alone and the QR code pins its first entry, so order it with your primary chain first.

If you send both, chainId must be one of chains. A chainId outside your own list is rejected with -32602 rather than resolved silently: the QR code would pin a chain the same request says you do not accept, so the code and the row beneath it would contradict each other.

An empty chains: [] is rejected with -32602 rather than read as "no preference": it usually means a filter in your app matched nothing, and showing every chain would be the opposite of what you asked for.

Example

[
  {
    "chainId": 8453,
    "chains": [8453, 10]
  }
]

Calling with no parameters is the common case, and means "show the connected account on the connected chain".

Response

Returns null.

Example

null

Behavior

• Opens the receive screen: the address, its ENS name and avatar when they resolve, and the chains it accepts deposits on — the ones in chains, or every mainnet the address works on when you send none
• The QR code encodes an EIP-681 payment request, ethereum:<address>@<chainId>, so a scanner selects the network itself instead of leaving the sender to notice a label
• Resolves when the user closes the screen. Deposits land off-app, so closing is a normal finish, not a rejection
• Reads no balances and polls for nothing
• Renders the same screen in both CrossPlatform and AppSpecific modes
• Params are validated before the screen opens, so a malformed request is refused rather than surfacing inside an open dialog

Errors

Example

// The connected account on the connected chain.
await jaw.provider.request({
  method: 'wallet_addFunds',
});
 
// Pin the QR code to a specific chain.
await jaw.provider.request({
  method: 'wallet_addFunds',
  params: [
    {
      chainId: 8453,
    },
  ],
});
 
// A single-chain app: only Base is offered, and the QR code pins it.
await jaw.provider.request({
  method: 'wallet_addFunds',
  params: [
    {
      chains: [8453],
    },
  ],
});
 
// A multichain app: the row shows exactly these, with Base led and pinned.
await jaw.provider.request({
  method: 'wallet_addFunds',
  params: [
    {
      chains: [8453, 10, 42161],
    },
  ],
});
 
// The screen closing tells you the user is done, not that funds arrived.
const assets = await jaw.provider.request({
  method: 'wallet_getAssets',
  params: [{ account: address }],
});

Related Methods

• wallet_getAssets - Read token balances after funding
• wallet_getCapabilities - Chains and their metadata
• wallet_connect - Connect before funding