Research and source methodology

Source hierarchy

Sources are selected in this order when they are available and relevant:

1. Current official product documentation, API references, help articles, status pages, terms, rulebooks, and market-specific rules.
2. Official regulatory filings, notices, contract repositories, and technical specifications.
3. Primary research papers or datasets for claims that official product pages cannot establish.
4. Reputable secondary reporting for context, never as the sole authority for a changeable platform rule.

Forums, social posts, affiliate pages, and search snippets may reveal questions worth answering, but they do not establish a material fact by themselves.

Review workflow

1. Define one primary intent and the product in scope.
2. Collect the first-party sources that govern the mechanism, task, or comparison row.
3. Check dates, changelogs, redirects, and newer documentation that may supersede an older help article.
4. Extract the factual state, then explain it in original language with a practical example.
5. Mark what can change and direct the reader to the live source for a final check.
6. Run consistency checks across metadata, visible copy, links, and structured data.

How conflicts are handled

First-party pages sometimes disagree. For example, a consumer help article may lag a protocol migration, or a broad availability table may use a different category label from the API reference. We do not silently choose the claim that makes the product look simplest.

The editorial response is to prefer the newer or more specific governing source, disclose the conflict when it affects a user's decision, and avoid hard-coding a value when the live interface or API is authoritative. The development source manifest is not deployed with the website; each article instead carries the relevant live references.

Comparison method

Comparison rows are chosen around a real decision: product model, eligible user, funding rail, cost structure, order book, resolution authority, custody model, and developer access. Each product is judged against its own current first-party material. “Best” is used only when the criteria and audience are explicit.

Freshness

A review date means the cited pages were checked on that date; it is not a promise that the product cannot change the next day. Fees, geographic restrictions, supported assets, bridge minimums, API limits, rewards, and beta features should always be confirmed on the live first-party page before action.