Independent DeFi security desk · Status: operationalMethodology & corrections · Submit an incident
DeFi Safety · Fact checked

How to Prepare a DeFi Guide for Correction

A lightweight workflow for recording source changes, disputed details and update history.

This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.

DeFi Safety — illustration keyed to this article's identifier. Source documents are listed under Sources and are not reproduced here.

A guide that cannot be corrected reliably will be abandoned by its readers the first time it is wrong, so correction handling belongs in the publishing process rather than in a separate workflow.

Write corrections as dated records

The basic unit is a correction entry. Each one records the date, the specific claim that was wrong, what the claim said, what it should have said, and the source that establishes the correct version.

Keeping corrections in the guide rather than only in an internal log matters because readers who notice the error cannot tell whether the page has already been fixed. A visible correction list is the signal that the page is maintained.

Group corrections under a heading near the top of the page rather than at the bottom. Readers who arrive from a search result scan the first screen; a correction list placed at the end of a long article is frequently never seen.

Separate corrections from updates

These are different events and merging them obscures both.

A correction means a statement was wrong and readers could have been misled by it. An update means the underlying information moved forward and the statement was accurate when written.

A parameter that changed after publication is an update. A fee figure that was stated incorrectly is a correction. Marking an update as a correction undermines trust in the rest of the page, because it implies previous errors that did not exist.

Record the source that settles the dispute

Most disputed claims are settled by a document, not by argument. Record which document settles it and where that document lives.

A claim about a contract’s fee is settled by the contract source at a specific block. A claim about a listing is settled by the official announcement. A claim about a security practice is settled by the relevant documentation.

Note the retrieval date alongside the source. Documentation pages are revised in place, and a claim verified against a page today may not match the same page next year.

Describe the impact on the reader

Each correction entry should say who was affected and how.

If the correction changes a recommended procedure, say that readers who followed the earlier version should stop and re-check. If it corrects a figure that was used for comparison, say that any conclusion drawn from that figure should be revisited. If it fixes wording that misled nobody, say so plainly.

This prevents an unranked pile of corrections and lets a reader work out in seconds whether the error touches their own situation.

Do not silently overwrite the wrong text

Replacing incorrect text with corrected text looks cleaner and destroys the audit trail.

The reader who already acted on the original version has no way to learn that anything changed. A brief note stating what changed and when costs a few lines and protects those readers from acting on a version you already know to be wrong.

The exception is a typo in a sentence that carried no factual claim; those need no record.

Route unresolved disputes instead of publishing them

Some disagreements cannot be settled by a single document, because two sources conflict or the question turns on interpretation.

Route these to a visible “unverified” state. State the competing claims, name each source, and say plainly which claim the page currently presents and why. A reader can act on a stated position; a reader cannot act on a page that pretends the question is settled.

Schedule the follow-up check

A correction entry that records only the past leaves the same error free to return.

Set a date when the correction was made and revisit the claim on that date. Some corrections age quickly, because the thing that was misstated has itself changed since. Record the result of the check in the entry, including the case where the page needed no further change.

Treat this as maintenance, not as damage control

A page with a clean correction history is a page that was worth reading. Most published material eventually contains something outdated, and the only real choice is whether the correction is visible to the people who rely on the page.

Building the correction entry into the authoring process costs a few minutes per change and removes the incentive to avoid updating a page that has become difficult to revise.

Sources