How to Maintain a Change Log for a DeFi Help Page
What to record when instructions, links, screenshots or warnings are revised.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A change log for a DeFi help page is the record of what you altered, when you altered it and why. It matters more here than in most documentation because the thing being documented keeps moving under you: interfaces get relabelled, fee structures change, support articles get rewritten by vendors, and a wallet flow that worked last quarter now sends funds to a different address shape. Without a written history, an old screenshot becomes indistinguishable from a current fact.
What a Help Page Change Log Is For
The purpose is not documentation for its own sake. It is answering three questions later that you cannot answer from the page itself.
- What did this page say three months ago, and is the current version still the same instruction?
- Which parts of this page have never been re-verified?
- When a user reports that a step failed, which version of the step were they actually looking at?
None of those can be recovered from the live page. All three become answerable if the log exists.
The Nine Fields Worth Recording
Keep the entry structure fixed. A log with varying fields cannot be searched later.
- Date and time of the edit, in full, with the timezone.
- Page URL, exactly as a reader would reach it.
- Section changed, named the way the page names it.
- What the old text said, quoted rather than summarised.
- What the new text says, quoted.
- Reason for the change, such as vendor change, correction, new feature or re-verification.
- Source used to verify it, with the URL and the date that source was read.
- Who verified it, if verification is split between editors.
- What was not checked, which is usually the most valuable field in the entry.
That last field is what separates a change log from a list of edits. An entry that records only what was fixed leaves the impression that everything else was confirmed.
Recording a Correction Honestly
Corrections are where a change log earns its credibility, so they deserve their own structure.
When a page was wrong, record what the error was, how long it stood, and whether the wrong information could have caused a loss. If the incorrect instruction would have sent funds to a wrong address or invited a seed phrase entry, that fact belongs in the log in plain language, not softened.
Also record how the error reached you. A correction found by a user report means the page was published without the check that would have caught it, and that check needs adding rather than just noting.
When to Re-Verify Rather Than to Edit
Some pages should not be edited at all when upstream changes. They should be re-verified from scratch.
Help pages that name fees, eligibility rules, minimum amounts, supported networks or security steps fall into this category. If a fee changes upstream, the correct action is to open the current upstream page, confirm the new value, and then edit. Editing from memory is how a change log fills up with confident wrong numbers.
Set a re-verification interval per page type rather than per page. Pages describing volatile values need short intervals. Pages describing concepts such as what a seed phrase is do not need to be re-checked at all.
What Not to Log
Do not log copy-edits that change nothing a reader would act on. If the log records every grammar fix, the entries that matter become invisible.
Do not log removals without recording the reason. A page that was deleted looks identical to a page that was never written.
Do not backfill history you did not observe. If the page was written six months ago and never checked since, write one entry saying that, dated today, rather than reconstructing entries that would look like verification that never happened.
The Format Question
Keep it plain. A table with the nine fields above, one row per entry, stored in the same repository as the page, is enough. A version control system already stores the history of the file, and that history is a different artifact from a change log: it records what the text was, not what was verified, why it changed, or what was left unchecked.
Use both when both exist. Do not treat a commit log as a change log.
Reviewing the Log Periodically
Once a quarter, read the entries for pages you actively link to and check whether anything has gone stale.
The useful review is short: are there pages whose last re-verification is older than their interval, and are there pages where the what-was-not-checked field is filled in every single time? A page that always has unchecked parts needs a smaller scope or a different verification method, not another entry recording the same gap.
Close the loop by writing a review entry that names the pages checked and the result. A log with review entries tells a reader the log is alive.
What a Change Log Does Not Do
A change log records what changed and what was verified. It does not verify anything by itself, and it says nothing about whether the current version is correct.
It also does not replace reading the current page. The whole point is that the log tells you what to check, and someone still has to check it.
Sources and Limits
This article is educational and does not constitute financial, legal, tax or security advice. Vendor interfaces, fees and support documentation change without notice, so confirm the current state at the primary source before relying on any instruction recorded here.