The shared pool
In a pool-based design, a reserve combines deposits and pays withdrawals. The payout does not travel straight from the deposit address to the fresh address, so the ledger has no direct edge between those two wallets.
A route label such as TRC20, ERC20, or BEP20 does not prove that a service uses a particular pool design. The live order is authoritative for the available entry and payout routes; private implementation details require separate evidence.
More overlapping activity gives an observer more possible deposit-to-payout matches. A quiet pool offers less cover, which is why pool depth belongs in the route decision.
Multi-hop routing
Some designs use intermediate transfers to separate the entry from the final payout. Looking at the fresh address alone does not reveal a one-hop path back to the original deposit, although a broader investigation may still use other signals.
deposit -> hop_1 -> hop_2 -> withdrawal
# intermediate edges obscure a simple one-hop relationship
Randomized time delays
A fixed deposit-to-payout interval is easy to compare. A service can vary that interval, making the clock less useful as a standalone matching signal. A longer delay is a tradeoff, not proof that the route cannot be analysed.
Review the route before sending
Confirm the entry network, payout route, wallet, amount, fee, ETA, and order ID.
What you can verify before sending
The public order screen can confirm the entry network, payout route, wallet, amount, fee, ETA, and order ID. It cannot prove reserve depth, an exact hop count, or a private deposit-to-payout mapping. Treat those architecture claims as unverified unless the service publishes evidence that supports them.
- Match the token and network on the deposit and payout sides.
- Save the order ID and final quote before sending funds.
- Remember that later reuse of an address creates a new visible ledger edge.
Observable matching signals
Amounts, timestamps, path edges, later address reuse, and exchange or other off-chain labels can all contribute to a matching hypothesis. None of these signals alone proves a deposit-to-payout match, but several aligned signals can make a route easier to analyse.
Fresh payout addresses
A route may end at a different payout address instead of the deposit address. That changes the visible endpoint, but it does not guarantee unlinkability or erase later links. A later transfer back to an old wallet creates a new visible edge.
What the route cannot hide
The blockchain remains public. A route does not erase timestamps, amount relationships, path edges, later address reuse, or records held by an exchange or another off-chain party. It also cannot protect a wallet seed or correct a wrong network choice. For the broader definition, retention policy, and website-data boundary, use the pillar guide and the privacy notice.