Trust Mixer/Editorial policy
Reviewed Search the help deskStart mixing

Editorial policy

The Trust Mixer editorial policy explains which sources carry weight, how a route review is reproduced, and when a published finding is allowed to change.

  1. 01

    Publish the boundary with the statement

    A network fact, provider statement, and unpublished value are labelled differently. The page also shows where the finding applies and when it was checked.

  2. 02

    Start with primary sources

    Block explorers, issuer documents, court records, and official registers come first. Secondary reporting is used when no primary record is available.

  3. 03

    Say when the answer is unknown

    We do not turn a changing fee, disputed legal point, or private server behavior into a confident fact. Unknown is a valid result.

  4. 04

    Move the date only after a real review

    A page date changes when its sources and conclusions are checked again. Cosmetic edits do not make old evidence fresh.

  5. 05

    Keep the handoff out of the finding

    A commercial referral cannot improve a result. The evidence remains the same whether a route has a handoff link or not.

  6. 06

    Use verified for the observed field only

    A dated catalog can verify route flags; a reviewed implementation can verify its default mapping. Neither passes that label to a hidden live override, fee, settlement, or outcome.

How catalog snapshots are reviewed

We read Xuanxi's Source: Public enabled-route catalog, preserve its route order, and reconcile every code and send/receive flag against the local record. The snapshot date changes only after that comparison succeeds.

For contract mappings absent from the catalog, the finding records the inspected first-party revision and whether the value can be overridden in production. The page keeps the configured default and the unknown live override as two different statements.

USDTBSC is the concrete example. The catalog verifies its route flags, Xuanxi revision 1e2d7e0 verifies the configured default, and BscScan identifies that default contract as Binance-Peg BSC-USD. Because the public response does not expose the production override, the live contract remains a separate quote-time check.

If a route disappears or either flag changes, the catalog finding and affected coverage page must change with it. A cosmetic edit does not refresh the evidence date.

How findings are labelled

The six evidence labels and their exact rules live on the methodology page, so they have one definition across the site.

Reproduce a route review

A Trust Mixer route review can be repeated without access to a private account or internal dashboard. Start with the dated public catalog, then check the network and issuer sources that apply to the asset.

  1. 1

    Record the exact route code, asset, network, source URL, and UTC date. A broad ticker such as USDT is not enough to identify a token contract.

  2. 2

    Compare both catalog flags. The route is marked verified only for the field the snapshot actually exposes: a listed code with send and receive enabled.

  3. 3

    Open the relevant public ledger or issuer document. Keep token identity, transfer visibility, freeze authority, and provider terms as separate findings.

  4. 4

    Mark quote-time values as not published when the public source does not expose a current fee, minimum, delay, settlement time, or production override.

Sources used in the route layer

The source registry keeps the reference attached to the claim rather than at the bottom of an unrelated page. The current policy relies on the following first-party records for the most repeated decisions.

Read the methodology, inspect the USDT route hub, or review corrections and disclosure.

Maintained by the Trust Mixer editorial team. Method v1.4.