Documented fact
A statement tied to a named source and its scope. The source should describe the same token, network or operation discussed in the guide.
Ask: Can you open the source and locate the information?
Research methodology
How we assess stablecoin claims
A citation can support a technical fact without supporting the conclusion attached to it. Our guides separate what a document says, what can reasonably be inferred, and what still needs evidence.
Three different kinds of statement
Our interpretation
A conclusion drawn from identified facts, with the reasoning and assumptions made explicit. It is not a measurement of a service unless that service was actually tested.
Ask: Does the reasoning follow, and what could change it?
Example statement
Matching a ticker alone is not enough to establish that two balances use the same token and network.
Not established
A claim whose supporting evidence is missing, too narrow, inaccessible or out of date. Repetition, a polished interface or a search position does not resolve that gap.
Ask: Which records, systems, dates and independent checks would support it?
An unsupported claim
“The provider keeps no identifying records because it advertises a no-logs policy.”
The label alone does not establish this.A claim under examination
Read one claim all the way through
An explorer shows a transaction as successful. Does that mean the receiving service has credited the balance?
Illustrative reasoning exercise — not a report about a real transfer.
What the network evidence can establish
An explorer can expose the transaction, its network and execution result. For a token transfer, the relevant token and transfer event also matter; a success label alone is not the whole record.
What does not follow
A network record does not, by itself, show an internal customer balance. It also does not prove that the recipient accepts that token representation or that a later payout has happened.
What evidence is still needed
The destination’s current acceptance and credit rules, plus its record of that deposit. Treat a missing credit as a separate question, not proof that the network transfer failed.
Technical background: Ethereum transaction lifecycle (opens in a new tab)
What would justify a provider review?
A useful review needs more than a homepage screenshot or a successful small transfer. These are the evidence questions to ask before accepting a rating or recommendation.
- A precisely identified service
- The domain, operator information, selected product and date of the observations. Similar branding is not proof that two sites have the same operator.
- A defined test and its limits
- What was observed, under which conditions, and what was not tested. One transaction cannot establish future performance, solvency or all retention practices.
- Terms that can be checked
- Custody, fee units, supported networks, failure handling and relevant restrictions. A stated policy and evidence of its implementation are different things.
- A visible commercial disclosure
- Any relationship that could influence the recommendation belongs beside it. A referral link is not evidence that a service has passed an independent technical audit.
These are review criteria, not a claim that an external partner has passed them.
When sources change or disagree
Check that both documents describe the same network, token representation and date. A current issuer record and an old integration guide can disagree because the underlying support changed; merging their claims would hide that difference.
A dated source check is a snapshot, not a promise of continuous monitoring. For current support or a live quote, return to the issuer and the receiving service. If the evidence remains incomplete, the conclusion stays limited rather than becoming a definitive recommendation.