Skip to main content
T TON Adoption
Basics GUIDE · 2026

WalletConnect vs TON Connect 2026: The Real Difference

Comparison of two wallet-connection protocols: WalletConnect (EVM standard) and TON Connect (TON-native). Architecture, security, what to use in 2026.

Author
TON Adoption Team · research desk
Published
5 min read

A common question from devs entering TON from the EVM world: “Does WalletConnect work for TON?”. Short answer — no. TON uses its own protocol, TON Connect, functionally similar but architecturally completely different.

This piece is the full breakdown of the differences, what to use when, how to support both as a dApp, and where TON Connect has the edge.

Short answer — what to know in 30 seconds

ItemWalletConnectTON Connect
Target networksEVM (Ethereum, BSC, Polygon, Arbitrum)TON only
2026 versionv2.xv2.0
Transaction formatEVM ABI (RLP-encoded)TON cells (BOC)
ConnectionQR code / deep linkQR code / Telegram-bridge
Signingsecp256k1 (Ethereum signing)Ed25519 (TON signing)
WalletsMetaMask, Rainbow, Trust, OKX, etc.Tonkeeper, MyTonWallet, Tonhub, Wallet by TG
Mini Apps supportNoYes (native)

Writing a TON dApp → use TON Connect. Writing an EVM dApp → WalletConnect. Cross-chain → both.

How WalletConnect works (EVM)

Architecture

WalletConnect is a broker-based protocol via relay servers:

  1. dApp generates a session token + QR code
  2. User scans the QR with their wallet (or taps a deep link on mobile)
  3. Wallet sets up an encrypted session over WalletConnect Relay (centralized or decentralized in v2)
  4. dApp → Relay → wallet → user approval → wallet → Relay → dApp
  5. Transaction is signed on the user’s device with secp256k1

Networks

WalletConnect v2 supports chains via CAIP-2 namespaces (eip155:1 for Ethereum mainnet, eip155:137 for Polygon, etc.).

TON is not part of the EVM namespace and has no CAIP-2 chain ID in standard WalletConnect namespaces. Theoretically it could be added via an extension protocol, but in practice nobody does — TON Connect natively is better.

How TON Connect works

Architecture

TON Connect 2.0 has a similar structure with TON-specific details:

  1. dApp generates a TC-session + TON Connect QR
  2. User scans the QR with their wallet OR opens a Mini App in Telegram (where the Telegram-bridge auto-connects Wallet by TG)
  3. Wallet sets up an encrypted session via the TON Connect Bridge (HTTP-based, no centralized relay)
  4. dApp → Bridge → wallet → approval → signature → returned to dApp
  5. Transaction is signed with Ed25519 (TON-native cryptography), packed into a BOC (Bag of Cells)

Specifics

  • Telegram-bridge — for Mini Apps, the wallet can be embedded into Telegram (Wallet by TG); connection happens without QR scanning
  • Local modeTonkeeper Pro on desktop can connect without a relay (peer-to-peer over local WebRTC)
  • Native Telegram support — a Mini App developer gets tg.initData.user.id and can link a TG username to a TON address

Key architectural differences

1. Transaction format

WalletConnect:

// EVM-style RLP-encoded transaction
{
  to: '0xabc...',
  value: '0x16345785d8a0000',  // 0.1 ETH
  data: '0x...'
}

TON Connect:

// TON cell-based transaction
{
  valid_until: 1700000000,
  messages: [{
    address: 'EQAB...',
    amount: '100000000',  // 0.1 TON
    payload: '<base64-BOC>'  // forward message body as BOC
  }]
}

A fundamental difference. An EVM tx is a flat ABI-encoded JSON; a TON tx is a nested structure of cells (slices, refs).

2. Signing

  • WalletConnect uses secp256k1 (same curve as Bitcoin)
  • TON Connect uses Ed25519 (faster verification, smaller signature size — 64 bytes vs 65)

3. Relay

  • WalletConnect v2 Relay — bridged via WalletConnect Cloud (centralized, hosted by WalletConnect Inc.), or self-hosted
  • TON Connect Bridge — an HTTP server, can be run by anyone (TON Foundation, wallet providers, dApp deployer). Default — bridge.ton-connect.dev or the wallet’s own bridge

4. Mini Apps integration

A unique TON Connect advantage:

  • Inside a Telegram Mini App, TON Connect auto-connects to Wallet by Telegram without QR scanning
  • Through tg.WebApp.openInvoice() you can combine Stars payments + TON Connect transactions in one flow

WalletConnect has no such integration — no Telegram-native support.

What to use when

Case 1: TON-only dApp

  • Build on TON Connect 2.0
  • Wallet support: Tonkeeper, MyTonWallet, Tonhub, Wallet by TG
  • Distribution via Telegram Mini App for bonus reach

Case 2: Multi-chain dApp (EVM + TON)

  • WalletConnect for the EVM section
  • TON Connect for the TON section
  • UI with “Select chain” → “Select wallet”
  • Examples: Symbiosis (cross-chain bridge), Allbridge (cross-chain swaps), Bitget (multi-chain wallet ops)

Case 3: Telegram Mini App

  • TON Connect 2.0 via Telegram-bridge (auto-detect Wallet by TG)
  • Optional: add Bitget Wallet / OKX Wallet for multi-chain users

Case 4: Native Web3 (no Telegram)

  • TON Connect via QR + manual deep-link
  • Support only Tonkeeper, MyTonWallet, Tonhub
  • UX slightly worse without Telegram integration, but it works

How a dApp supports both

TypeScript pseudo-code:

import { TonConnectUI } from '@tonconnect/ui-react';
import { Web3Modal } from '@web3modal/wagmi';

// TON Connect
const tonConnect = new TonConnectUI({
  manifestUrl: 'https://my-dapp.com/tonconnect-manifest.json'
});

// WalletConnect (Wagmi)
const wagmiModal = new Web3Modal({
  projectId: 'WALLET_CONNECT_PROJECT_ID',
  chains: [mainnet, polygon, bsc]
});

// UI router
const Connect = () => {
  return (
    <div>
      <h2>Connect wallet</h2>
      <Button onClick={() => tonConnect.openModal()}>
        Connect TON wallet
      </Button>
      <Button onClick={() => wagmiModal.open()}>
        Connect EVM wallet
      </Button>
    </div>
  );
};

More detail in our TON Connect piece.

Security

Common rules (apply to both)

  1. Phishing — top threat. Always verify URL before approve.
  2. Transaction payload review — read what you sign carefully. No blanket “approve all.”
  3. Session expiration — sessions have TTL (24h for TON Connect by default). Re-auth is mandatory.
  4. Pinned domain backup — for critical dApps verify TLS certs and pinned domains.

TON Connect-specific risks

  • Forward message payload — the user signs not only the main transfer but also a forward cell. If the payload is a transfer-jetton call, you can unintentionally send USDT-TON.
  • Mini App spoofing — someone makes a fake Mini App with UI similar to a legit one. The Telegram-bridge connection is “too automatic.”
  • Wallet version drift — Tonkeeper v3.x vs Tonkeeper v4.7 may handle complex payloads differently.

Future of TON Connect in 2026–2027

Per the public TON Foundation roadmap:

  • TON Connect 2.1 — out in summer 2026, adds batch-approval (multiple transactions one approval)
  • Hardware wallet support — Ledger via TON Connect 2.0 already works; Trezor integration expected
  • AI-agent integration — via AgenticKit (see our AgenticKit and Teleport piece)
  • Cross-protocol bridges — a theoretical WalletConnect–TON Connect adapter, but not a priority

Bottom line

TON Connect ≠ WalletConnect. Two different protocols, both functional, both mature, but for different ecosystems.

  • TON-only project — TON Connect, no question
  • EVM-only project — WalletConnect
  • Cross-chain — both, with a router UI
  • Telegram Mini App — TON Connect via the TG bridge (a huge UX bonus)

For users the difference is invisible: both work via QR / deep-link, both are safe (no seed transmission). The difference matters for developers and for understanding which wallets can connect.

Additional reading:

Frequently asked

Not directly. WalletConnect is an EVM-oriented protocol (Ethereum, Polygon, BSC, Arbitrum, etc.). It doesn't understand TON transaction structures (cells, BOC, ADNL). TON uses its own protocol **TON Connect**, functionally analogous but architecturally entirely different.
TON Connect is the standard protocol for connecting TON wallets (Tonkeeper, MyTonWallet, Tonhub, Wallet by Telegram) to dApps and Mini Apps. Analogous to WalletConnect for Ethereum, but native for TON: it understands cells, BOC transaction format, ADNL addressing, jetton standards.
(1) Native for TON — no translation overhead. (2) Mini Apps support — wallets can confirm transactions **inside** Telegram without switching apps. (3) Sub-second confirmation after Catchain 2.0 (faster than most EVM chains). (4) Low gas ($0.0005 after MTONGA step 2). It's not 'better' globally — it's better for TON use cases. For cross-chain, WalletConnect is needed.
All mainstream TON wallets: **Tonkeeper** (TON Connect 2.0), **MyTonWallet** (2.0), **Tonhub** (2.0), **Wallet by Telegram** (2.0 via Telegram-bridge), **Bitget Wallet** (2.0), **OKX Wallet** (2.0). Cross-chain support (via WalletConnect): Bitget Wallet and OKX Wallet work in both EVM and TON, the rest are TON-only.
Yes, like WalletConnect — both use **end-to-end encryption** for session tokens and never transmit seed phrases. The main risk is phishing sites (impersonating a legit dApp and asking to approve a malicious transaction). Defense: always verify URL before approving, read transaction payload, use dApps with public reputation. See our [drainer-sites guide](/en/blog/drainer-sites-in-ton-how-they-work-2026/).
Yes. If the dApp works with EVM + TON, implement both: WalletConnect for Ethereum/Polygon/BSC, TON Connect for TON. The dApp gets a 'Select wallet' UI with two groups. Examples: Storm Trade (perp on TON + EVM-margin opt-in), EVAA (TON-only currently), cross-chain bridges (Symbiosis, Allbridge — both).
Technically nothing. The TON Connect protocol works with addresses and transactions, not tickers. After June 1, 2026, wallets will display 'GRAM' instead of 'TON' on transaction confirmation, but the protocol itself doesn't change. See our [main rebrand explainer](/en/blog/toncoin-renamed-to-gram-what-it-means-2026/).

Related