How STONfi Handles Bounceable and Non-Bounceable Addresses on TON
TON addresses can look different while identifying the same on-chain account. EQ... is the bounceable form, while UQ... is non-bounceable. When the workchain and account identifier are identical, both can represent the same account.
What Bounceable Means
Bounceability describes message behavior, not a permanent account property. A TON user-friendly address contains flags that help software determine how a message is handled.
With bounceable delivery, if processing fails under applicable conditions, remaining value can return toward the sender. This makes bounceable messages suitable for smart-contract interactions.
Non-bounceable delivery is useful when funding an account that has not been initialized. On TON, wallets are smart contracts, and their addresses can be known before deployment. Unsuitable bounce behavior for an uninitialized destination can cause the transfer to fail instead of funding the account.
How STONfi Uses Addresses
A STONfi's swap can involve the connected wallet, Jetton masters, routers, pools, receiver, refund and excess addresses.
The initial transaction target is the contract receiving the wallet message. Other addresses can travel inside the payload as TON address values.
Since STONfi SDK v0.5.0, generated to parameters use bounceable addresses because protocol contracts are expected to exist and execute logic. This follows TON practice for established contract interactions.
Why Developers Should Parse Addresses
A common mistake is comparing EQ... and UQ... as plain strings and assuming they are different wallets. Instead, parse them into proper TON Address objects and compare the underlying workchain and account identifier.
This matters for integrations, validation and transaction construction. Developers should preserve the workchain and rely on trusted TON tooling for address encoding.
$STON $RAY
#BTC Price Analysis#
TON addresses can look different while identifying the same on-chain account. EQ... is the bounceable form, while UQ... is non-bounceable. When the workchain and account identifier are identical, both can represent the same account.
What Bounceable Means
Bounceability describes message behavior, not a permanent account property. A TON user-friendly address contains flags that help software determine how a message is handled.
With bounceable delivery, if processing fails under applicable conditions, remaining value can return toward the sender. This makes bounceable messages suitable for smart-contract interactions.
Non-bounceable delivery is useful when funding an account that has not been initialized. On TON, wallets are smart contracts, and their addresses can be known before deployment. Unsuitable bounce behavior for an uninitialized destination can cause the transfer to fail instead of funding the account.
How STONfi Uses Addresses
A STONfi's swap can involve the connected wallet, Jetton masters, routers, pools, receiver, refund and excess addresses.
The initial transaction target is the contract receiving the wallet message. Other addresses can travel inside the payload as TON address values.
Since STONfi SDK v0.5.0, generated to parameters use bounceable addresses because protocol contracts are expected to exist and execute logic. This follows TON practice for established contract interactions.
Why Developers Should Parse Addresses
A common mistake is comparing EQ... and UQ... as plain strings and assuming they are different wallets. Instead, parse them into proper TON Address objects and compare the underlying workchain and account identifier.
This matters for integrations, validation and transaction construction. Developers should preserve the workchain and rely on trusted TON tooling for address encoding.
$STON $RAY
#BTC Price Analysis#