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

How to Build a Source Hierarchy for a DeFi Safety Guide

A repeatable structure for separating protocol documentation, explorers, support pages and commentary.

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 source hierarchy answers one question: when two sources disagree, which one wins? It has to be written down before you need it, because the situations where it matters are exactly the situations where you are least able to think clearly about it.

Rank by what the source can actually know

On-chain state and executed transactions. These are the ground truth about what happened. A transaction receipt cannot be edited and does not depend on anyone’s claims. When a dashboard disagrees with a receipt, the receipt is right.

Deployed contract code and verified source. Authoritative about protocol behaviour, provided the verification matches the deployed bytecode. Check that it matches; verified source on a different address tells you nothing about the address you are using.

Official project documentation and governance records. Authoritative about intent and about the rules a project claims to follow. Not authoritative about current behaviour, because a project can fail to do what its own documentation says.

Audits. Authoritative about what was examined and when. Not authoritative about what happens after the audit date, and not authoritative about code the auditor did not read. Check the scope, not just the presence of a PDF.

Reputable reporting. Useful for context, timelines, and quotes. Frequently the first source to describe an incident accurately, and frequently wrong about technical detail in ways that matter.

Social posts, including the project’s own. Useful for detecting that something has happened. Nearly worthless as a statement of fact, including when the account posting is the project itself.

The rules that make the hierarchy work

Earlier beats later only within the same rank. A tweet from six hours ago does not outrank an on-chain reading from a day ago. Rank first, recency second.

Two sources from the same domain are one source. Three outlets syndicating one press release is not corroboration. This is the single most common way a “confirmed” story turns out to be one company’s press release.

Absence of a source is information, but weak information. A token launch with no audit and no verifiable source is worth noting; it is not proof of anything.

Making the hierarchy operational

Write the ranking down as an ordered list with your own project’s sources filled in, and then apply it mechanically. If you find yourself arguing about which source to trust after reading two of them, the hierarchy was not specific enough — add the tiebreaker rule you needed. A hierarchy that requires judgement is not a hierarchy, it is a preference.

Sources