Verifiability

Verifiability is the first standard on RADIX Wiki: the threshold for including material is whether readers can check that it comes from a reliable, published source – not whether an editor is personally convinced it is true.^[1] Any statement likely to be challenged, and every quotation, should carry an inline citation to a source.

Reliable sources

Prefer primary Radix documentation, the project's own repositories, peer-reviewed papers, and the on-chain record. The Radix ledger is itself a primary source: an asset supply, a component's state, or a transaction can be cited directly via the Gateway API or a ledger explorer.^[2] Marketing copy and unattributed forum posts are weak sources and should be replaced.

Checking a Radix claim

Most of what this wiki asserts is about a running system, so the check is usually mechanical: read the thing itself rather than an account of it. Three failure modes recur often enough to be worth naming, and each has a worked example on the wiki.

A dashboard is not the ledger

Aggregators break quietly and keep serving a number. DeFiLlama has reported zero TVL for Surge every day since 25 March 2026, while the pool component its own adapter reads held 33,245.53 sUSD when queried directly on 11 August 2026. Cite the component state; treat the dashboard as the claim to be checked, not the source that settles it.

Official documentation can be wrong

Radix Docs gives the Cuttlefish mainnet enactment as “Epoch: 105353”. That is Bottlenose’s epoch; Cuttlefish enacted at epoch 160923. One Gateway request settles which is right, and where the ledger and a documentation page disagree, the ledger is the source and the disagreement is worth stating.

A project’s website is not its status

Whether a homepage loads says nothing about what a project is doing on-ledger. Leaf Node’s site returns a paused deployment, while the validator itself reads unregistered since 10 August 2026 with 33.9 million XRD still delegated to it and 99.67% uptime over the trailing week. Status fields on ecosystem pages are taken from is_registered, a component’s state, or a resource’s supply – never from whether a site responds.

A failed fetch is not a dead source

Automated link checking produces false positives in bulk: Medium, LinkedIn, SSRN, CoinGecko and Cloudflare-fronted sites routinely return 403, 429 or 999 to a script while serving the page normally to a reader. Confirm with an ordinary browser request before removing a citation. A sound source deleted on a false positive is harder to recover than a dead link left in place for one more pass.

Where a claim cannot be checked against the ledger or a filed document – an off-ledger treasury balance, an unannounced roadmap, a private agreement – write what is known, attribute it to whoever said it, and state plainly what is not established. An honest gap is preferable to an inference presented as a fact.

Citations needed

When a claim lacks a source, mark it with a [citation needed] tag rather than deleting it outright, and add a Needs citations notice banner to the top of the article so contributors and the maintenance sweep can find it.

Maintenance banners

Rather than delete imperfect material, mark it. RADIX Wiki carries six top-of-article notice banners; any editor can add one to a page, and each renders a fixed label and message that a custom note can override.

A banner is a request for help, addressed to the next editor. Remove it when the problem it names has been fixed.

See also

• Neutral point of view
• No original research
• Notability
• Freshness
• Conflict of interest