WalletKit: the SDK for TON wallet builders in 2026

WalletKit is the lower level of the same stack as AppKit, but for those who build a wallet, not connect to one. It’s part of TON Toolset 2026.

If you’re building a new wallet (custodial or non-custodial), a Mini App with its own wallet, or just crypto-asset management components — this is the foundation toolset.

What’s in it

@ton/walletkit includes:

• TON Connect server-side — full implementation from the wallet side (receiving dApp requests, displaying, signing, responding).
• Asset management — reading balances of TON, jettons, NFTs.
• Transfer building — outbound transactions with typed params.
• Gasless transfer flows — integration with gas-station providers.
• Multi-wallet management — managing many wallets (accumulated keys) in one app.
• Cross-platform core — shared logic for web, iOS, Android, browser extensions.

When to use WalletKit

Fits:

• You’re building a new wallet from scratch (Antarctic, Bitget Wallet) or a Mini App wallet.
• You have an existing wallet, but a legacy TonConnect stack, and time to migrate.
• You want a wallet that’s cross-platform from day one.

Doesn’t fit:

• An existing mature wallet (Tonkeeper, MyTonWallet) — migration isn’t cost-justified. They use their own implementations evolved over years.
• Pure frontend scenarios without custody — use AppKit.

TON Connect from the wallet side

Unlike AppKit (where <TonConnect /> is a button to connect), WalletKit provides server-side processing of dApp requests:

import { WalletKit } from '@ton/walletkit';

const wallet = new WalletKit({
  network: 'mainnet',
  walletAddress: userAddress,
  signTransaction: async (tx) => {
    // your logic: show user details, sign with key
    return signedTx;
  },
});

// Accept request from dApp:
const request = await wallet.tonConnect.acceptRequest(rawRequest);
// request.type === 'tonProof' | 'transaction' | 'signData'

A standardised flow instead of hand-written TonConnect packet parsing.

Gasless transfers

When a dApp requests a gasless transfer (via the Wallet-V5 extension), WalletKit handles:

1. Verifying the fee-payer contract is available and funded.
2. Building the “outer” transaction with correct flags.
3. Signing and sending via the gas-station provider.
4. Returning the tx hash to the dApp.

For the user — a free transfer; for the wallet — a couple lines of code instead of hundreds of lines of hand-rolled Battery integration.

Multi-wallet

Modern TON wallets often hold multiple wallets under one app (work + personal + savings). WalletKit standardises:

const wallets = await walletKit.listWallets(userSeed);
// [{ address, version: 'v4r2', label: 'Main', balance: '15.3 TON' }, ...]

const tx = await walletKit.send({
  from: wallets[0].address,
  to: 'recipient.ton',
  amount: '5 TON',
});

Also includes helpers for import (24-word seed, watch-only address) and rotation (recovery with a new seed).

Cross-platform

@ton/walletkit itself is platform-agnostic. Adapters for specific platforms:

• @ton/walletkit-web — browser/PWA.
• @ton/walletkit-react-native — iOS/Android via React Native.
• @ton/walletkit-extension — browser extensions (Chrome, Firefox).

Each adapter handles platform-specifics: secure storage (Keychain/Keystore vs IndexedDB), network requests (native fetch vs ServiceWorker), biometrics (Face ID, fingerprint).

Shared business logic stays one. Cuts a wallet’s codebase by 30-50% vs per-platform implementations.

Lifecycle events

WalletKit emits events for UI:

walletKit.on('balance:change', ({ address, newBalance, delta }) => {
  // refresh UI, show notification
});

walletKit.on('tx:received', ({ from, amount, comment }) => {
  // show toast
});

walletKit.on('connection:accepted', ({ dappName, dappUrl }) => {
  // logs + UI
});

Security

WalletKit doesn’t store or transmit the seed phrase. Signing is done via the signTransaction callback you implement locally. Meaning:

• Seed stays in the platform’s secure storage.
• WalletKit sees only the public side.
• All network activity is public operations (read balance, send signed tx).

The right design for self-custody — the user fully controls the keys.

Compared to alternatives

WalletKit wins on time-to-market and cross-platform parity. Custom — only if you have unusual requirements (regulatory, specific hardware integration).

What’s next

• Docs: docs.ton.org/ecosystem/walletkit/overview.
• GitHub: ton-connect/kit (shared monorepo).
• NPM: @ton/walletkit.

Building a wallet or a Mini App with its own wallet — WalletKit is your friend. Building a frontend that connects to someone else’s wallet — use AppKit.

Full Toolset context — in our TON Foundation overview.