From statement to published finding
The review follows the same sequence for a fee claim, a chain fact, an issuer policy, or a legal source.
- Step 1
State the claim
Record the exact statement being reviewed. A fee, no-logs policy, and legal event each need their own finding.
- Step 2
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.
- Step 3
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.
- Step 4
Assign a status
Publish one of six labels: verified, partially verified, provider claim, not published, unknown, or failed.
Example: provider catalog availability
A dated Source: Public enabled-route catalog can verify an exact route code and its send/receive flags. It cannot verify values absent from that response, such as a fee, minimum, settlement time, or successful payout.
Six labels, each with one meaning
A label describes the evidence available at the review date. Provider quality and network quality remain separate questions.
- Verified
- A public source or directly reviewed first-party implementation supports this finding at the stated scope and date.
- Partially verified
- The source confirms part of the statement. The remainder changes by route or time.
- Claimed by provider
- The provider states this, but the available sources do not confirm it independently.
- Not published
- No stable public value exists. Read the current figure from the live quote.
- Unknown
- The available sources do not support a conclusion either way.
- Failed
- The checked source or interface contradicted the statement.
What the review checks
The rule changes with the type of statement. A public chain fact can be reproduced; a server-retention promise usually cannot.
| Area | Verified when | Provider claim when | Failed when |
|---|---|---|---|
| Catalog availabilityDid Xuanxi publish this exact asset and network for send and receive? | The dated public catalog exposes the route code with both availability flags enabled. | The route appears in marketing copy but cannot be reproduced in the checked public catalog. | The route is absent, disabled, or contradicted by the current catalog snapshot. |
| 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 public fact rather than a provider statement. | A route promises the transfer will not appear on-chain at all. |
| 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. |
| No-logs postureDoes the operator state it keeps no records tying you to a transfer? | An independent audit supports the retention policy. Interface behavior alone cannot prove server deletion. | 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. |
| 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. |
| 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 appears only after deposit and changes the agreed terms. |
| Fee transparencyIs the fee quoted clearly before you commit? | A fixed, up-front quote that does not move between request and settlement. | The fee is a range or varies by route. The exact figure must come from the live quote. | The fee shifts after deposit, or a new fee appears that was not quoted. |
| Network-match safetyIs the correct network unambiguous before sending? | Asset and network are stated explicitly and match on both ends. | Not applicable. The interface can assist, but the sender still has to match both network labels. | The route is vague about chain or asset, inviting a mismatch that loses funds. |
| Domain authenticityIs the destination the genuine site, not a clone? | Hostname is shown before handoff and matches the known destination. | Not applicable. The reader can compare the displayed hostname with a trusted source. | A near-identical look-alike domain, or a hostname hidden behind a redirect. |
When evidence changes
A material correction updates the page and its review date. Method changes are kept in a dated changelog.
Primary references used in examples
These records anchor the catalog, issuer, and contract examples used throughout the method.