Repeatedly entering the same destination recipient address in AllSwap groups multiple incoming transactions, assets, amounts, times, balance changes, and later transfers in one public on-chain view. A third party may combine those records with cross-chain timing and amount patterns, public identity information, or exchange records to infer usage frequency, asset preferences, and possible address ownership. Such attribution is generally probabilistic, however, and does not necessarily identify a particular natural person correctly.
First, distinguish a recipient address from a one-time deposit address
In this article, the “recipient address” is the destination-chain address that a user enters when creating an AllSwap order to receive the destination asset. In the normal flow, the user first selects the source and destination networks and assets, then enters the recipient address. Only after the order is created does the payment page display the one-time deposit address dedicated to that order. The user sends the source asset to this payment endpoint, and the settlement network subsequently sends the destination asset to the recipient address the user entered.
These addresses have different purposes. A user may decide whether to use a different recipient address when their wallet or destination service supports it. However, the one-time deposit address from an AllSwap order must never be saved and reused for another swap. An old deposit address may have expired and does not automatically inherit a new order's asset, network, amount, Memo, or quote conditions. Sending funds to it again may prevent the payment from being identified or processed automatically.
What information becomes aggregated when an address is reused?
When the same address receives funds repeatedly on a public blockchain, an observer can generally use a block explorer or node data to view and aggregate:
- the asset or token contract, amount, block time, and transaction hash for each incoming payment;
- the address's current and historical balances, other token holdings, and balance changes over time;
- the wallets, contracts, merchants, or labeled service addresses to which the funds later move;
- some senders, recipients, and smart contracts that have interacted with the address; and
- receipt frequency, common amount ranges, active hours, and patterns such as long-term holding or rapid onward transfers.
For example, the public account information described in the Ethereum documentation on block explorers includes address balances, tokens, and incoming and outgoing transaction history. On account-model networks of this kind, one address usually represents an account state that is updated over time. Reusing it therefore creates a relatively complete activity timeline in one place.
Bitcoin and other UTXO, or unspent transaction output, networks work differently. Assets are represented by a set of outputs that have not yet been spent rather than a single account balance that simply rises and falls. Reusing an address still links multiple receipts directly. If a wallet later combines several inputs in one transaction, an observer may also infer that those inputs are controlled by the same entity and analyze the change output and subsequent movements. The Bitcoin developer documentation therefore recommends avoiding address reuse. Input clustering and change detection remain analytical heuristics, not definitive proof of ownership; shared services, complex transaction structures, and incorrect labels can produce false conclusions.
Can a cross-chain swap create additional association clues?
It can. An AllSwap transaction leaves a payment to the order's deposit address on the source chain and a receipt of the destination asset at the recipient address on the destination chain. The two records do not necessarily have a single direct link that an ordinary observer can click to confirm their relationship. The quote, fees, price movement, and processing time can also change the amount delivered. Nevertheless, a third party may compare asset and amount patterns, order of events, and timing windows across the source and destination chains.
If one destination recipient address repeatedly receives the proceeds of swaps, an analyst has more samples to cluster. Identity-association clues increase further if the address is linked to a public name such as ENS, published on social media, a donation page, or a merchant payment page, or later interacts with an identity-verified centralized exchange. Conversely, an on-chain label can be stale or wrong, and a match based on similar timing and amounts can be coincidental. “Traceable” therefore does not mean “proven to belong to a particular person.”
Confirmed public on-chain history is generally retained by the network for the long term. Even if a user stops using an address, or AllSwap later deletes or de-identifies records within its control according to policy, this cannot rewrite a transaction that has already been recorded on-chain. The AllSwap Privacy Policy explains the different boundaries for order data, website technical data, and blockchain records.
How can users balance recipient privacy and operational safety?
- Confirm who controls the address first. Consider using different recipient addresses by purpose only if the wallet supports this and you can securely retain control of the relevant private key or account. Never copy an arbitrary “new address” from the internet, and do not interpret a changed address as a guarantee of anonymity.
- Separate purposes instead of changing addresses blindly. Using different self-controlled addresses for personal savings, public receipts, and merchant settlement can reduce direct aggregation on one page. Common funding sources, similar timing and amounts, or later consolidation into the same wallet may still re-establish a connection.
- Verify each order independently before submitting it. Confirm the destination network, asset, and complete address, including the first and last characters. Do not try to substitute a different recipient address after the order has been created merely to improve privacy. Blockchain transfers are generally irreversible, and assets sent to the wrong address may not be recoverable.
- Follow the exchange's deposit rules. If the destination is a centralized exchange, use only the deposit address currently displayed by that exchange for the exact asset and network. Meet its minimum deposit and Memo, Tag, or reference requirements. If the AllSwap recipient form does not provide a destination-side Memo or Tag field, do not use an exchange address that requires one. A safer approach is to receive the swap first in a compatible wallet that you control and then deposit to the exchange according to its instructions. Never substitute a different address merely to reduce reuse unless the exchange has confirmed it.
- Check the refund address separately. A refund address belongs to the source-chain exception-handling route; it is not the destination recipient address. It should be compatible with the source network and asset, remain under your long-term control, and allow you to demonstrate ownership. Retain the order ID, one-time deposit address, and source-chain transaction hash. If no refund address was provided, a refund first goes to AllSwap's fallback address. The user must then contact official support and provide genuine proof of payment; after verification, the platform processes the refund manually.
- Limit information you disclose publicly. Do not publish a full address together with an order ID, transaction hash, and unredacted screenshots on social media or in public groups. When troubleshooting, share only the necessary information through an official channel listed in the AllSwap Help Center. Never provide a private key, seed phrase, wallet password, or one-time authentication code.
Using different addresses is a way to reduce the direct aggregation of activity; it is not a method for evading on-chain analysis, sanctions screening, anti-money-laundering requirements, or lawful investigations. A VPN, clearing cookies, or generating another address cannot erase existing blockchain records or guarantee anonymity. Address management should always remain compatible with the destination service, preserve reliable user control, and allow assets to arrive correctly. When privacy and deliverability conflict, preventing a wrong-network transfer, incorrect address, or missing Memo should take priority because those errors can cause an actual loss of funds.
Related help
For further checks, consult the AllSwap Privacy Policy, Cross-Chain Swap Risk Disclosure, and the official support channels identified in the Help Center.