About this publication
Methodology
Articles are written from protocol documentation, papers, source files, and governance posts. A last-verified date means those sources were read for that page. It does not mean an audit. Figures quoted from a governance update stay attributed to that update.
Protocol Anatomy explains how a few widely used protocols account for assets. The pages are for engineers who can read a contract and want the mechanism, the version boundary, and the source. They are not price commentary, and they are not a substitute for the protocol’s own docs when you are about to send a transaction.
What gets cited
Sources are preferred in this order:
- The protocol’s own technical documentation.
- A whitepaper or formal note published by the protocol.
- Source code in the protocol’s repository, at a file, tag, or commit named on the page.
- Governance proposals and official development updates.
- Security write-ups and incident reports from the protocol, when a page is actually about an incident.
- A standard such as an ERC or an Ethereum consensus document, when the protocol depends on it.
A company blog can establish a date the organization announced, which is how the Uniswap v4 launch post and the Lido Dual Governance overview are used. A blog sentence about safety or market leadership is not treated as evidence of those qualities. Marketing pages that describe collateral mixes or “trustless” architecture are not used as proof of either.
Secondary explainers are not in the source lists for the protocol pages. If a fact is only in a secondary source, it is not stated.
Version status
Each protocol and version guide carries a version list with a controlled status:
| Status | Meaning on this site |
|---|---|
| active | A production design the cited docs still describe as something users or integrators can be on |
| released | Shipped, used when the important fact is that it left development |
| historical | An earlier design, kept so the newer one has a predecessor |
| deprecated | A mechanism the protocol’s own current interface marks as deprecated |
| proposed | Discussed or voted, not established here as deployed |
| in-development | Being built, not established here as activated |
A version is not added because a number would make a tidy sequence. Aave V4 is listed because the protocol’s overview and the 2026 governance updates describe an activated deployment. Uniswap v4 is listed because the project’s launch post and current docs describe it. No page invents a V5.
“Active” does not mean “the only deployment.” Aave V3 and V4 are both active on the evidence used here. Old Curve pools stay on their original bytecode after a new factory implementation exists.
Code examples
A fenced Solidity block is one of three things, and the paragraph around it says which.
- A short excerpt from a named file, tag, or commit. The excerpt is small. The license of that repository still applies to the original. This site does not relicense it.
- An educational sketch, marked as one, with a compiler pragma. It has not been compiled or deployed as part of publishing this site unless a page says that a command was run. None of the sketches are meant to hold assets.
- A formula in a text block, copied from a cited derivation rather than typeset as if the contracts computed real numbers.
If the excerpt and the docs disagree, the page says so. Master branches move. A citation of master is tied to the last-verified date, not to a promise that the file is frozen.
What last verified means
lastVerified is the date the sources listed on that page were read for the claims on that page. For the first edition, that date is 13 October 2026. It is not an audit date, not a bug-bounty date, and not a claim that every parameter was read from chain that day.
Numbers that move are handled in one of two ways. They are omitted, which is the default for loan-to-value, caps, and TVL. Or they are attributed, which is how the September 2026 Aave Labs update is quoted: as that post’s report, not as a live balance this site refreshes.
Corrections
Protocols change. A page can be wrong because a governance payload landed, because a doc URL started redirecting at a marketing page, or because an excerpt was trimmed badly. The correction path is an issue or a change on the project repository naming the page, the sentence, and the source that contradicts it. A corrected page should move lastVerified only after the new source has been read, and should keep the distinction between historical behavior and current behavior in the prose.
Automated checks in the repository catch broken internal links, missing metadata, unknown version statuses, and unfinished-article markers. They do not catch a false sentence that is grammatically fine and cites a real URL. The URL being real is not the same as the sentence being supported. That judgment stays with the person editing the page. The contributor notes in the README are the checklist for the next article.
Sources
- Aave V4 overview Documentation · Aave
- How Uniswap works Documentation · Uniswap
- Vat detailed documentation Documentation · MakerDAO
- Understanding StableSwap Documentation · Curve
- Lido tokens integration guide Documentation · Lido