WalletConnect wallet integration

WalletConnectAdapter reaches wallets over a relay rather than through anything installed in the page. It is the one entry in the stable registry whose cip0103 block declares native: false, so it is driven through this adapter rather than treated as a CIP-0103 provider. It needs a WalletConnect Cloud project id, and it is the only adapter in this set where your application renders the pairing QR itself.

What the registry declares

Transport	Mobile, over a relay or deep link
Adapter package	@partylayer/adapter-walletconnect
SDK version	>=0.3.0
Networks	devnet, testnet, mainnet
CIP-0103	Declared not native

The CIP-0103 marker is recorded with its evidence: https://www.npmjs.com/package/@canton-network/dapp-sdk. That link is the source; this page does not restate what it says.

Install

npm install @partylayer/react @partylayer/adapter-walletconnect

Construct the adapter

import { WalletConnectAdapter } from '@partylayer/adapter-walletconnect';

// requiresConfig: true in the registry entry. projectId is mandatory.
const walletconnect = new WalletConnectAdapter({
  projectId: process.env.NEXT_PUBLIC_WALLETCONNECT_PROJECT_ID!,
  metadata: {
    name: 'Your dApp',
    description: 'What the wallet shows the user during pairing',
    url: 'https://app.example.com',
    icons: ['https://app.example.com/icon.png'],
  },
  // Wire the pairing URI to your own QR UI:
  onUri: (uri) => setPairingUri(uri),
});

Register it

Pass the adapter to PartyLayerKit. Everything else, the button and the modal, is the same for every wallet.

import { PartyLayerKit, ConnectButton } from '@partylayer/react';

export default function App() {
  return (
    <PartyLayerKit network="devnet" adapters={[walletconnect]}>
      <ConnectButton />
    </PartyLayerKit>
  );
}

Connection flow

The adapter fires onUri once the session proposal is created; that URI is what your QR component renders. The CAIP-2 chain is derived from the network configured on PartyLayerKit, so the two cannot drift. Set chainId only to pin a chain regardless of the configured network.

What the transport means for you

The pairing URI is yours to display, so unlike every other adapter here there is no wallet-owned window that appears on its own: if you do not implement onUri, the user sees nothing happen. In exchange the same integration reaches any wallet on the relay rather than one vendor, and the metadata block you pass is what those wallets show the user, so it is worth filling in properly rather than leaving placeholder text.

What this adapter supports

Capability	Call	Through this adapter
Sign message	useSignMessage()	Yes
Sign transaction	useSignTransaction()	Not available
Submit transaction	useSubmitTransaction()	Yes
Report transaction status	submit result	Not available
Switch network	client.switchNetwork()	Not available
Multi-party	multi-party flows	Not available

Not available, and why

signTransaction: The registry entry declares signTransaction: false. Through this adapter the sign and submit steps are one call, so there is no detached signature to return; use submitTransaction.
transaction status: The registry entry declares transactionStatus: false.

Things that will catch you out

Sign and submit are a single stepCalling signTransaction rejects with a message pointing you at submitTransaction, because on this path the two are fused and there is no intermediate signed payload to hand back. Structure your flow around one approval, not two.

submitTransaction throws rather than returning "pending"This adapter previously returned the literal string pending as a transactionHash when it had no real value. It now throws, matching the Send adapter. Handle the rejection. This was our defect, not the relay's.

The project id is not optionalWithout a WalletConnect Cloud project id there is no pairing to establish, so the constructor rejects rather than failing later. Supply it from your own environment rather than hardcoding one.

Troubleshooting

Every symptom below is a real rejection path in @partylayer/adapter-walletconnect, quoted from the adapter rather than reconstructed.

Symptom	Cause	What to do
"WalletConnectAdapter requires a `projectId`."	The adapter was constructed with no project id, usually an environment variable that did not reach the browser bundle.	Check the variable is exposed to client code. In Next.js that means a NEXT_PUBLIC_ prefix; a bare name is undefined in the browser.
Nothing visible happens after the user picks the wallet	onUri was not wired, so the pairing URI was produced and discarded with no QR rendered.	Pass onUri and render the URI as a QR code. This adapter has no window of its own to open.
signTransaction rejects pointing at submitTransaction	There is no detached signing step on this path.	Call submitTransaction and treat the single approval as both steps.
"Failed to restore WalletConnect session"	A stored session could not be re-established against the relay, for example after it expired.	Fall back to a fresh pairing. Clear any UI that assumed a live session first.

Quick Start builds a working app around this adapter.
Wallets and adapters covers registration, discovery and custom adapters.
CIP-0103 provider is the standard behind the transports above.
WalletConnect homepage for anything about the wallet itself. This page describes the PartyLayer adapter, not the wallet's own SDK.

Other wallets

Console Wallet · 5N Loop · Cantor8 · Bron · Nightly