How we write
The working method, from first read to changelog line.
A reader who cites an entry is trusting the method as much as the editor. This page describes the method in full so that trust can be checked.
1. Choosing what to write
An entry is written when a reader question has been asked twice in mail or when a network change makes an existing entry misleading. We do not write to a content calendar. The maintenance rota is sorted by read count and by the date of the last network upgrade that touched the subject, so the entries most likely to be read wrong are the ones re-checked first.
2. Reading the primary sources
Before drafting, the editor reads the relevant SIMD in full, the client release notes for the last two releases that touched the area, and the most recent validator call recording. Where the source is a proposal still under discussion, the entry is marked as describing a proposal, not a shipped behaviour. The footnote block lists every source read, including the ones the editor disagreed with.
3. Verifying against on-chain data
Every entry pairs its concept with a worked example that points at a real, checkable artefact: a transaction signature, an account address, a slot number, or a dated mainnet epoch. The editor opens the artefact in a block explorer, confirms it still says what the entry claims, and records the slot or date of the check in the footnote. If the artefact has changed state since the check, the entry says so.
4. Review
A draft is read by a second editor who did not write it. The reviewer's job is to find the sentence a tired reader would misread, and the source that does not say what the draft says it says. A draft is not shipped while the reviewer has an open objection. The reviewer is named in the changelog line for the version.
5. Versioning against upgrades
When a mainnet upgrade lands, every entry tagged with the affected client release is re-read within ten working days. The editor updates the body where the behaviour has changed, leaves the previous version in the entry's history, and adds a changelog line naming the upgrade, the date, and the reviewer. An entry that has not been re-read since the last upgrade carries a "pending re-check" line at the top until the work is done.
6. Corrections
A correction from a reader is logged in the changelog with the reader's name unless they ask to stay anonymous. A correction that changes the meaning of an entry rewrites the affected paragraph and adds a changelog line; a correction that fixes a typo only adds a changelog line. We do not silently edit entries. The history of an entry is part of the entry.
7. What we do not do
We do not publish an entry the same week an editor changed their own validator configuration for the subject of the entry. We do not accept payment for placement, ordering, or wording. We do not write entries about tokens an editor holds a position in. We do not summarise a source we have not read in full.
Last updated: 14 September 2026. Method owner: Dohyeon Ahn, founding editor.