The short answer
Pseudonymous is not the same as anonymous. Decide which information is exposed and to whom before evaluating a privacy claim.
Four questions, four different kinds of evidence
| Layer | Question | Relevant evidence |
|---|---|---|
| Public ledger | What transactions and balances are visible? | The chain's explorer and protocol documentation. |
| Attribution | Can an address be connected to a person? | Offchain records and a stated analytical method. |
| Service data | What does an operator retain? | A scoped privacy policy and relevant audit evidence. |
| Issuer / recipient | Can tokens be blocked or refused? | Issuer terms and the recipient's own policies. |
Reduce unnecessary disclosure without inventing guarantees
Do not publish wallet information or transaction details you do not need to publish. Check what a website asks for before connecting anything, and never share a seed phrase or private key with a support contact.
These are basic information-handling precautions. They do not establish that an address cannot be linked to you, and they do not remove obligations under applicable law.
A credible privacy claim names its limits
“Private from whom?” is the useful first question. A claim about what another ordinary user can see is different from a claim about what a custodial operator knows. An operator's promise to delete internal records does not delete the chain's own records.
If a claim does not identify its threat model, evidence and exceptions, there is no clear proposition to test. A confident adjective is not a substitute for those details.
Does USDT or USDC become private on another network?
USDT and USDC do not acquire an anonymity guarantee from choosing TRON, Ethereum, BNB Smart Chain, Base, Polygon or Solana. First establish the exact token representation. Then separate what the chain reveals from what the issuer, service and recipient can know or control.
An Ethereum explorer documents one chain's public records; it is not an attribution test for every network. A crosschain operation creates additional events and dependencies, not evidence that earlier records were erased. USDT and USDC issuer restrictions also differ from any intermediary's privacy policy.
A privacy checklist with testable questions
- Public visibility: identify which address, token and transaction details are visible on the correct chain.
- Attribution: ask what evidence connects the observed addresses to a person. Do not treat a guess as an identity finding.
- Service records: identify data categories, retention, processors and any audit limitations.
- Registration and KYC: read when information can be requested, including after a deposit.
- Screening and issuer controls: examine these separately from registration. No account does not mean no checks.
- Privacy levels: require a documented mechanism and bounded evidence; low, medium and extra are not standardized privacy measurements.
Mixer, exchange, swap or bridge: different privacy questions
A custodial exchange can keep customer and transaction records. A swap changes the asset; a bridge changes the chain or representation. A mixer claims to change how an observer associates inputs and outputs. Compare those claims separately: changing assets or chains does not itself establish unlinkability.
To reduce unnecessary disclosure, review what you publish and what a service asks you to supply. Do not share wallet details publicly without a reason, and never give support a private key. These information-handling precautions cannot guarantee that existing records or later activity will not be linked.
Test the claim against the observer
| Claim | Observer or system | Evidence still needed |
|---|---|---|
| Private | Public reader, operator, issuer or recipient | The exact data visible to that observer. |
| No KYC | Registration and review process | Exceptions, thresholds and later requests. |
| No logs | Application, infrastructure and support systems | Scope, retention, processors and dated inspection. |
| Untraceable | Chain analyst or attribution process | Method, uncertainty and known limits; never an absolute guarantee. |
Where a USDT mixer's privacy promise can fail
| Risk | Why it matters | What to check |
|---|---|---|
| Public transaction history | An intermediary does not erase earlier chain events. | The actual observer and the evidence behind the claimed privacy change. |
| Operator-controlled funds | A privacy claim does not establish reserves or withdrawal access. | Custody, control permissions and the documented withdrawal process. |
| Offchain records | Account, support or infrastructure records are separate from blockchain records. | The dated retention scope and what was actually inspected. |
| Token and issuer restrictions | USDT remains subject to its token terms and applicable issuer controls. | The exact representation and the relevant issuer documentation. |
| Recipient compatibility or review | A recorded output need not be a usable credited balance. | The recipient's asset, network, confirmation and review requirements. |
| False identity or support claims | A logo, ranking or chat account can misrepresent who operates a site. | Independently established domain and contact provenance before disclosing information. |
Privacy from whom?
A privacy claim needs a named observer: a public ledger reader, an operator, an issuer or a recipient. Hiding information from one does not establish that it is hidden from the others.
USDT and USDC transfer history, attribution, service records and issuer or recipient controls are separate questions. A policy describes what an operator says; it does not prove the deployed system follows it.
| Layer | Question | What a service label does not prove |
|---|---|---|
| Public ledger | What token transfers and address history are visible? | That the history is erased or unavailable. |
| Attribution | What evidence connects an address to a person or activity? | That a new address cannot be associated. |
| Operator records | What application, support or infrastructure data is retained? | That a no-logs phrase covers every system. |
| Issuer and recipient | Can tokens be restricted or a deposit refused? | That a route bypasses issuer or compliance controls. |
Does changing the network make a transfer private?
No. TRC20, ERC20 and BEP20 identify transfer environments, not a demonstrated privacy result. Token compatibility and the observer's access are separate checks.
For a claim of anonymity, require a stated observer, mechanism and inspected evidence. Without that scope, the outcome remains unverified.
| Check | What it can establish | What it cannot establish |
|---|---|---|
| Token and chain | Which asset and ledger the transfer uses. | That the transfer cannot be associated. |
| Recipient instructions | Whether the stated deposit network is supported. | That the recipient accepts a privacy claim. |
| Public record | The observed transaction and address history. | The real-world identity or internal service logs. |
| Privacy wording | The scope and evidence an operator chooses to publish. | A guaranteed anonymous or untraceable result. |
A mixer label does not remove AML or sanctions questions
No AML is a claim about legal or compliance obligations, not a token feature. A network, wallet or mixing label cannot establish that an operator, recipient or transaction is outside applicable requirements. The relevant business model, jurisdiction, issuer terms and recipient policy need separate evidence.
Treat an offer that promises to bypass screening as a material risk signal. StableMatrix provides a distinction between public information and legal advice; it has not assessed a named provider's compliance program or a particular transaction.
| Phrase | What it may describe | What it does not settle |
|---|---|---|
| No KYC | A stated interface or identity-check policy. | Applicable obligations, exceptions or later screening. |
| No AML | A marketing assertion about controls. | Whether the business model or transaction is lawful. |
| Private | A claimed observer and scope. | Issuer restrictions, recipient review or public history. |
Source notes
Each reference has its own last-check date. That is not its publication date. Follow the live document for current terms and identifiers.
- Ethereum.orgBlock explorersPublic transaction, block and address data, rather than proof of a person's identity. Document date not recorded. Checked: 2026-09-20.
- CircleUSDC TermsRedemption conditions, blocked addresses, third-party platform boundaries and transfer risks. Document date not recorded. Checked: 2026-09-20.
- TetherToken terms and risk disclosuresIssuer rights, redemption conditions, restrictions, and third-party wrapped-token risks. Document date: 2026-02-26. Checked: 2026-09-20.
- CircleUSDC contract addressesIssuer-listed mainnet identifiers. A token listing is not a service endorsement. Document date not recorded. Checked: 2026-09-21.
- TetherSupported protocols and integration guidelinesExact issuer-listed asset/network combinations, including discontinued protocols. Document date not recorded. Checked: 2026-09-21.
- U.S. Treasury / OFACFAQ 560: digital currency obligationsSanctions obligations for U.S. persons and others subject to OFAC jurisdiction. Document date: 2018-03-19. Checked: 2026-09-20.
- CircleCross-Chain Transfer ProtocolUSDC burn-and-mint transfers across supported networks; not an anonymity mechanism. Document date not recorded. Checked: 2026-09-20.
- FinCENVirtual currency regulatory frameworkHistorical 2019 explanation of how money-transmission rules apply to certain business models. Not a present-day legal clearance. Document date: 2019-05-09. Checked: 2026-09-20.