Methodology v1.2

The trust framework: how a claim becomes a status

Trust is not a badge. It is a dated chain of evidence you can inspect. This page is the rulebook: every status on the site is produced by the process described here, so you can re-check any verdict yourself.

Methodology version

v1.2

Effective date

2026-07-08

Maintained by

Trust Mixer Verification Desk

The process

How verification works

There is no hidden score. A claim moves through four steps and resolves to a single status.

01
State the claim
Take one specific statement — a fee, a no-logs posture, a legal fact — and write it down exactly, without softening or inflating it.
02
Find a source
Look for something anyone can re-check: a public ledger, a primary document, an issuer page. If none exists, that itself is the finding.
03
Set the scope and date
Record whether the fact is network-wide, issuer-wide, or per-route, and the date it was checked. Scope and freshness change what a claim means.
04
Assign a status
Verified, partially verified, claimed by provider, not published, unknown, or failed. The status is the verdict — there is no hidden number behind it.

The verdicts

The six statuses, defined once

Each status is a plain-language rule, not a number. This is the entire vocabulary we use.

Verified: Independently observable right now on a public source we link. Re-checkable by anyone.
Partially verified: Part of the statement is confirmable; the rest depends on the specific route or moment.
Claimed by provider: Stated by the operator or a third party. We report the claim; we do not confirm it here.
Not published: No stable public figure exists to cite. Real values vary by route and change over time.
Unknown: We cannot confirm this either way and will not guess.
Failed: We checked this and it did not hold. Treat it as a warning.

The rulebook

What we evaluate, and the rule for each status

Eight dimensions. For each, the exact condition that earns Verified, what stays Claimed, and what marks a Failure.

Verification dimensions and status rules
Dimension	Earns Verified	Stays Claimed	Marks Failed	Typical
Ledger visibilityAre transfers on this network publicly inspectable?	Every transfer is visible on a public block explorer we link.	Not applicable — chain visibility is a matter of public record, not provider claim.	A route promises the transfer will not appear on-chain at all.	Verified
Issuer controlCan the token issuer freeze the balance after it moves?	Issuer freeze authority is documented on the issuer's own transparency page.	A route claims it can shield funds from an issuer freeze.	A route guarantees an issuer can never freeze the resulting balance.	Verified
No-logs postureDoes the operator state it keeps no records tying you to a transfer?	Independently observable absence of accounts, email, or history — rare and hard to prove.	A stated no-logs policy with no account or identity wall. This is the usual honest ceiling.	The interface requires an account, email, or history that contradicts a no-logs claim.	Claimed by provider
No identity wallDoes the route ask for identity documents or verification?	Directly observed: the interface asks only for a destination address.	Operator states no KYC, not yet re-observed this review cycle.	A verification wall, document upload, or account appears before you can transact.	Claimed by provider
No surprise AML holdAre terms fixed up front, with no after-the-fact hold or release fee?	Terms are shown before you commit and do not change at settlement.	Operator states no holds; behaviour must be confirmed on the live interface.	A hold or 'compliance fee to release funds' appears only after you deposit — a known scam pattern.	Claimed by provider
Fee transparencyIs the fee quoted clearly before you commit?	A fixed, up-front quote that does not move between request and settlement.	Fee is described as a range or 'varies by route' — confirm the exact figure on the interface.	The fee shifts after deposit, or a new fee appears that was not quoted.	Not published
Network-match safetyIs the correct network unambiguous before sending?	Asset and network are stated explicitly and match on both ends.	Not applicable — matching the network is the sender's responsibility, aided by clear labelling.	The route is vague about chain or asset, inviting a mismatch that loses funds.	Partially verified
Domain authenticityIs the destination the genuine site, not a clone?	Hostname is shown before handoff and matches the known destination.	Not applicable — verify the hostname yourself; clones imitate everything except the exact domain.	A near-identical look-alike domain, or a hostname hidden behind a redirect.	Partially verified

Worked example

What a single record looks like

This is demonstration data — the shape of a record, not a real transaction.

Example evidence record — not a real transaction

ClaimUSDT transfers on TRON are publicly inspectable

Evidence typeOn-chain / public ledger

ScopeNetwork-wide (TRON)

SourceTronscan (public block explorer)

Checked at2026-07-07

Methodologyv1.2

StatusVerified

A record fixes the claim in place: what was stated, what kind of evidence supports it, how wide the claim reaches, who published the source, and the date it was checked. The status at the bottom is the verdict — nothing is averaged into a number.

When a value genuinely varies by route or moment — a fee, a minimum, a delay — we do not invent a figure. It is marked Not published and confirmed on the live interface instead.

Accountability