WalletConnect Monorepo Documentation

repository·v2.0·Indexed 23 days ago

https://github.com/walletconnect/walletconnect-monorepo

A monorepo containing core SDKs, providers, and utilities for the WalletConnect open protocol. It includes the WalletConnect Pay SDK for payment processing, @walletconnect/sign-client for v2.0 Protocol implementation for Dapps and Wallets, @walletconnect/ethereum-provider for Ethereum-compatible chains, and @walletconnect/react-native-compat for React Native environment shims.

Tokens
53.3K
Snippets
91
Records
293
Agent score
32%

What's inside WalletConnect Monorepo

  1. Use @walletconnect/sign-client for WalletConnect v2.0

    v2.0

    The @walletconnect/sign-client library provides the Sign Client implementation for the WalletConnect v2.0 Protocol. It is designed to support both Dapps (acting as the Proposer) and Wallets (acting as the Responder).

    Supported Runtimes

    • NodeJS
    • Browser
    • React-Native (Note: Required NodeJS modules must be polyfilled for React-Native environments).

    Integration Paths

    Integration logic varies depending on your role:

  2. How the WalletConnect Pay SDK architecture works

    v2.0

    The SDK uses a provider abstraction to support different environments. It auto-detects the best available provider:

    • NativeProvider: Uses the React Native uniffi module (currently supported).
    • WasmProvider: Uses a WebAssembly module (coming soon).

    You can use provider utilities to check availability or manually inject the native module if auto-discovery fails.

    import {
      isProviderAvailable,
      detectProviderType,
      isNativeProviderAvailable,
      setNativeModule,
    } from "@walletconnect/pay";
    
    // Check if any provider is available
    if (isProviderAvailable()) {
      // SDK can be used
    }
    
    // Detect which provider type is available
    const providerType = detectProviderType(); // 'native' | 'wasm' | null
    
    // Check specifically for native provider
    if (isNativeProviderAvailable()) {
      // React Native native module is available
    }
    
    // Manually inject native module (if auto-discovery fails)
    import { NativeModules } from "react-native";
    setNativeModule(NativeModules.RNWalletConnectPay);
  3. How to create a custom provider file

    v2.0

    If you need to extend the Universal Provider by adding support for a new namespace, follow these steps:

    1. Create a new file under providers/universal-provider/src/providers/<NAMESPACE>.ts.
    2. Implement the IProvider interface.
    3. In the IProvider.request method, implement logic to determine whether to route the request to the wallet or to the blockchain. Note that this.namespace.methods should only contain methods supported by the wallet.
    4. Most methods will follow a similar structure to existing providers, utilizing httpProvider and chain identifiers like eip155:1 or solana:mainnetBeta.
    5. Export the new provider from providers/universal-provider/src/providers/index.ts.
  4. Connect a wallet using WalletConnectModal or custom URI handling

    v2.0

    You can initiate a connection in two ways:

    1. Using the built-in Modal: If showQrModal was set to true during initialization, call provider.connect() or provider.enable() to display the QR code.
    2. Custom URI handling: If you are not using the built-in modal, subscribe to the display_uri event to receive the connection URI, then handle it with your own custom logic.
    // Option 1: Using the built-in Modal
    await provider.connect({
      chains, // OPTIONAL
      rpcMap, // OPTIONAL
      pairingTopic, // OPTIONAL
    });
    // or
    await provider.enable();
    
    // Option 2: Custom URI handling
    provider.on("display_uri", (uri: string) => {
      // ... custom logic to show QR code or handle URI
    });
    
    await provider.connect();
    // or
    await provider.enable();
  5. Use EthereumProvider with SSR Frameworks (e.g., Next.js)

    v2.0

    Because EthereumProvider relies on browser-specific APIs (window, document, localStorage), it cannot be initialized on the server. When using SSR frameworks like Next.js, follow these steps:

    1. Isolate in a Client Component: Create a component (e.g., WalletConnectLogic.tsx) and mark it with the "use client"; directive.
    2. Dynamic Import: In your server-side or parent component, import the client component using next/dynamic with ssr: false to prevent the server from attempting to execute the provider code.
    // src/app/page.tsx
    "use client";
    
    import dynamic from 'next/dynamic';
    import { Suspense } from 'react';
    
    const WalletConnectLogic = dynamic(
      () => import('@/components/WalletConnectLogic'),
      { ssr: false }
    );
    
    export default function Home() {
      return (
        <Suspense fallback={<p>Loading...</p>}>
          <WalletConnectLogic />
        </Suspense>
      );
    }
  6. Connect the Universal Provider to a session

    v2.0

    After initialization, call provider.connect() to establish a connection. You must define namespaces to specify which chains and methods your application supports.

    For EIP-155 (Ethereum) namespaces, you should provide:

    • methods: An array of supported JSON-RPC methods (e.g., eth_sendTransaction).
    • chains: An array of chain identifiers in the format <namespace>:<chainId> (e.g., eip155:80001).
    • events: An array of supported events (e.g., chainChanged).
    • rpcMap: A mapping of chain IDs to their respective RPC URLs.

    Optional connection parameters:

    • pairingTopic: A specific topic to connect to.
    • skipPairing: A boolean (defaults to false) to skip the pairing process.
    import { ethers } from "ethers";
    import UniversalProvider from "@walletconnect/universal-provider";
    
    //  Initialize the provider
    const provider = await UniversalProvider.init({
      logger: "info",
      relayUrl: "ws://<relay-url>",
      projectId: "12345678",
      metadata: {
        name: "React App",
        description: "React App for WalletConnect",
        url: "https://walletconnect.com/",
        icons: ["https://avatars.githubusercontent.com/u/37784886"],
      },
      client: undefined, // optional instance of @walletconnect/sign-client
    });
    
    //  create sub providers for each namespace/chain
    await provider.connect({
      namespaces: {
        eip155: {
          methods: [
            "eth_sendTransaction",
            "eth_signTransaction",
            "eth_sign",
            "personal_sign",
            "eth_signTypedData",
          ],
          chains: ["eip155:80001"],
          events: ["chainChanged", "accountsChanged"],
          rpcMap: {
            80001:
              "https://rpc.walletconnect.org?chainId=eip155:80001&projectId=<your walletconnect project id>",
          },
        },
        pairingTopic: "<123...topic>", // optional topic to connect to
        skipPairing: false, // optional to skip pairing ( later it can be resumed by invoking .pair())
      },
    });
    
    //  Create Web3 Provider
    const web3Provider = new ethers.providers.Web3Provider(provider);
  7. Understand the structure of Required and Optional Namespaces

    v2.0

    In a WalletConnect proposal, namespaces define the capabilities (chains, methods, and events) that a session will support. These are categorized into requiredNamespaces and optionalNamespaces.

    Each namespace follows the BaseRequiredNamespace structure:

    • chains?: An optional array of chain IDs (strings).
    • methods: An array of method strings that the session supports.
    • events: An array of event strings that the session supports.
    interface BaseRequiredNamespace {
        chains?: string[];
        methods: string[];
        events: string[];
    }
    
    type RequiredNamespaces = Record<string, BaseRequiredNamespace>;
    type OptionalNamespaces = Record<string, BaseRequiredNamespace>;