Initialize the WalletKit, set up at least one TON wallet, handle connection requests and transaction requests before using examples on this page.
Balances
Blockchain state changes constantly as new blocks are produced. This has implications for when and how to check TON wallet contract balances:- Discrete one-off checks have almost no value on their own — the state might change immediately after the query completes, invalidating its results. Thus, such checks are only practical when handling
transactionrequests. - Continuous monitoring is useful for UI display, showing the most recent balance to users, but should not be used for transaction confirmations.
On-demand balance check
Use thegetBalance() method to check the wallet contract balance in TON wallets managed by WalletKit. The balance is returned in nanoToncoin, with 1 Toncoin equal to nanoToncoin.
Do not store the balance check results anywhere in the wallet service’s state, as they become outdated very quickly. For UI purposes, do continuous balance monitoring.
TypeScript
TypeScript
Continuous balance monitoring
Poll the balance at regular intervals to keep the displayed value up to date. Use an appropriate interval based on UX requirements — shorter intervals provide fresher data but increase API usage. This example should be modified according to the wallet service’s logic:TypeScript
Transfers from dApps
When a connected dApp requests a Toncoin transfer, the wallet service follows this flow:Emulation and preview
WalletKit automatically emulates every incoming transaction request before presenting it to the user. The emulation result is available in theevent.preview object:
TypeScript
Emulation uses the API client configured during WalletKit initialization. The default TON Center APIs provide rich emulation capabilities.
Approve or reject
After showing the preview, handle the user’s decision:TypeScript
Confirm transaction delivery
TON achieves transaction finality after a single masterchain block confirmation, where new blocks are produced approximately every 5 seconds. Once a transaction appears in a masterchain block, it becomes irreversible. Therefore, to reliably confirm the transaction delivery and status, one needs to check whether a transaction has achieved masterchain finality using the selected API client. That said, the wallet service should not block the UI while waiting for such confirmation. After all, with continuous wallet balance monitoring and subsequent transaction requests, users will receive the latest information either way. Confirmations are only needed to reliably display a list of past transactions, including the most recent ones. For detailed transaction tracking, message lookups, and payment processing, the message lookup guide covers finding transactions by external message hash, waiting for confirmations, and applying message normalization.Transfers in the wallet service
Transactions can be created directly from the wallet service (not from dApps) and fed into the regular approval flow viahandleNewTransaction() method of the WalletKit. It creates a new transaction request event, enabling the same UI confirmation-to-transaction flow for both dApp-initiated and wallet-initiated transactions.
This example should be modified according to the wallet service’s logic:
TypeScript