AllSwap processes IP addresses, User-Agent data, timestamps, and the addresses needed to execute a swap, but its public materials do not establish that every IP address is stored in a linked record with every wallet address. Swap requests and status records may be retained for up to 12 months. Standard server access logs are usually kept for 7–30 days, although this is not a hard maximum guaranteed by the Privacy Policy. Specific retention periods for cookies and customer support records have not been published.
What can—and cannot—be confirmed today?
According to the AllSwap Privacy Policy, visiting the website may involve processing an IP address, a User-Agent string (basic browser or device information transmitted with a request), and the time of access. Creating and executing a swap involves processing the source and destination assets, the relevant blockchains, the amount, the user's slippage preference, the order-generated deposit address, and the destination recipient address entered by the user. The actual order flow may also process an optional refund address supplied by the user. Quote generation, order creation, deposit detection, swap processing, and the final success or refund result create activity records related to that swap.
The AllSwap no-KYC swap explanation also states that AllSwap does not proactively build associations between IP addresses and wallet addresses, and that standard server access logs are usually retained for 7–30 days. This describes AllSwap's published data-handling and ordinary operating position. It does not mean that linking the data is technically impossible, nor does “usually 7–30 days” create a hard retention ceiling under the Privacy Policy. Network-access data and order data may both be processed by technical systems. AllSwap has not publicly documented whether these fields sit in the same database record, can be connected through an order ID or timestamp, or are available to the same personnel.
The most accurate conclusion is therefore: public information is insufficient to show that every IP address is linked and stored with every wallet address, but it is also insufficient to guarantee that the two data sets remain technically isolated in every circumstance. The absence of a registered account and the stated policy of not proactively creating an identity profile can reduce the collection of conventional account data. It does not mean that a swap leaves no technically correlatable records or that on-chain activity is anonymous.
Why does “source address” need a separate explanation?
Several different addresses are easily confused:
- Deposit address: the one-time address generated for an order and shown to the user for sending the source asset. The Privacy Policy expressly identifies this as order data.
- Destination recipient address: the address entered by the user to receive the destination asset. An optional refund address, if supplied, designates where a refund should be sent if an exception occurs.
- Payment source address: the wallet address, exchange hot wallet, or UTXO inputs that appear in the on-chain payment. A UTXO is an earlier transaction output spent in a new transaction on networks such as Bitcoin. One payment can contain several inputs, so there may be no single, persistent “sender address.”
The published policy does not say that AllSwap creates a separate “user source address” database field for each order. However, deposit detection requires the system to identify a blockchain transaction sent to the order's deposit address. The transaction hash, input or sending addresses, amount, and time may also be publicly visible on the relevant blockchain. Consequently, the fact that a source address is not expressly listed as a field that AllSwap proactively collects does not make the payment path unobservable, and it cannot support a promise that the source will never be technically associated with the order.
When a user pays from a centralized exchange, the on-chain source may be the exchange's hot wallet rather than the user's personal deposit address at that exchange. This illustrates why an on-chain source address does not necessarily identify a natural person. Conversely, if a wallet has previously been connected with a verified platform account, a public identity, or other activity, a third party may still use blockchain analysis to attribute it.
How long is each category of data retained?
There is no single “12-month” answer for every data category. The currently published boundaries are:
| Data layer | Published processing or retention position | Important limitation |
|---|---|---|
| Swap requests and status records | Retained for up to 12 months for support verification, dispute handling, and legal compliance, then periodically destroyed or de-identified | This consumer-order position applies when addresses, assets, chains, amounts, and statuses are order fields. De-identification does not delete the corresponding blockchain history |
| IP address, User-Agent, timestamp, requested URL, and other standard access logs | Usually retained for 7–30 days | This is the ordinary operating period disclosed on the no-KYC page, not a hard maximum written into the Privacy Policy. How logs may relate to orders and who can access them have not been published; the 12-month period should not be applied to these logs by assumption |
| Essential and security cookies | Used for language, theme, time zone, CSRF protection, and rate limiting, with limited anonymous page-view counting | Existing public materials do not provide one specific lifetime for every cookie. Anonymous counting does not make an order or wallet activity untraceable |
| Customer support materials submitted by the user | May contain an order ID, TxID, contact details, an explanation, and redacted evidence | No specific retention period has been published, so these materials cannot be assumed to disappear automatically when the order record is deleted |
| Blockchain records | Permanently public and immutable on the relevant public blockchain | On-chain addresses, amounts, timestamps, and transaction hashes are beyond AllSwap's database-deletion controls. AllSwap cannot rewrite or erase the ledger history |
The 12-month period is the published position for ordinary consumer swap requests and status records. It should not be mixed with any separate rules for business API customers. Users should also distinguish destruction from de-identification. Destruction removes a controlled copy, while de-identification may preserve a record or statistics that no longer directly identify a person. The published policy does not specify which treatment applies to every individual database field.
How can privacy-conscious users reduce unnecessary correlation?
- Submit only information needed to complete the swap. Check the recipient and refund addresses character by character. Do not expose unrelated wallet balances, email addresses, phone numbers, or other orders in support screenshots.
- Treat the three record layers separately. Browser-access metadata, AllSwap order records, and public blockchain transactions are generated by different systems. Clearing cookies or requesting deletion of site-controlled data cannot erase a confirmed on-chain transaction.
- Reduce unnecessary address reuse. Using addresses you control for separate purposes can reduce direct aggregation at the address level. It cannot guarantee anonymity or prevent lawful risk screening or investigation.
- Keep order evidence secure. An order ID, deposit address, and transaction hash can help resolve a missing payout or refund. Store them on a trusted device rather than posting complete order screenshots publicly. Legitimate support never needs a private key, seed phrase, wallet password, or one-time verification code.
- Make a precise data request. To request access, rectification, erasure, objection or restriction of processing, or data portability, email
[email protected]and identify the relevant order, data category, and requested action. The response may be limited by applicable law, necessary identity verification, dispute handling, legal retention duties, and technical feasibility. Blockchain records cannot be erased in response to such a request.
Do not treat changing an address, clearing browser data, or using a VPN or another network tool as a guarantee of anonymity. Such actions may change only some observable signals. They do not remove public blockchain history or prove that no other connection exists between AllSwap access logs and order fields. If the privacy implications affect whether you should proceed, read the latest published policy and make the decision from confirmed boundaries rather than an unverifiable absolute promise.