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. A chat message is the ordinary case on this wiki rather than the exception, and citing one has a procedure of its own.

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. Five 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 340,083 (12 September 2026, 03:08 UTC, the morning after mainnet restarted), it is registered and sits 41st of the 100 validators in the active set with 25,573,394.53 XRD – 0.5616% of the 4.55 billion XRD securing the network – on a 1% fee, with the 100% fee still queued for epoch 341,223. It has climbed four places since 23 August while holding 147,067 XRD less, because the active set’s total stake fell further than its own did: a rank is a fact about everyone else. Throughout all of it leafnode.info answered 503, as it did again on the re-read: the site said nothing when the validator quit, nothing when it came back, and nothing across a twelve-day network halt.

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.

An on-ledger reading is not a true one

The ledger is a primary source, but for the right claim. Reading a component’s state tells you what that component holds, not what is the case in the world, and where the two are confused the ledger will state a falsehood with perfect precision. On 30 August 2026 Weft Finance’s price cache recorded HUG at 1,330.41 XRD per token. That reading is genuine, current and citable, and it is wrong by about ten million times: HUG traded at 0.000131 XRD the same day. One transaction turned the gap into 71 million XRD of debt drawn against collateral bought for 70.6 XRD.

The correction is not to distrust the ledger but to name what a reading is a source for. A resource’s supply, a vault balance, an NFT’s data, is_registered on a validator: these are facts about the ledger, and the ledger settles them outright. A price, a valuation, a website, a social handle, a status label: these are claims the ledger merely stores on someone’s behalf, and a second, independent source settles them. Cite the first as fact. Cite the second as what a named component published, with the time it published it.

A release is not its contents

A version tag, a “latest release” badge and a downloadable artifact are metadata about a build, not evidence of what is in it, and during an incident the difference is the whole story. On 8 September 2026, babylon-node published v1.3.0.5-test.1, its first release since June and the first tag in the repository’s history to use -test rather than -rcN; not being flagged a pre-release, it became what GitHub returns as the latest. The commit behind the tag is the merge of a CI and Dockerfile change, and that merge’s first parent is the commit tagged v1.3.0.5 – the version mainnet was running when it halted. The fix was on a different branch, which GitHub compares as diverged from the tag. Resolve the tag to its commit, read the commit’s parents and its diff, and check which branch it sits on. A release page answers when something was built and by what; it does not answer what was built.

A status endpoint is not the ledger

Two Gateway endpoints answer what looks like the same question and do not. /status/gateway-status reports the tip the Gateway aggregator has ingested; /stream/transactions reports what the ledger committed. While both numbers are moving the difference is invisible, and while neither is moving it is a published falsehood. Through the twelve days mainnet was down this wiki gave the last round before the halt as state version 557,840,622, epoch 339,896, round 102, at 21:19:06.179 UTC on 31 August 2026, in some forty consecutive readings across two articles. The ledger had run on. Read from /stream/transactions at state version 557,840,615 ascending, three further user transactions commit in epoch 339,897 round 1 and a round update closes the ledger at state version 557,840,627, epoch 339,897, round 4, timestamped 2026-08-31T21:19:48.939Z – five state versions and forty-three seconds past the figure that was published. The next commit is state version 557,840,628 at 11:35:28.960 UTC on 11 September 2026, and the first user transaction after the restart lands at 11:39:25.129 UTC. The general form: a status endpoint answers what have I seen, and a boundary question needs what is there.

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.

Citing a chat message

Much of what this wiki learns first is said in a Telegram channel, and its citations show it. Read on 12 September 2026, 504 links across 73 of the wiki’s 376 pages point at one individual Telegram message – 180 into the hyperscale-rs channel, 131 into Radix DLT Official, 85 into the Accountability Council’s. They gather where no other record exists: 126 on hyperscale-rs, and 64 across the two articles covering the Hyperlane asset drain – the most-read page on the site and the day-by-day timeline split out of it on 11 September. The section above calls an unattributed forum post a weak source, and a chat message arrives unattributed by default. What follows is the step that changes that.

The message arrives without its author

A public channel read through Telegram’s API returns four things per message: the channel, a numeric id, a timestamp, and the text. It does not return who wrote it. A quotation taken from that read alone carries a checkable date and a speaker the editor supplied, which is the shape no original research rules out – the reading is real and the attribution is an inference.

The embed settles the author

Every message in a public channel also has a public embed, and the embed names who posted it. Requesting https://t.me/<channel>/<id>?embed=1&mode=tme returns that single message rendered with the display name and handle of its author, above the channel title. Two read while this section was written: the Accountability Council’s status update at 11:02 UTC on 4 September 2026 resolves to projectShift, and the message this wiki cites for Astrolescent’s funding resolves to Timan | Astrolescent, handle @djtrebel. Cite the plain message URL in the article, and read the embed before you do.

One failure here is silent. Where the cited message is a reply, the embed renders two messages – the one requested first, then the one it answers – and each carries its own author block. t.me/radix_dlt/1001809 renders as Timan | Astrolescent answering Jon-Eric Cook, so taking the name from the second block credits the quotation to the person being answered, and the finished citation looks correct either way. Take the first author block, and check whether the reply marker points at a message id other than the one requested.

What an embed establishes, and what it does not

An embed establishes that a handle posted this text in this channel at this time. It does not establish that the display name belongs to the person it names, and it says nothing about whether the text is true. A chat message is a source for what someone said, dated and attributed, and it enters an article as attribution rather than in the wiki’s own voice, per neutral point of view. Where the speaker is describing their own work, their own project, or their own withdrawal from one, that is the claim they are a strong source for.

A figure that enters a conversation from the person asking is not sourced by the answer. Asked in September 2026 whether he was giving up funding “past the $50k or whatever it was already paid out”, the author of hyperscale-rs took the number up sarcastically, and neither he nor the Foundation has published an amount or a payment date. That page quotes both messages and records the exchange; it does not record $50,000 as a sum paid. The general form is narrow: a number is sourced by whoever can be shown to have asserted it, and a question is not an assertion.

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 appeared on exactly one page – this one, in the examples above. Read again on 12 September, after 888 further revisions, that is still the count. 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 12 September 2026 found five editor-placed banners across 376 pages, the same five the query returned on 19 August: 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.

When this section was written there was plenty to flag: forty of the wiki’s 361 articles held under 1,500 characters of prose, twenty-five held under 1,000, and the two carrying a Stub notice were neither the shortest nor among the shortest ten. Re-measured on 12 September, the thin tail has more than halved – 18 of 367 articles under 1,500 characters and 11 under 1,000 – and the two Stub pages are now the shortest on the wiki at 735 characters and the third-shortest at 769. The notices did not move. Everything around them was filled in until they were accurate.

The mechanism explains the count better than any judgement about editors does. Of 2,338 revisions written in the ninety days to 12 September 2026, 2,317 – 99.1% – 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