Taint analysis assigns exposure under a chosen allocation model; it does not discover one objective percentage embedded in a transaction. A synthetic example shows how proportional and first-in allocation can produce different results from the same inputs.
What remains visible
Taint assumptions can differ between Bitcoin-style UTXO flows, ERC20 token transfers, TRC20 token transfers, bridge activity, exchange records, and platform-side context.
What it does not prove
A taint score does not automatically prove ownership, intent, legal status, source of funds, or platform outcome. It is an analytical signal that needs method context.
Evaluation checklist
- Name the model assumption before interpreting a score.
- Avoid treating scores, labels, or clusters as identity proof.
- Explain proportional exposure limits and data-quality limits.
- Link taint wording to analytics labels, graph analysis, and source context.
Two-model taint worked example
The numbers are fictional and illustrate model sensitivity, not a score for any real address or transaction.
Freeze the inputs
Record tagged and untagged amounts, order, transaction model, and data coverage.
Apply named models
Calculate each result separately under proportional and first-in allocation assumptions.
Report divergence
Show the range, data limitations, and why the model choice changes the conclusion.
Filled evidence record
Two-model taint worked example snapshot: 2026-08-05. The worked record for taint analysis mixer labels every synthetic or non-attributed specimen directly in the table.
| Evidence item | Worked record | Interpretation boundary |
|---|---|---|
| Synthetic input | An address receives 20 tagged units and 80 untagged units, then sends 50 units. | Ownership, purpose, and real-world identity are intentionally absent. |
| Proportional model | Tagged share is 20%; the 50-unit outgoing transfer is assigned 10 tagged units. | Assumes homogeneous mixing of inputs. |
| First-in model | If the tagged 20 units are allocated first, the same outgoing transfer receives 20 tagged units. | Depends on ordering and an allocation rule, not an observed property of the output. |
Pass or hold criteria
For taint analysis mixer, a missing decisive input remains unknown and blocks the affected conclusion; the two-model taint worked example never converts it to a silent pass or zero.
| Dimension | Pass condition | Hold or fail condition |
|---|---|---|
| Inputs | Amounts, order, coverage, and transaction model stated | Score appears without data |
| Model | Allocation rule named and reproducible | Taint treated as objective fact |
| Conclusion | Result tied to method and range | Identity, intent, or legal outcome inferred |
Next evidence layer
Blockchain Analytics vs Mixer Claims
Blockchain Analytics vs Mixer Claims adds visibility guide context to taint analysis mixer. Define analytics separately from identity. An analytics label is not always a legal identity, and a mixer claim is not always a verified privacy outcome. Both require context.
Transaction Graph Analysis For Mixer Claims
Transaction Graph Analysis For Mixer Claims adds visibility guide context to taint analysis mixer. Define nodes and edges plainly. A graph pattern is not automatically identity proof. It can suggest relationships, but interpretation depends on evidence quality, tooling, and off-chain context.
AML Risk Labels And Mixer Context
AML Risk Labels And Mixer Context adds risk guide context to taint analysis mixer. Define labels as signals. A label does not automatically prove identity, intent, or final outcome. It should be reviewed with visible transaction data and source context.
Source of Funds And Mixer Risk
Source of Funds And Mixer Risk adds risk guide context to taint analysis mixer. Define source of funds clearly. Documentation does not erase public-chain history. It can help explain a transaction, but it does not change what explorers show.
Source notes
The sources below clarify taint analysis mixer terminology and the evidence limits described above. They do not verify private service operations or guarantee an outcome.
Related questions
What if a provider uses a proprietary model?
Record the published inputs and limits; if the allocation rule cannot be reproduced, treat the percentage as provider-specific rather than universal.
What if data coverage misses an earlier input?
The result may change materially, so the page should flag incomplete coverage and avoid a definitive exposure percentage.