How to Record Uncertainty in DeFi Research
A concise note format for incomplete data, changing interfaces, network conditions and open questions.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
Uncertainty is the part of a DeFi finding you cannot look up. You can look up the total value locked at a block, the gas used by a transaction, or the address that holds a position. What you cannot look up is how much of your reading depends on an assumption you made, and whether that assumption still holds tomorrow.
Recording uncertainty is not hedging. It is the difference between a note that can be checked by someone else and a note that can only be trusted by you. DeFi changes fast enough that a conclusion without its conditions attached becomes wrong without anyone noticing the moment it changed.
The four categories worth separating
Most uncertainty in DeFi research falls into four groups, and they behave differently, so mixing them loses information.
Incomplete data. The information exists and is retrievable, but you have not retrieved it. A dashboard that excludes one venue is incomplete, not uncertain, and the fix is to go get the missing piece.
Changing interfaces. A wallet update, a contract upgrade, or a router migration changes what a button does without changing the label on the button. Your observation was correct when made and describes different behaviour now.
Network conditions. Fees, congestion, and pool depth move continuously. A transaction that cost little is not evidence that transactions are cheap.
Open questions. You do not know, and you know that you do not know. This is the only category that no amount of further reading resolves, and it is the one most often left unrecorded because it feels unfinished.
A note format that survives contact with time
The format matters less than one rule: each claim carries its own condition. Writing conditions once at the bottom of a note is what makes notes rot, because the reader cannot tell which sentences the condition governs.
Use four fields per finding.
The claim. One sentence, stated flatly, with no adjectives of confidence inside it.
The condition. What has to be true for the claim to hold. Write it as something checkable: at what block height, on which version, under what fee level, as of what date.
The evidence. Where it came from, at a level specific enough that someone else could find the same thing. A transaction hash, a contract address, a URL with the section named, a governance proposal number.
The confidence, and its reason. High, medium, or low, plus the reason in words. Low because the only source is one dashboard, or medium because the coverage excludes a venue.
Why the reason matters more than the level
A confidence level without a reason is not usable. Low confidence because the data is genuinely contested and low confidence because you were in a hurry are different problems, and they lead to different next actions.
The first calls for more sources. The second calls for a re-read. Writing the reason forces you to tell them apart while you still remember which one it was.
There is a useful discipline here: if your reason is that you have not looked yet, mark it as incomplete rather than low. Incomplete data has a remedy, and low confidence often does not.
What interfaces change without warning
Interface changes are the most dangerous category because the label stays the same while the behaviour does not.
A token approval is the clearest example. When you interact with a smart contract, spending permissions can be granted, and unlimited allowances are the norm rather than the exception. If you recorded only that you approved a protocol, you have not recorded the allowance, and an allowance is not the same thing as a protocol name.
Similarly, a signature request can mean several things. A message signature may be off-chain and cost no gas, while a permit can grant spending rights with a signature rather than an approval transaction. Both look like a confirmation dialog. One can move assets later.
Record the approval amount, the token, the spender contract, and whether the interaction was a swap, a permit, or a plain connection. A wallet update can also change what a confirmation screen shows, so a note that says the interface presented a plain send is a statement about a version.
Turning uncertainty into a task list
A note is finished when it names what would resolve each open item. This is the part that makes research compounds instead of restarting.
For incomplete data, the task is retrieval, and it is specific: pull the volume from the second venue. For changing interfaces, the task is re-checking a named behaviour on a named version. For network conditions, the task is recording the fee level or block number alongside the observation so it can be compared later. For open questions, the task is often finding who would know, which usually means a governance forum, a developer channel, or a published audit.
Audits fit here. An audit is a finding at a point in time about specific code. It narrows an open question; it does not close it, and treating it as a guarantee is a category error.
A closing habit
Before you file a note, read only the conditions. Ignore the claims. If a claim cannot be reconstructed from the conditions, the claim was too vague to keep.
Then add one line: what would change this answer. That single line is what tells the next reader, including you in three months, whether the note is still live.
The short version
Attach the condition to the claim, not to the summary. Separate incomplete data from open questions, because only one of them has a remedy. Name the version when the interface could have changed, and name the fee level when the network could have changed.
Uncertainty that is written down is a task. Uncertainty that is remembered is a source of quiet errors six months later.