TON Connect 2: What Changed in the Wallet Connection Protocol

TON Connect is the open protocol that connects wallets to decentralized applications on TON. Where the EVM world uses WalletConnect, the TON ecosystem standardized on TON Connect. Version 2, in production since 2023, is the de facto industrial standard — almost every dApp, mini app, and DEX in the ecosystem runs on it.

This guide walks through what changed between v1 and v2, how bridge servers and deep links work, what makes the multi-wallet picker useful, and what edge cases developers should expect. To be upfront: v2 is an evolution, not a revolution — but its improvements are precisely what made mass wallet adoption inside Telegram mini apps possible.

What TON Connect actually does

TON Connect solves a basic problem: a dApp wants the user’s public address, wants to ask for a signature, and wants a clear way to receive the answer — and the user wants to manage permissions and see what they are signing. Without a standard every wallet would expose its own API and developers would integrate five to seven SDKs.

With TON Connect the flow becomes:

1. The dApp installs one SDK (@tonconnect/sdk or a UI wrapper).
2. The user clicks “Connect wallet” and picks their wallet from a unified picker.
3. The wallet connects through a bridge server or a deep link.
4. The dApp gets the address and can request signatures.

What was wrong with v1

The first version (2022) was functional but limited:

• Narrow method set — effectively just connect and one form of sign.
• No standard picker UI — every dApp drew its own button, which confused users.
• Weak mobile support — connection went through a QR code, awkward when the wallet and dApp lived on the same device.
• Hard-coded message shape without an explicit version, so extensions broke backward compatibility.

v1 never settled as a universal standard — most wallets supported it alongside their own methods.

What v2 brings

The substantive changes:

1. JSON-RPC over a bridge. All messages are structured JSON with a schema, explicit version, and an extensible method set.
2. Bridge servers. A relay (Tonkeeper and Tonhub run defaults; you can host your own) shuttles messages between dApp and wallet. The dApp never needs a direct connection to the wallet.
3. Deep and universal links. On mobile a tc://... or https://app.tonkeeper.com/ton-connect?... URL opens the wallet with the connection request preloaded. QR remains the desktop fallback.
4. Multi-wallet picker. The wallet list loads from a single registry (wallets-list.json), so users see familiar icons.
5. A sendTransaction standard. Clear schema for a signature request: list of messages with amount, payload, stateInit; the wallet renders them to the user in a human-readable way.
6. Explicit permissions and events. The user sees what the dApp asks for (address only vs address + right to send). Sessions can be revoked.

i

Architectural nuance. The bridge server never sees secrets. The dApp and wallet exchange end-to-end encrypted messages; the bridge just forwards bytes. A compromised bridge can delay or drop a message but cannot tamper with content undetected.

Supported wallets

The TON Connect 2 registry on May 2026 includes:

• Tonkeeper — flagship UX, supports W5 and emulation.
• MyTonWallet — cross-platform: Chrome extension + mobile + Telegram mini app.
• Wallet (Telegram bot) — built-in @wallet, friendly for non-crypto users.
• Tonhub — older but still maintained.
• OpenMask — MetaMask-style browser extension.
• DeWallet, Bitget Wallet, Bybit Wallet — custodial and semi-custodial options.

Current list lives in the ton-connect/wallets-list repository on GitHub.

Compared with WalletConnect

WalletConnect is broader as a multi-chain umbrella; TON Connect is deeper as a TON-native protocol.

What JSON-RPC structure looks like

A minimal sign request:

{
  "valid_until": 1747900000,
  "messages": [
    {
      "address": "EQA...",
      "amount": "100000000",
      "payload": "te6cck..."
    }
  ]
}

The dApp sends this through the bridge → the wallet renders “send 0.1 TON to EQA…” to the user → the user confirms → the wallet signs the BoC and returns the signed body. The dApp can broadcast through its own API provider (TONAPI, OrbsTonAccess) or hand it back to the wallet for delivery.

Deep links and universal links: why they matter

Mobile connections depend on iOS universal links and Android app links:

• Universal link (https://app.tonkeeper.com/ton-connect?v=2&id=...&r=...) opens Tonkeeper if installed, otherwise lands on the website.
• Deep link (tc://?v=2&id=...&r=...) opens only the installed app, otherwise nothing happens.

Modern SDKs combine both: try the universal link, fall back to QR.

Developer integration in five steps

Minimal TON Connect 2 in a React dApp:

1. Install: npm install @tonconnect/ui-react.
2. Manifest (tonconnect-manifest.json hosted on your domain): declares the URL, icon, and app name.
3. Provider: wrap the app in .
4. Button: drop in — it draws the picker and handles states.
5. Transactions: await tonConnectUI.sendTransaction({...}).

Full examples live in ton-connect/sdk and on docs.ton.org.

!

Footgun. The manifest must live at exactly the URL you passed to the provider and must be reachable over HTTPS without CORS restrictions. Wallets download the manifest on every connection and validate it. Any error and the user sees “invalid app.”

UX improvements 2024–2026

Since the v2 launch the infrastructure shipped several important upgrades:

• Tonkeeper Auth — a signature-only login flow (challenge signing without a transaction), useful for Web2-style auth.
• Transaction emulation — wallets preview “what will happen after you sign” (balance changes, jetton mints). Tonkeeper shipped this first.
• Batched messages — one transaction can contain up to four messages (wallet contract v4/v5 standard); the UI is standardized.
• Session resume — closing and reopening a dApp restores the session from localStorage without showing the picker again.

Where the protocol is heading: v3 on the horizon

Community discussions point at v3 with several directions:

• Multi-account in a single session — switch between several addresses of the same wallet without reconnecting.
• Account-abstraction-style hints — gas sponsorship, batched smart-account operations, recovery.
• Events standard — the wallet subscribes to dApp events (balance updates) without polling.
• Cross-chain hooks — preparation for the multi-network future (TAC and other L2/bridge integrations).

There is no firm v3 release window — rough horizon is 2026–2027.

Conclusion

TON Connect 2 is an infrastructure success of the TON ecosystem. One protocol, one picker, support across most wallets, smooth mobile integration, clear security through bridge plus end-to-end encryption. For users it means wallet connection feels the same and predictable in every dApp. For developers it means one SDK instead of five.

If you are starting a TON dApp — use @tonconnect/ui-react (or the vanilla SDK for Vue or Svelte) and track the wallets registry. If you are a user — pay attention to what the wallet shows you before signing. TON Connect will not protect you from your own click on “Confirm” on a malicious transaction.

→