Mixer protocol
A practical framework for reading mixer pages, separating visible blockchain facts from marketing claims, and understanding where network context changes the risk picture.
| Category | What to check | What not to assume |
|---|---|---|
| Network claims | ERC20/TRC20 support, fee context, explorer visibility | That one network makes a transfer invisible |
| Privacy claims | Wording, limits, visible on-chain data, stated assumptions | That absolute privacy can be guaranteed |
| Risk context | Counterparty type, address age, labels, and source documentation | That every risk label is complete or correct |
| Service scope | Whether deposits, addresses, routing, or order creation exist | That an information page is a live mixer |
A complete review needs a definition, the correct network, visible records, risk context, policy wording, and a clear list of conclusions that the available evidence cannot support.
Evaluation protocol
Write the exact claim, identify the network, inspect visible evidence, state unavailable evidence, and choose the next check before reaching a verdict.
| Step | Question | Safe output |
|---|---|---|
| 1 | What exact phrase is being evaluated? | A quoted or narrowly paraphrased claim, not a generalized promise. |
| 2 | Which network and record layer matters? | ERC20, TRC20, explorer, token contract, wallet history, support, or policy context. |
| 3 | Which evidence is unavailable? | Private infrastructure, platform records, legal conclusions, and hidden methodology are marked as unverified. |
| 4 | Which evidence should be checked next? | Continue with risk signals, source of funds, review criteria, or trust signals. |
Protocol boundary
NO AML and NO KYC concern stated screening. NO LOGS concerns retention. UNDETECTABLE and INVISIBLE concern observability. INSTANT concerns timing. Combining them into one privacy promise hides the evidence needed for each.
Preserve the exact wording and scope. A claim about onboarding cannot establish retention behavior, network visibility, or an outcome.
Use public-chain data for visibility, policy text for stated rules, and dated support or status records for service claims.
Do not infer private logs, exchange treatment, identity, legal conclusions, or operational results from public wording alone.
Review workflow
Apply the same questions to every commercial claim: what is promised, which network is involved, which record can be inspected, what remains unavailable, and which conclusion is justified.
Separate network support, trust, fees, logs, exchange screening, and privacy outcomes. Similar wording can refer to entirely different evidence.
Write the strongest useful version of the claim, then mark the boundary. A phrase like UNDETECTABLE can be discussed as a market claim, but the safe output explains which signals remain visible and which evidence is not available.
Continue with source of funds, address reuse, trust signals, or blockchain analytics when the first answer leaves an evidence gap.
Worked example
Retention language becomes easier to evaluate when it is separated from blockchain visibility and independent verification.
Identify which data categories the claim covers: account data, browser data, support conversations, transaction metadata, infrastructure records, or something narrower. A broad slogan with no categories leaves the central question unanswered.
ERC20 and TRC20 transfers remain visible through compatible network tooling regardless of a site's retention statement. Keep token movement, timestamps, addresses, and wallet history outside the meaning of NO LOGS.
Public policy text can show what a publisher claims, but it cannot independently prove private handling. Compare the no-logs guide with the privacy-policy review and mark unresolved gaps.
Primary protocol sources
The framework uses these sources for technical vocabulary and public-record boundaries. They do not verify a private service, its retention practice, or a promised outcome.
Ethereum.org's ERC-20 standard supports the distinction between token transfers, approvals, and the wider Ethereum record.
TRON Developer Hub's TRC-20 documentation anchors token-event terminology and network-specific resource context.
Tether's supported-protocols reference identifies the issuer's deployment context; current claims still require a dated page-level check.
Mixer Atlas guide