Describe what goes in, what you hold afterward, where income comes from and how the position becomes spendable assets again. Trace the actual program and control relationships, then verify those mechanics through one complete operation and its records.

Write the position in plain language

Start with a concrete sentence. For a teaching lending vault: you deposit 500 USDC, receive a program-defined share of a managed pool and later request underlying assets under its withdrawal rules.

That sentence identifies the input, the holding and the exit. It is more useful than a product label such as earn because it tells you what must be inspected.

Now identify the exact mints, vault and program addresses from the product's official documentation and constructed transaction. A familiar token logo does not establish the asset or the program accepting it.

Choose the description appropriate to the product. An LP position holds a changing asset mix; a collateralised loan adds debt; an LST represents pool backing. Their records and income sources require different explanations.

Follow who pays the income

For the teaching vault, follow allocations into lending reserves. Borrowers pay interest, and the vault's share of reserve positions contributes to its assets. Product charges reduce the amount reflected in the user's claim under its accounting.

A curator can change allocation within the permitted mandate. Read the actual supported reserves, caps and controls. Kamino's lending-vault risk documentation, for example, explicitly treats allocation decisions and underlying reserve risks as material to depositors.

Additional reward-token emissions are another source. Record their identity, availability and valuation instead of merging them into a single unexplained rate.

For a trading-fee product, trace trades and fee allocation instead. For native staking, use its reward mechanism. The question who pays and for what work should have a specific answer for the product being reviewed.

Map the programs and administrative actions

Identify the program that holds or manages the position, the token programs used and relevant external data. Then map actions such as code upgrade, allocation change, parameter update and asset restriction to their actual authorities.

A multisig claim should be supported by its current configuration and execution path. A removed upgrade authority answers a code question, while mutable configuration and token-issuer controls can remain relevant.

For a lending product, the price path affects collateral calculations. For an LP, the pool's actual pricing and fee rules matter. Attach dependencies to the mechanism they influence instead of collecting unrelated security badges.

The governance guide shows how to turn this into an action-specific authority table.

Record the actual dependencies

Record the actual dependencies. Asset and claim: Exact mint and what the receipt represents. Control: Program, upgrades and management powers. Valuation: Price source, units and observation time. Exit: Redemption, liquidity and market alternatives.
A position passport should describe the specific product rather than generic promises.

Explain the ways the position can change value

For the vault example, distinguish underlying interest, product charges, market value of the deposited asset and potential reserve losses. A positive historical fee or rate figure does not explain every one of those components.

For a loan, write the debt asset and liquidation mechanism. For liquidity provision, write the asset mix and comparison benchmark. For an incentive programme, write the emission and reward-token exposure.

Read how an exceptional loss is allocated. An audit describes reviewed code and scope at a point in time; it should link to the actual reports and deployment context rather than becoming an all-purpose economic guarantee.

A useful review names the causal path: which event changes which holding or claim, under which rules. That gives a reader something they can observe and test.

Complete the route back to spendable assets

For the teaching 500 USDC deposit, identify how shares are redeemed, what liquidity the vault needs and whether a separate claim is required. Determine where the resulting USDC arrives.

If a product offers an alternative sale, compare its actual quote and supported market. If repayment is required first, include the debt asset and any conversion. A portfolio value is not a complete exit specification.

Account for network fees, setup costs, product charges and market execution under the same units. Read whether the interface's reported net figure already deducts a component.

The withdrawal guide separates reserve availability, queues and trading routes. Use it to fill the exit part of the product review.

Finish with a filled specification and an observed result

A useful lending-vault specification can state: input is the verified USDC mint; output holding is this vault share; income comes from these lending allocations; curator controls follow these roles; fees follow this method; withdrawal depends on these reserves and instructions.

For a walkthrough, record the actual entry transaction and resulting position. Then inspect an income observation or accounting update and the supported exit. A tutorial presented as tested needs that execution evidence; a conceptual teaching case should be labelled accordingly.

Keep concrete unknowns and links to the governing documentation beside the relevant fields. Remove generic warnings that add no information about this product. Link deeper explanations only where the reader needs the underlying mechanism.

The completed review should let someone explain the position to another person, locate its accounts and identify what evidence confirms each stage. That is the useful standard for the rest of this library.

Common questions

Is an audit enough to understand a DeFi product?

No. Read its scope and deployment context, then also understand assets, economic rules, controls and exits.

Should every product have the same risk checklist?

Use a shared set of questions, but fill the answers from the actual mechanism. Lending, LPs and staking have different causal paths.

What makes a walkthrough reproducible?

Named assets/programs, documented versions or observation date, actual operation steps and evidence connecting the request to the resulting position and exit.

Sources and documentation

Found an error or an outdated detail? Send a correction.