Wallet connect multi chain support by Tomasvrba · Pull Request #4359 · BitBoxSwiss/bitbox-wallet-app

Tomasvrba · 2026-08-25T20:53:45Z

This PR adds WalletConnect support for multiple EVM networks:

Ethereum
optimism
BNB Smart Chain
Gnosis
Polygon
HyperEVM
Base
Arbitrum
Ethereum Sepolia

The BitBoxApp now:

Handles required and optional permissions requested by dApps.
Shows the requested networks with their names and icons.
Supports read-only WalletConnect sessions.
Rejects connection requests that require unsupported features.
Uses the correct network when preparing, signing, and broadcasting
transactions.
Keeps pending transactions from different networks separate.

This depends on #4267 but would be nice to get into the next release. Only the top 3 commits are for this PR.

benma · 2026-09-01T15:02:09Z

@Tomasvrba could you rebase? staging-spark got merged, maybe that caused all the conflicts.

benma

Codex finds below.

P3 is tricky, as it's annoying to deal with - does it need to be dealt with?

[P1] Native-chain contract transactions can crash the backend.
broadcastTransaction() (

bitbox-wallet-app/backend/coins/eth/account.go

Line 719 in 13e12d2

if err := account.storePendingOutgoingTransaction(transaction); err != nil {

) now stores WalletConnect transactions and schedules
an account update. However, TransactionData() (

bitbox-wallet-app/backend/coins/eth/types/types.go

Line 109 in 13e12d2

if erc20Token == nil && len(data) > 0 {

) panics when an ETH
account’s pending transaction contains calldata. A pending approval or swap on Ethereum/Sepolia can hit this path. Pending-transaction presentation must support general contract calls before these
transactions enter that storage. The new tests only exercise empty calldata.
[P2] "input": null is incorrectly rejected.
The new parser (

bitbox-wallet-app/backend/coins/btc/handlers/walletconnect.go

Line 35 in 13e12d2

if request.Input != nil {

) rejects every non-nil json.RawMessage,
including JSON null. The previous implementation explicitly accepted it, and its corresponding test was removed during the refactor. This breaks previously accepted requests. Preserve the distinction between
an absent/null field and a populated unsupported alias.
[P2] Other chains lack pending-transaction protection.
Non-native broadcasts skip storage (

bitbox-wallet-app/backend/coins/eth/account.go

Line 716 in 13e12d2

if chainID != account.coin.ChainID() {

), and nonce selection trusts the remote
nonce directly (

bitbox-wallet-app/backend/coins/eth/account.go

Line 346 in 13e12d2

if chainID != account.coin.ChainID() {

). If the provider returns a stale pending nonce, consecutive
requests can reuse it, causing replacement or rejection. Transactions lost after an apparently successful broadcast also cannot be rebroadcast. The native path already accounts for these provider behaviors.
Tracking by chain and address would preserve those protections without mixing networks.

benma · 2026-09-09T08:31:57Z

-	Coin *Coin
-	Tx   *types.Transaction
-	Fee  *big.Int
+	ChainID uint64


It seems conceptually off to use a coin/account instance tied to a specific chainID to handle transactions of walletconnect by arbitrary other chains. Now account.go has its own chainID and is supplied an external one, which is probably confusing and brittle in the long run, one has to always check to not mix anything up.

Is there a reason for mixing all of this here, or could walletconnect not simply call shared helper functions to get the next nonce, sign the tx, etc?

addressed in 7095079

All other issues addressed in the fixup commits

benma · 2026-09-09T08:35:47Z

+	"github.com/stretchr/testify/require"
+)
+
+func TestEVMChainCapabilities(t *testing.T) {


This is basically a copypaste of the actual var, don't think this test is valuable and could be removed.

Build approved namespaces from required and optional WalletConnect capabilities shared with request dispatch. Support read-only sessions, reject unsupported proposals, and handle approval and rejection failures.

WalletConnect advertises several EVM networks, but the backend previously accepted transactions only on the account's native network. This caused requests for networks such as Optimism, Base, and Arbitrum to fail. Use the network requested by WalletConnect when getting transaction data, signing, and broadcasting. Use the network requested by WalletConnect for nonce and fee lookup, signing, and broadcasting. Do not mix native-chain pending transactions into another network's nonce selection. Reuse the normal Ethereum signing path instead of maintaining a separate WalletConnect signer. Keep the underlying transaction code independent of WalletConnect so it can also support native multichain features later.

- Centralize metadata for the ten EVM networks supported by the backend. - Derive WalletConnect chain entries from numeric IDs. - Render the registry's SVG assets in pairing and signing requests.

Tomasvrba · 2026-09-11T21:18:13Z

Codex finds below.

P3 is tricky, as it's annoying to deal with - does it need to be dealt with?

1. [P1] Native-chain contract transactions can crash the backend.
   broadcastTransaction() (https://github.com/BitBoxSwiss/bitbox-wallet-app/blob/13e12d20a54b6e5ec5eb40ae4420b7142c149fb1/backend/coins/eth/account.go#L719
   ) now stores WalletConnect transactions and schedules
   an account update. However, TransactionData() (https://github.com/BitBoxSwiss/bitbox-wallet-app/blob/13e12d20a54b6e5ec5eb40ae4420b7142c149fb1/backend/coins/eth/types/types.go#L109
   ) panics when an ETH
   account’s pending transaction contains calldata. A pending approval or swap on Ethereum/Sepolia can hit this path. Pending-transaction presentation must support general contract calls before these
   transactions enter that storage. The new tests only exercise empty calldata.

2. [P2] "input": null is incorrectly rejected.
   The new parser (https://github.com/BitBoxSwiss/bitbox-wallet-app/blob/13e12d20a54b6e5ec5eb40ae4420b7142c149fb1/backend/coins/btc/handlers/walletconnect.go#L35
   ) rejects every non-nil json.RawMessage,
   including JSON null. The previous implementation explicitly accepted it, and its corresponding test was removed during the refactor. This breaks previously accepted requests. Preserve the distinction between
   an absent/null field and a populated unsupported alias.

3. [P2] Other chains lack pending-transaction protection.
   Non-native broadcasts skip storage (https://github.com/BitBoxSwiss/bitbox-wallet-app/blob/13e12d20a54b6e5ec5eb40ae4420b7142c149fb1/backend/coins/eth/account.go#L716
   ), and nonce selection trusts the remote
   nonce directly (https://github.com/BitBoxSwiss/bitbox-wallet-app/blob/13e12d20a54b6e5ec5eb40ae4420b7142c149fb1/backend/coins/eth/account.go#L346
   ). If the provider returns a stale pending nonce, consecutive
   requests can reuse it, causing replacement or rejection. Transactions lost after an apparently successful broadcast also cannot be rebroadcast. The native path already accounts for these provider behaviors.
   Tracking by chain and address would preserve those protections without mixing networks.

I don't think 3 is urgent to deal with. Given fast confirmation times and slow wallet connect workflow, I think it's unlikely that the provider would provide a stale nonce. We can deal with this in the future if it turns out to be an issue.

Move WalletConnect transaction construction and fee estimation into standalone functions that use an explicit target chain and RPC client. Keep sender validation, keystore access, signing, and native pending tracking in the account.

benma-agent · 2026-09-12T07:45:09Z


-import { ReactNode, createElement } from 'react';
 import { IWalletKit } from '@reown/walletkit';
-import { ArbitrumLogo, OptimismLogo, BaseLogo, ETHLogo } from '@/components/icon';


This removes the last uses of ArbitrumLogo, OptimismLogo, BaseLogo, and ETHLogo. Please also remove the four now-unused wrappers and their SVG imports from frontends/web/src/components/icon/icon.tsx.

benma · 2026-09-12T17:36:19Z

+		return signingResponse{Success: false, ErrorMessage: err.Error()}, nil
+	}
+	signedTx, err := ethAccount.SignTransaction(eth.SignTransactionArgs{
+		ChainID:     *args.ChainID,


My comment about confusing ownership still seems to apply?

#4359 (comment)

chainID is not in the account struct anymore, but passed to functions on the account instance instead, which still means the account tied to one chain is handling other chains.

What do you think?

Codex suggestion:

I would make these changes:

Move Account.SignTransaction() into a package-level eth.SignTransaction() function.
Give it the request, target-chain client, signing configuration, the existing ConnectKeystore callback, and access to pending transactions for that chain/address. It should perform sender validation, nonce
selection, construction, signing, broadcasting, and tracking.

It should receive no *Account. Derive the expected sender and keypath from the supplied signing configuration. Keeping ConnectKeystore as a callback preserves the current ordering: validate and prepare
before connecting the device.

Move client selection out of Account.
Remove Account.chainClient() and the account’s chainClientProvider field. Backend wiring resolves the client from the requested chain ID and passes it to the function. It can reuse the existing native-chain
client when appropriate; that is dependency selection during setup.

Tomasvrba requested review from benma and thisconnect August 25, 2026 20:53

Tomasvrba requested a review from a team as a code owner August 25, 2026 20:53

Tomasvrba force-pushed the wc-update-2 branch 2 times, most recently from a87ccf8 to 13e12d2 Compare September 1, 2026 20:15

thisconnect requested review from shonsirsha and removed request for thisconnect September 2, 2026 07:45

benma reviewed Sep 9, 2026

View reviewed changes

Comment thread backend/coins/eth/chains.go Outdated

benma reviewed Sep 9, 2026

View reviewed changes

Tomasvrba added 5 commits September 11, 2026 13:11

frontend: honor optional WalletConnect namespaces

8b9c847

Build approved namespaces from required and optional WalletConnect capabilities shared with request dispatch. Support read-only sessions, reject unsupported proposals, and handle approval and rejection failures.

frontend: add generic EVM chain registry

c2da627

- Centralize metadata for the ten EVM networks supported by the backend. - Derive WalletConnect chain entries from numeric IDs. - Render the registry's SVG assets in pairing and signing requests.

fixup! backend: support multichain WalletConnect transactions

88f2a57

fixup! backend: support multichain WalletConnect transactions

a1af3ed

Tomasvrba force-pushed the wc-update-2 branch from 13e12d2 to 7095079 Compare September 12, 2026 00:30

Tomasvrba requested a review from benma September 12, 2026 00:32

benma-agent reviewed Sep 12, 2026

View reviewed changes

benma reviewed Sep 12, 2026

View reviewed changes

Navigation Menu

Uh oh!

Wallet connect multi chain support - #4359

Wallet connect multi chain support#4359
Tomasvrba wants to merge 6 commits into
BitBoxSwiss:masterfrom
Tomasvrba:wc-update-2

Tomasvrba commented Aug 25, 2026 •

edited

Loading

Uh oh!

benma commented Sep 1, 2026

Uh oh!

benma left a comment

Uh oh!

benma Sep 9, 2026

Uh oh!

Tomasvrba Sep 12, 2026

Uh oh!

Uh oh!

Uh oh!

benma Sep 9, 2026

Uh oh!

Tomasvrba commented Sep 11, 2026

Uh oh!

benma-agent Sep 12, 2026

Uh oh!

benma Sep 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Tomasvrba commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benma commented Sep 1, 2026

Uh oh!

benma left a comment

Choose a reason for hiding this comment

Uh oh!

benma Sep 9, 2026

Choose a reason for hiding this comment

Uh oh!

Tomasvrba Sep 12, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

benma Sep 9, 2026

Choose a reason for hiding this comment

Uh oh!

Tomasvrba commented Sep 11, 2026

Uh oh!

benma-agent Sep 12, 2026

Choose a reason for hiding this comment

Uh oh!

benma Sep 12, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Tomasvrba commented Aug 25, 2026 •

edited

Loading