How to check a protocol before you trust it
Most of what a protocol says about itself can be checked in an evening, by someone who does not write code. Here is the order that saves the most time.
Start with what cannot be edited
A website is a claim. A whitepaper is a claim. The deployed contract is the only artefact that has to be true, because it is what actually runs.
So the first check is whether the source you are reading is the source that is deployed. On a block explorer, verified source means the published code compiles to the bytecode at that address. If a protocol shows you code on one site and an unverified address on another, you have learned something before reading a line.
The second check is the address itself. Find it somewhere the project cannot quietly change — a signed message, a repository tag, a timestamped document — rather than only in a page that can be edited between visits.
Then look at who can change what
Every protocol has powers reserved to somebody. The question is never whether they exist but what they cover and how they are constrained.
Read for three things. What can an operator do without a vote, and does it take effect immediately or after a delay? What can a vote do that an operator cannot? And what can nobody do — is there a list of things the contract has no function for at all?
That last list is the useful one, and it is the one most projects do not publish. A protocol that can rewrite its own mint price, alter the rules for distributing backing, or defer returning funds has told you that your exit depends on someone’s restraint. Look for the absence of those functions, not for a promise not to use them.
Then the reserve and the oracles
Backed coins live or die on the reserve, so price it yourself. Get the addresses, read the balances on chain, and check what the assets actually are: an issuer-controlled stablecoin, a bridged wrapper, or the protocol’s own token wearing a different name. A reserve made of the protocol’s own issuance is not a reserve.
Then find the oracles. A contract that reads prices has to decide what to do when the feed is stale, when the answer is nonsense, and — on a rollup — when the sequencer has been down and every price is an hour old. Look for named feeds, an explicit staleness limit per asset, and a sequencer check. A protocol that reads a price and uses it is a protocol that will one day use a wrong one.
Then read the failure sections
Skip the introduction. Go to the parts of the documentation that describe what happens when things go badly: a currency depegging, an oracle stopping, a large holder exiting at once, a vote going the wrong way.
If those sections do not exist, that is the finding. If they exist and are vague, read them as marketing. If they name specific mechanisms and also name what those mechanisms do not cover, you are reading something written by people who have thought about being wrong.
Applied to this protocol, the honest short version is: the corridor’s lower edge is defended by several mechanisms at once, and every one of them is measured in units of the reserve. If the reserve holds volatile collateral, all of those levels move with the collateral’s own price. That is the sentence worth checking against our own pages, and worth demanding from anyone else.
Then the timestamps
Documents change. The way to know whether a document changed after you read it is a checksum plus a proof that the checksum existed on a given date.
Every document we publish has its checksum listed and an OpenTimestamps proof next to it, anchored in the bitcoin blockchain. The verification takes one command and does not require trusting us, which is the point. If a protocol asks you to trust a version history it controls, the history is worth what the control is worth.