T
Most protocol write-ups have the same defect: they describe a system as its authors wish it worked, and the reader has no way to separate what is implemented from what is documented from what is aspiration wearing the present tense.
You can do better than trusting the write-up, and it takes an afternoon rather than an audit budget. What follows is a procedure. It works on any protocol, and the interesting part is not the checks themselves. It is what the gaps between them tell you.
1. Read the documentation for mechanisms, not adjectives. Find the protocol’s own docs and write down every concrete mechanism it claims: thresholds, signer counts, token behaviours, routing rules. Ignore everything with no testable content, such as “battle-tested”, “industry-leading” or “secure by design”. You are building a list of statements that could, in principle, be false.
2. Check each mechanism against a primary source that is not the protocol. The docs are the claim. The chain, the governance portal, the audit firm’s own site, and the block explorer are the evidence. A mechanism documented but not evidenced is not a lie. It is an unverified claim, which is a different and more useful category.
3. Use a control. This is the step almost nobody does, and it is the one that separates a finding from a mistake. When a check comes back negative, ask: would this check have come back positive for a protocol where the thing is true? If you cannot answer that, you do not have a finding. You have an untested instrument.
4. Check governance where governance actually lives. Not the docs page describing governance, but the portal where proposals are recorded, with dates and outcomes. Documentation describes intent; the portal shows what happened.
5. Write down what you could not verify. Keep the unverified list. It is the most valuable artefact you will produce, and the rest of this piece is about why.
Take the audit claim, which almost every protocol makes and almost no reader checks.
POTS Money’s documentation states, at docs.pots.money/pots-core/security.md, that the protocol “has been audited by leading blockchain security firms” and that “all audit reports are publicly available”. That is step 1: a concrete, checkable claim.
Step 2 is to go to the auditor rather than the protocol. CertiK’s Skynet page for Pots Money shows “Audits: Not Available” and carries no report link anywhere on the page, checked programmatically on 4 September 2026. So the documentation’s second clause, the one about reports being publicly available, does not currently hold for that engagement.
Now step 3, the control, because a negative result is worthless until you have shown the check could have gone the other way. CertiK’s Skynet page for PancakeSwap shows a working “View PDF” link. Same site, same check, positive result. That single comparison rules out the explanations that would otherwise make the finding meaningless: it is not that Skynet never shows reports, and not that the page failed to load. Whatever is going on is specific to that one engagement.
Notice what the control also prevents. Without it, a single negative result invites a sweeping conclusion about the auditor’s practices generally, a claim you would have no basis for in either direction, made in the course of complaining about unfounded claims. The control keeps the finding narrow: this engagement, this page, this date. That narrowness is not timidity. It is the whole of what the evidence supports, and saying more would be the same failure in the opposite direction.
Documentation describing a governance process is a description of intent. The portal is the record.
For POTS, the docs state that treasury movements require 25-of-50 multisig approval, and that voting weight uses a non-transferable credential minted by staking. Both are documented in two independent places, which is as good as documentary evidence gets. But the portal, Snapshot in this case, is where you see whether governance is a live process or a page.
This is also where time-sensitive claims go stale. A count of closed proposals is true on the day it is written and wrong a fortnight later. If you are reading a protocol write-up with a number in it, check the number’s date before you check anything else. I have shipped that error myself and had to publish a correction for it.
Run all five steps, and you end up with three piles: mechanisms you verified, mechanisms you could not, and claims that turned out not to be supported by the source they cite.
The second pile is the one worth reading. Not because unverified means false, since most of it will be perfectly true, but because what a protocol has not written down tells you where its attention has been. A system with meticulous documentation of its token mechanics and near-silence on its withdrawal path has told you something about its priorities without meaning to. A protocol whose governance portal shows steady activity and whose docs describe governance in one paragraph has told you the opposite.
You cannot get that signal from reading the marketing, because marketing is uniformly confident. You get it from the shape of the silence.
It cannot tell you whether a protocol is a good investment; nothing here touches price or performance, and any procedure claiming to do that from documentation alone is selling something. It cannot detect a well-documented lie: if the docs, the chain, and the audit all agree and all are wrong, five checks will not save you. It cannot substitute for a security audit. And it is a snapshot, which is why every finding above carries a date.
What it does is cheap, repeatable, and better than the alternative, which is believing the write-up.
The procedure took an afternoon per protocol when I started and about an hour once the checks became routine. Run it on something you already own, where you think you know the answer. That is the version that teaches you something.
I publish educational material about the POTS ecosystem, and I am not on its team. Every factual claim above maps to a written claims register with a citable source attached, and the register is what refused several sentences I would otherwise have written. Findings verified 4 September 2026; the audit-page state in particular is a live condition that can change without notice. Not financial advice. I hold a financial interest in the ecosystem described here, which is why the procedure above is written to be run by you rather than taken on my word.
Sources: docs.pots.money/pots-core/security.md, skynet.certik.com/projects/pots-money, skynet.certik.com/projects/pancakeswap, docs.pots.money/building-pots/governance.md, and the Snapshot governance portal for ibs.eth.
Photo by Alex Shute on Unsplash
You can do better than trusting the write-up, and it takes an afternoon rather than an audit budget. What follows is a procedure. It works on any protocol, and the interesting part is not the checks themselves. It is what the gaps between them tell you.
The Procedure
1. Read the documentation for mechanisms, not adjectives. Find the protocol’s own docs and write down every concrete mechanism it claims: thresholds, signer counts, token behaviours, routing rules. Ignore everything with no testable content, such as “battle-tested”, “industry-leading” or “secure by design”. You are building a list of statements that could, in principle, be false.
2. Check each mechanism against a primary source that is not the protocol. The docs are the claim. The chain, the governance portal, the audit firm’s own site, and the block explorer are the evidence. A mechanism documented but not evidenced is not a lie. It is an unverified claim, which is a different and more useful category.
3. Use a control. This is the step almost nobody does, and it is the one that separates a finding from a mistake. When a check comes back negative, ask: would this check have come back positive for a protocol where the thing is true? If you cannot answer that, you do not have a finding. You have an untested instrument.
4. Check governance where governance actually lives. Not the docs page describing governance, but the portal where proposals are recorded, with dates and outcomes. Documentation describes intent; the portal shows what happened.
5. Write down what you could not verify. Keep the unverified list. It is the most valuable artefact you will produce, and the rest of this piece is about why.
What this looks like in practice
Take the audit claim, which almost every protocol makes and almost no reader checks.
POTS Money’s documentation states, at docs.pots.money/pots-core/security.md, that the protocol “has been audited by leading blockchain security firms” and that “all audit reports are publicly available”. That is step 1: a concrete, checkable claim.
Step 2 is to go to the auditor rather than the protocol. CertiK’s Skynet page for Pots Money shows “Audits: Not Available” and carries no report link anywhere on the page, checked programmatically on 4 September 2026. So the documentation’s second clause, the one about reports being publicly available, does not currently hold for that engagement.
Now step 3, the control, because a negative result is worthless until you have shown the check could have gone the other way. CertiK’s Skynet page for PancakeSwap shows a working “View PDF” link. Same site, same check, positive result. That single comparison rules out the explanations that would otherwise make the finding meaningless: it is not that Skynet never shows reports, and not that the page failed to load. Whatever is going on is specific to that one engagement.
Notice what the control also prevents. Without it, a single negative result invites a sweeping conclusion about the auditor’s practices generally, a claim you would have no basis for in either direction, made in the course of complaining about unfounded claims. The control keeps the finding narrow: this engagement, this page, this date. That narrowness is not timidity. It is the whole of what the evidence supports, and saying more would be the same failure in the opposite direction.
Governance is the easiest check and the least performed.
Documentation describing a governance process is a description of intent. The portal is the record.
For POTS, the docs state that treasury movements require 25-of-50 multisig approval, and that voting weight uses a non-transferable credential minted by staking. Both are documented in two independent places, which is as good as documentary evidence gets. But the portal, Snapshot in this case, is where you see whether governance is a live process or a page.
This is also where time-sensitive claims go stale. A count of closed proposals is true on the day it is written and wrong a fortnight later. If you are reading a protocol write-up with a number in it, check the number’s date before you check anything else. I have shipped that error myself and had to publish a correction for it.
The gap is the finding.
Run all five steps, and you end up with three piles: mechanisms you verified, mechanisms you could not, and claims that turned out not to be supported by the source they cite.
The second pile is the one worth reading. Not because unverified means false, since most of it will be perfectly true, but because what a protocol has not written down tells you where its attention has been. A system with meticulous documentation of its token mechanics and near-silence on its withdrawal path has told you something about its priorities without meaning to. A protocol whose governance portal shows steady activity and whose docs describe governance in one paragraph has told you the opposite.
You cannot get that signal from reading the marketing, because marketing is uniformly confident. You get it from the shape of the silence.
What this method cannot do.
It cannot tell you whether a protocol is a good investment; nothing here touches price or performance, and any procedure claiming to do that from documentation alone is selling something. It cannot detect a well-documented lie: if the docs, the chain, and the audit all agree and all are wrong, five checks will not save you. It cannot substitute for a security audit. And it is a snapshot, which is why every finding above carries a date.
What it does is cheap, repeatable, and better than the alternative, which is believing the write-up.
Try it on something you hold
The procedure took an afternoon per protocol when I started and about an hour once the checks became routine. Run it on something you already own, where you think you know the answer. That is the version that teaches you something.
I publish educational material about the POTS ecosystem, and I am not on its team. Every factual claim above maps to a written claims register with a citable source attached, and the register is what refused several sentences I would otherwise have written. Findings verified 4 September 2026; the audit-page state in particular is a live condition that can change without notice. Not financial advice. I hold a financial interest in the ecosystem described here, which is why the procedure above is written to be run by you rather than taken on my word.
Sources: docs.pots.money/pots-core/security.md, skynet.certik.com/projects/pots-money, skynet.certik.com/projects/pancakeswap, docs.pots.money/building-pots/governance.md, and the Snapshot governance portal for ibs.eth.
Photo by Alex Shute on Unsplash