USDT mixer
A term used for services or concepts that claim to reduce transaction-linkability. Any such claim should be evaluated against public-chain visibility and legal context.
Mixer terminology
USDT mixer terms.
Short definitions for comparing mixer claims, network differences, transaction visibility, and risk language around ERC20 and TRC20 USDT.
USDT
A stablecoin issued on multiple networks. It is commonly used for transfers, exchange settlement, and payments.
ERC20
An Ethereum token standard. USDT on Ethereum is visible through Ethereum-compatible block explorers.
TRC20
A Tron token standard. USDT on Tron is popular because transfers are often cheaper than Ethereum transfers.
Wallet clustering
A probabilistic analytics method that groups addresses when there is evidence they may be controlled by the same entity.
Counterparty risk
The risk created by the entity, platform, or address connected to a transaction.
Source of funds
Documentation or context that explains where assets came from before a transfer.
Term boundaries
Glossary terms are useful only when their limits are visible.
A term page should help readers separate vocabulary from proof. The words below are common in mixer research, but none of them should be treated as a guarantee.
No logs
A retention claim. It does not prove that public-chain records, support records, platform records, browser data, or counterparty context disappear.
Undetectable
A detection claim. It needs a definition of who is detecting what, on which network, with which records, and at what confidence level.
Instant
A timing claim. It may refer to page response, quote creation, broadcast, confirmation, or marketing shorthand. Those are different layers.
Evidence boundaries
How to read this reference without overclaiming.
Mixer Atlas treats high-intent phrases as claim language, not as proof. Terms such as NO AML, NO KYC, NO LOGS, UNDETECTABLE, INVISIBLE, INSTANT, secure, and online can appear in market searches, but a useful page must define the claim, name the evidence layer, and state what remains unverified.
Visible layer
Public-chain records, token contracts, timestamps, explorer views, wallet history, support pages, policy text, and update dates are visible signals. They are useful for review, but they do not automatically identify a person or prove a final outcome.
Claim layer
Publisher wording can describe retention, network scope, support claims, fee language, timing claims, or privacy language. Mixer Atlas keeps those statements separate from verified facts so a reader can see where confidence starts and stops.
Unavailable layer
Private infrastructure records, exchange-side decisions, analytics methodology, legal conclusions, and operational service behavior are outside the direct evidence of this site. Those gaps should be marked, not filled with confident slogans.
Term routing
Definitions become useful when they connect to decisions.
A glossary term should not sit alone. Each definition should tell the reader which page owns the practical follow-up: network visibility, review criteria, trust signals, source-of-funds context, or the FAQ. This keeps commercial phrases usable without letting them drift into unsupported guarantees.
| Term family | Reader intent | Best next route |
|---|---|---|
| NO KYC / NO AML | Understand a policy claim without treating it as a universal guarantee. | Use review criteria, trust signals, and risk-signal pages before any partner handoff. |
| NO LOGS / invisible | Separate retention language from public-chain evidence. | Use privacy-claim, no-logs, wallet-clustering, and transaction-visibility pages. |
| ERC20 / TRC20 | Choose the correct evidence layer for a USDT transfer. | Use the Ethereum and Tron network pages, then compare with explorer visibility. |
| Instant / fee claims | Read timing and cost language with operational limits. | Use time-based claim and fee-claim pages, then check what remains unverifiable. |
Reader shortcut
If a term describes a visible blockchain object, route to explorer, token-contract, or wallet-history pages. This keeps the definition grounded in records a reader can actually compare instead of relying on broad privacy wording.
Policy shortcut
If a term describes a stated service policy, route to review criteria, trust signals, or policy-review pages. The definition should preserve the difference between declared rules, independently verified behavior, and later platform decisions.
Risk shortcut
If a term describes an outcome, route to risk signals first and explain what cannot be verified from public evidence. Outcome language needs the strictest boundary because it is easiest to misread as a promise or a guaranteed operational result.
Mixer Atlas guide