On this page
The essentials
- Connection does not hand an app your signing keys.
- Proof of login, data signatures and transfers authorize different things.
- Disconnecting does not reverse an action already approved.
Why an app asks for a wallet
An application may need your address to display the right assets, identify an account or prepare a blockchain action. TON Connect is the standard protocol for connecting TON wallets to applications. It lets the wallet handle supported requests without handing the app your signing keys.
That describes the protocol role, not a guarantee about the application. A convincing connect button does not tell you whether a product is useful or its terms are acceptable. Establish the product address and your intended task before opening the wallet request.
What a connection establishes
A connected address tells the app which blockchain account you selected. The app may also request proof of control to authenticate you. With ton_proof, the wallet signs a challenge that the service can verify. That is more than merely reading a public address, but it is not the same as sending coins.
Read the app identity and domain shown by the wallet. Choose the intended account and network. If the details do not match the service you meant to open, cancel. Multiple accounts make this check especially important: the address you used yesterday is not automatically the correct one today.
Distinguish the request types
An app can request a transaction or supported data signature after connection, and some interfaces combine connection and an action in one journey. Follow what the actual confirmation authorizes rather than assuming every connect flow has identical steps.
A signature can be used to prove identity or approve meaningful data. The absence of a coin amount does not by itself mean a request has no consequence. If the wallet cannot present the purpose clearly enough for you to understand it, cancel and ask the service for an explanation.
Read a transaction as a new decision
For an on-chain operation, inspect the recipients, amounts, attached data where understandable and estimated costs. Compare the request with what the app said would happen. An action described as checking access should not quietly become an unrelated transfer.
When there are multiple messages or recipients, review the whole request. A small visible fee is not necessarily the total amount being authorized. Do not use a familiar app name as a replacement for reading the wallet screen.
Know what disconnecting does
Disconnecting ends the connection used for further app-wallet communication. It does not reverse an already completed transfer, erase a published blockchain record or automatically remove every effect of previously approved data. Review those effects separately.
When finished with a service, remove connections you no longer need through the wallet or app controls. If you are troubleshooting, note which account and network were connected before reconnecting; repeatedly switching accounts can make an application issue harder to understand.
Use a four-question routine
Before approval ask: is this the app I intended, is this the right account, what exactly is being authorized and does it match my task? These questions work for a first connection and a returning session.
You should not have to paste a recovery phrase into a Mini App to make TON Connect work. Keep secrets in the wallet recovery process. If a supposed connection form asks for them, stop and verify the product through a known source.
Recognize four different wallet requests
Read the purpose of the current request even when the app presents the journey as a single connect button. The protocol supports distinct actions, and wallets do not all support or display them in the same way. A missing coin amount does not tell you that a signature is meaningless. If the displayed data is too opaque to connect with your task, cancel instead of approving it as a routine formality.
Request | What it is for | What to check |
|---|---|---|
Connect | Establish an app-wallet session and expose the selected address | The application identity, account and network |
ton_proof | Prove control of the wallet for an application's authentication | The intended application and the explanation of the sign-in |
signData | Sign supported data such as text, binary content or a structured cell | The purpose and the actual data you are authorizing |
Transaction | Request a blockchain action that can include several messages | All destinations, assets, amounts, attached actions and costs |
Worked example: viewing a portfolio does not require an unexplained payment
Imagine you open a portfolio app to view items belonging to your wallet. The app asks you to connect the account you use for that collection. After connection, it asks for a clearly explained wallet sign-in proof. You can decide whether authentication is useful for that service; connecting and authenticating are still different steps. Keep the selected account in view rather than relying on the name of the wallet app.
Now suppose the next screen requests a transaction to an unfamiliar recipient while the website still says it is only checking your collection. Stop and compare the two requests. Ask the app to explain the action through its verified support route. Do not interpret a small displayed fee as the whole authorized action. If the app cannot explain the recipients and the operation, decline it; disconnecting later will not undo a completed transfer.
Payment rules are a separate question from wallet connectivity. Digital goods and services sold inside Telegram Mini Apps use Telegram Stars. The existence of TON Connect is not permission to replace every such checkout with a Gram transfer. Read the actual product flow and payment unit instead of using the word connect to infer what a purchase allows.
Use a short routine from connection to cleanup
You can rehearse the inspection without making a payment. Open a service from a known source, read the wallet prompt and cancel it if you are only learning. When a supported data-signing request is involved, read that request too. A successful connection should not become a reason to stop checking later actions.
- Confirm the product's address and purpose before opening the wallet.
- Select the intended wallet account and network, then compare them with the confirmation.
- Name the action: connect, authenticate, sign data or send a transaction. Pause if you cannot tell which it is.
- For a transaction, inspect the whole request and keep its identifier after approval. For other actions, retain the service's relevant confirmation without exposing secrets.
- When finished, remove a connection you no longer need. Check the application's own sign-in controls separately; disconnecting wallet communication is not a universal logout or an undo button.
