TON Connect Integration for Mobile Wallet Applications
TON Connect is a communication protocol between a dApp and wallet in the TON Blockchain ecosystem. Unlike WalletConnect (EVM world), it has its own protocol on top of an HTTP bridge with push notifications via SSE. Implementation in a mobile application requires understanding not only the SDK but also how the transport layer works.
How TON Connect Transport Works
The protocol works via a bridge server (bridge.tonapi.io or self-hosted). Wallet and dApp exchange encrypted messages through this bridge — no direct connection. Encryption is NaCl box (X25519 + XSalsa20-Poly1305).
Mobile wallet application connects to bridge via SSE (Server-Sent Events): GET /bridge/{clientId}/events. This is a long-lived HTTP request that keeps the connection open. On iOS — a problem: URLSession doesn't support SSE natively, requiring an EventSource library or custom implementation via URLSessionDataDelegate. On Android with OkHttp — also no built-in SSE support, but EventSource from the OkHttp team (com.squareup.okhttp3:okhttp-sse) solves the issue.
Alternative transport — deeplink. dApp encodes a tc:// or https://ton.app/... link, user clicks, wallet opens and receives connect request from URL parameters. This is synchronous flow without bridge — works simpler, but requires dApp and wallet to be on the same device.
Handling connect request in wallet
Upon receiving a connection request, the wallet should:
- Decode
ConnectRequestfrom encrypted payload (or from deeplink parameterr). - Show the user: which dApp is requesting connection, what
itemsare needed (ton_addr,ton_proof). - Obtain user approval.
- Form
ConnectResponsewith wallet address, network (mainnet/testnet), public key, andton_proofif requested.
ton_proof is cryptographic proof of wallet ownership without transaction signing. Format: ton-proof-item-v2/<wc>:<addr_bytes>/<app_domain>/<timestamp>/<payload>. Signed with wallet private key via Ed25519. dApp verifies signature via TON API, not trusting the wallet.
Common implementation mistake: incorrect serialization of addr_bytes — needs raw format (workchain + 32 bytes hash), not user-friendly bounce/non-bounce address.
Signing Transactions
After connection, dApp sends SendTransactionRequest with BOC (Bag of Cells) — binary representation of TON transaction. Wallet:
- Decodes BOC via
ton-coreor@ton/ton. - Shows transaction details to user: recipient, amount, comment.
- Signs transaction with private key.
- Sends signed BOC to TON network via
tonapi.ioortoncenter.com. - Returns
SendTransactionResponsewith transaction hash to dApp.
BOC decoding for UI display — non-trivial task. BOC may contain arbitrary smart contract calls with payloads. For standard jetton transfers there's an OP-code parser (0xf8a7ea5 — jetton transfer), otherwise — show raw hex with warning.
TON Connect SDK for Mobile
Official @tonconnect/sdk is written for JavaScript/TypeScript — works in React Native with polyfills (react-native-crypto, buffer). For native platforms there's no official SDK — implement the protocol yourself per spec or use community libraries (TonSdk.NET for MAUI, ton-kotlin for Android).
Tonkeeper — open source, excellent reference for understanding real TON Connect implementation on mobile.
Timeline
Integrating TON Connect into existing wallet (connection and transaction signing only) — 3–5 weeks. Full-fledged TON wallet from scratch (seed management, key derivation, jetton support, NFT, staking) — 4 to 6 months.







