Freshness is RADIX Wiki's crypto-native extension of verifiability. Facts about a fast-moving ecosystem decay quickly, so a claim that was sourced correctly a year ago may now be wrong.[1] Factual pages should record when they were last checked and be re-verified against the live ledger.
How verification is recorded
Every page has a Last Verified field, set when its facts are re-checked against sources and the live ledger. The stamp is separate from the last edit: fixing a typo does not re-verify a page, and confirming that a page is still correct does not require changing a word of it. Where a page has never been verified the field is empty, and nothing is shown beside the version and revision count.
The stamp is written by the rotating maintenance sweep, which runs scripts/mark-verified.mjs against the database.[3] The article editor has no control for it, so an editor who re-checks a page cannot record that they did – the sweep is the only thing that can. Read at 23:04 UTC on 5 October 2026, 332 of the wiki’s 379 pages carry a verification stamp and 47 have never been verified, against 313 of 379 on 24 September, 310 of 378 on 20 September, 308 of 377 on 16 and 18 September and 293 of 373 on 10 September. Every stamp was written by the sweep, because nothing else can write one.
A page whose last verification – or, if it has never been verified, its last edit – is more than 180 days old is treated as stale and shown a May be outdated notice. That notice is generated at render time from the page’s own dates and is never stored on the page, so it cannot be dismissed by editing: it clears when, and only when, the page is verified again. The 180-day threshold and the notice it raises both live in wiki-formant, a package this wiki shares with its sibling sites, having moved out of this site’s own repository on 18 September 2026; the move broke the source link this page carried, and the link audit of 20 September found it.[4] Age is counted in whole days and a page is stale only when it is more than 180 of them old, so the notice first appears on the 181st day. At that reading no page met the threshold. The oldest reading on the wiki is XRD Domains, never verified and last edited at 15:56 UTC on 28 March 2026, 180 whole days old at that reading, and it began showing the notice at 15:56 UTC on 25 September 2026: a load of the page that bypassed the cache rendered it at 19:05 UTC that day, the first May be outdated notice this wiki has displayed. It is also one of the two pages the wiki locks against script edits, so the sweep that clears this notice everywhere else cannot edit that page to correct whatever a re-check found, and a stamp written to it would assert a verification the sweep is not in a position to act on. So the first notice sits on a page the process cannot currently clear. On 5 October it was 191 days old and a cache-busted load still rendered the notice.
So will the second. The next-oldest reading is Radix Namespace, also never verified, last edited on 29 June 2026, 98 days old on 5 October, and showing the notice from 27 December 2026 – and it is the other locked page. Behind those two the queue drops away. On 24 September the third-oldest reading was 53 days, shared by four pages the sweep had verified on 2 August 2026, Cerberus vs Other BFT Protocols, Consensus Evolution at Radix, Sharding and Rollups. All four were verified again before 5 October, which is the rotation working as intended, and third place passed to Access Controller, 59 days old, verified on 7 August 2026; unless it is verified again first, it shows the notice from 4 February 2027. Both of the pages that will show the notice are pages the sweep cannot edit, and no page it can edit is within four months of showing one. That render-time notice is also the only maintenance banner on this wiki that ever appears in quantity: the six an editor can place by hand sit on five pages in total, counted and explained under verifiability.
Where a page states an on-chain value, re-check it against a ledger explorer or the Gateway API[2] – the ledger is the authority, and published documentation about it can itself be out of date. The rotating audit that does this across the wiki records each pass in the wiki maintenance log.
When a claim decays faster than the stamp
The 180-day threshold is built for a page that goes quietly out of date, and it cannot see a claim that goes wrong in the week it is written. An instruction to node operators is the clearest case. On 9 September 2026 the Radix Accountability Council asked operators not to install the release candidate that carries the fix for the August 2026 network halt, and to wait for official versions and instructions; three pages here recorded that, with the source. At 16:15 UTC on 10 September the council told the same operators to upgrade now. Every page carrying the earlier instruction was wrong from that minute, and the verification stamps on them, written that morning, still read fresh.
Two habits cover the gap, and both are already the house style here. Date the claim inside the sentence, so the sentence carries what the stamp cannot: read at 07:06 UTC on 10 September
tells a reader on the 11th exactly what they are looking at, and a reader can act on a dated instruction that a bare present tense would have hidden. Then revisit a page on the cadence of the thing it reports rather than the cadence of the rotation. A halt that is still running takes a reading a day; a protocol page whose subject last changed in 2023 does not.
