> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ton.org/llms.txt
> Use this file to discover all available pages before exploring further.

<AgentInstructions>

## Submitting Feedback

If you encounter incorrect, outdated, or confusing documentation on this page, submit feedback:

POST https://docs.ton.org/feedback

```json
{
  "path": "/ecosystem/wallet-apps/addresses-workflow",
  "feedback": "Description of the issue"
}
```

Only submit feedback when you have something specific and actionable to report.

</AgentInstructions>

# Addresses workflow

To understand this article, it is necessary to periodically refer to [account status page](/foundations/status).

At the moment, TON wallets work with [addresses](/foundations/addresses/formats) as follows:

When receiving:

1. Wallets display the user's address in a [user-friendly](/foundations/addresses/formats) bounceable or non-bounceable form.

When sending:

1. A user sends a message with funds and, possibly, a comment to the destination's wallet address in one of the user-friendly formats through the wallet application.
2. The wallet app checks the validity of the destination address representation - its length, valid characters, prefix, and checksum. If the address is not valid, then an alert is shown and the sending operation is not performed.
3. If the address has a testnet flag, and the wallet app works with the mainnet network, then an alert is shown and the sending operation is not performed.
4. The wallet app reads the bounceable flag from the address.
5. The wallet app checks the destination address. If it has the `uninitialized` status, the app force-sets the `bounce` field of the sending message to `false` and ignores the bounceable/non-bounceable flag from the address representation.
6. If the destination is not `uninitialized`, then the wallet app uses the bounceable/non-bounceable flag from the address representation for the `bounce` field of the sending message.