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 – 148 consecutive daily readings through 19 August 2026, taken from its own API series rather than from the dashboard, which returns 403 to a script – while the pool component its adapter reads held 32,562.60 sUSD when queried directly at epoch 336,270 on that last day. 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, and the example this section has carried since August proved it twice. Leaf Node’s validator unregistered on 10 August 2026 and registered again six days later, at 11:41:48 UTC on 16 August (epoch 335,461), without announcing either move. Read live at epoch 337,518 (23 August 2026, 15:06 UTC), it is registered and sits 45th of the 100 validators in the active set with 25,720,462.22 XRD – 0.5502% of the 4.67 billion XRD securing the network – on a 1% fee, with a 100% fee queued for epoch 341,223. Throughout all of it leafnode.info answered 503, as it still does: the site said nothing when the validator quit and nothing when it came back.

This page is itself the cautionary half of that example. It described the validator as unregistered for seven days after it was not, because a status read once was written down as a standing fact. 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 – and each one is a reading with a date attached, which is why freshness is a sourcing policy rather than a tidiness one.

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. The tag is a pointer for whoever reads the page next, and it costs nothing to leave in place while the source is hunted.

Read on 19 August 2026, the tag appears on exactly one page – this one, in the examples above. No article carries it. That is not evidence that every claim on the wiki is sourced; it is evidence that the tag is not part of how this wiki is actually edited, and the section below explains why.

Maintenance banners

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

Banners in practice

The In use column is a count, not an estimate. One query over the pages table on 19 August 2026 found five editor-placed banners across 363 pages: the Stub notice on application layer and kernel layer, and the Written like an advertisement notice on three ecosystem pages. Four of the six variants have never been placed on anything, including the two that other policies here instruct editors to reach for.

Nor is that because there is nothing to flag. Forty of the wiki’s 361 articles hold under 1,500 characters of prose and twenty-five hold under 1,000 – and the two carrying a Stub notice are neither the shortest nor among the shortest ten.

The mechanism explains the count better than any judgement about editors does. Of 1,503 revisions written in the ninety days to 19 August 2026, 1,478 – 98.3% – came from the single account that runs the rotating maintenance sweep. A banner is a message addressed to the next editor, and here the next editor is that same pass coming round again, which fixes a thin or unsourced page in place rather than labelling it for a later visit that is also itself. The one notice that does appear at scale is the one no editor places: the May be outdated stamp, generated at render time from a page’s own dates by the freshness rule.

So the honest rule, in place of an instruction nobody follows: place a banner when the fix is beyond the current pass – when the source exists but finding it is a session’s work, when the subject needs an expansion the sweep cannot write from the material to hand, when a page reads as its subject’s own copy and rewriting it fairly needs someone who knows the project. Otherwise fix it now. A banner left in place of a repair that took two minutes is worse than no banner, because it tells a reader the wiki knows and did nothing.

Remove a banner when the problem it names has been fixed, and say so in the revision message – the history is public.

See also

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