WalletConnect

• Name: WalletConnect
• URL: https://walletconnect.network/
• Category: wallet connectivity protocol / onchain UX network / relay-and-node infrastructure
• Tags: ethereum-ecosystem solana-ecosystem bitcoin-ecosystem
• Summary: WalletConnect is the main wallet-to-app session rail in the corpus. The useful distinction is between the session rail itself, the WalletConnect Network operator substrate beneath it, and the Reown-controlled app-facing packaging layer above it. The connect wallet button is just the wrapper. Keep this note on the rail; use reown when the practical question is AppKit defaults, verification signals, embedded-wallet packaging, or the company-run onboarding shell many integrators meet first.
• What it does:
  • Connects wallets and apps through an end-to-end encrypted relay and routing layer used across EVM, Solana, Cosmos, Bitcoin, and other ecosystems
  • Operates a network architecture with service nodes that persist encrypted mailbox-style messages and gateway nodes that route SDK and app traffic
  • Provides wallet and app SDKs across multiple platforms so wallets, custodians, and applications can integrate the WalletConnect Network without building their own connectivity fabric
  • Uses the WCT token for staking, rewards, governance, and possible future fee activation as the network decentralizes
  • Is transitioning from a permissioned operating model toward a more permissionless network, with community governance and node-operator participation documented explicitly in the primary materials
• Key claims:
  • The homepage and docs position WalletConnect as “the connectivity layer for the financial internet” and as an onchain UX ecosystem rather than a narrow SDK package
  • Official materials say the network has already facilitated hundreds of millions of connections across 700+ wallets and 70,000+ apps, while the homepage now advertises even larger live ecosystem counts; this is a useful signal that the network is real, active infrastructure rather than a dormant standard
  • The docs say relay traffic is end-to-end encrypted and that service nodes cannot decrypt or read the contents of the messages they handle
  • The service-node docs describe a rendezvous-hashing-based database and a mailbox model for offline clients, which is a strong categorization clue toward offchain network infrastructure rather than an onchain-only protocol
  • The governance and token docs make clear that WCT is not just a marketing token: it is tied to staking, rewards, governance, and eventually fee decisions for the network
  • The GitHub organization exposes a Rust implementation of the WalletConnect Network node protocol plus multiple SDK and docs repositories, reinforcing that the network and tooling surface are actively maintained
• Whitepaper: An official WalletConnect Network whitepaper exists and was saved locally as ../whitepapers/walletconnect-whitepaper.pdf; see also ../whitepapers/walletconnect-primary-sources-2026-04-27.md.
• Sources:
  • https://walletconnect.network/
  • https://docs.walletconnect.network/overview
  • https://docs.walletconnect.network/network
  • https://docs.walletconnect.network/service-nodes
  • https://docs.walletconnect.network/token-dynamics/intro
  • https://docs.walletconnect.network/governance
  • https://docs.walletconnect.network/wallet-sdk/overview
  • https://whitepaper.walletconnect.network/
  • https://github.com/WalletConnect
  • https://raw.githubusercontent.com/WalletConnect/walletconnect-monorepo/main/README.md

Internal linkages

• Keep the budget tight.
• Structural anchors: walletconnect-network, wallet-standard, and walletconnect-auth.
• Company boundary for the app-facing packaging and product-default layer around the rail: reown.

Protocol / company boundary

• Keep projects/walletconnect on the session rail itself: pairing, encrypted message transport, wallet/app interoperability, cross-ecosystem connectivity, and the governance-bearing network shape around that rail.
• Use reown when the real question is who packages the modal, chooses app-facing SDK defaults, layers on analytics / verification / embedded-wallet integrations, and still sits close to gateway and operator packaging around the network.
• That split matters because the protocol can be open and multi-operator in aspiration while the easiest developer path still arrives through one branded company shell.

Control surface

• Practical leverage sits in relay and gateway operation, namespace and chain support, verification layers, notification rights, and which wallet or app behaviors the SDKs normalize by default.

• Some of those defaults are network-shaped through walletconnect-network, while the app-facing packaging and adoption path is often company-shaped through reown.

• Read WalletConnect first as the durable session rail. The wallet button is the wrapper; the real power is in routing, liveness, and what the network makes easy before any onchain execution starts.

• Last reviewed: 2026-08-07 UTC