How to Review a DeFi Document Before Citing It
A source-first checklist for publisher, date, network, version and stated limits.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
Citing a DeFi document is easy. Copying a link into an article and calling it a source is not the same as having checked that the document says what you claim it says. Most bad citations in this space fail at the same point: nobody established who wrote the text, when it was written, or which system it actually describes.
A document review is a short, repeatable procedure. You are checking provenance, scope and currency before you rely on a sentence long enough to change a reader’s decision.
Start with provenance, not with the content
Before you read a claim, establish who published it. A protocol’s own documentation, a governance forum post, and a third-party aggregator can describe the same mechanism in language that looks identical. They are not equally reliable.
Check the publishing entity against something you already trust. If the document is a support article, the domain should match the product it describes. If it is a specification, the repository should belong to the protocol team rather than to an account that merely quotes it.
A document hosted on a help centre subdomain is more likely to be maintained than the same text pasted into a forum reply. That does not make the forum reply wrong. It makes it a different kind of evidence, and you should label it as such.
Record the four metadata fields
Four fields decide whether a citation is usable:
- Publisher. The organisation or project that controls the text.
- Date. Publication date, and separately the last update date if the page shows one.
- Network. Which chain, layer or environment the text refers to.
- Version. Any version marker, deployment name or release tag the page carries.
These four fields cost a few seconds each and they prevent the most common citation error: describing a rule from an old version as though it were current. Many protocol parameters change without the page address changing, because documentation usually lives at a stable address.
Write these fields into your notes at the moment you read the page. Reconstructing them a month later means guessing.
Separate what the document says from what you infer
A document states what a system does under specified conditions. Your inference is what you conclude the document means for a reader’s situation.
Keep them apart in your notes, and keep them apart in your prose. A sentence that says the documentation states that withdrawal limits are set per market is checkable. A sentence that says users should expect limits to change is your interpretation, and it needs to be written as one.
If you cannot find a sentence in the source that supports the claim you want to make, you do not have a citation. You have a belief. That is worth writing down, but it belongs in a different section.
Check whether the limits are stated
Well-written operational documentation declares its own scope. It says which network it covers, which client version it describes, and what it deliberately leaves out.
When a page has no stated limits, that absence is itself information. It usually means the text is general guidance rather than a specification you can test a transaction against.
Treat pages with unstated limits as background reading. Do not build a safety recommendation on them.
Practical review sequence
Work through this in order and stop at the first failure:
- Confirm the domain matches the product or protocol you are describing.
- Record publisher, publication date and last update date.
- Record the network and version the text covers.
- Find the sentence that supports your specific claim.
- Note anything the page explicitly excludes from its scope.
- Save a copy or a screenshot so the citation survives a later edit.
If step 4 fails, stop. Either find a different source or drop the claim.
Common failure modes
- Citing a search snippet. The result text is not the page. Open the page.
- Citing an aggregator with no attribution. If it does not link to a primary source, it is a rumour with formatting.
- Ignoring the update date. A page updated after the behaviour changed is describing the new behaviour; a page untouched for two years may describe a system that no longer exists.
- Dropping the network qualifier. A parameter on one chain says nothing about another.
- Quoting promotional material as documentation. A token launch post and a technical specification are different genres.
Keep the review reproducible
The point of a documented procedure is that someone else, including you in six months, can repeat it and reach the same conclusion.
Store the metadata fields next to the citation, not in your head. When the document is later found to have been wrong or to describe a deprecated version, the people affected are the ones who can identify exactly which claim came from which page.
That is the whole value of reviewing a document before citing it: the review is cheap, and the cost of skipping it lands on your readers.