A portfolio screen can show one position while the failure tree contains nine different systems.
Imagine this deliberately generic position: you buy a liquid-staking token on an exchange, withdraw it to another chain through a bridge, deposit it as collateral in a lending protocol and borrow a stablecoin against it.
The ticker count is one. The risk count is not.
My rule: draw the dependency tree before writing the upside case. If you cannot name what must keep working for you to own, finance and exit the position, you do not yet understand the position.
This is an educational framework, not personalised investment advice.
Start with the dependency tree
| Dependency | What you need from it | Failure that reaches your position |
|---|---|---|
| Bank / cash rail | Fund and later withdraw from the venue | Access loss or delayed exit |
| Exchange legal entity | Execute and withdraw the asset | Account restriction, insolvency or withdrawal halt |
| Withdrawal chain | Receive the asset on the intended network | Wrong-network or chain-availability failure |
| Bridge / wrapped representation | Move or represent value across chains | Bridge exploit, pause or redemption failure |
| Staking protocol | Preserve the claim on underlying staked assets | Validator, smart-contract or withdrawal-design failure |
| Lending protocol | Hold collateral and enforce the loan correctly | Contract, governance or liquidation failure |
| Oracle | Price collateral and debt | Bad or delayed price triggers wrong liquidation behaviour |
| Borrowed stablecoin | Remain usable and sufficiently liquid | Depeg, issuer, reserve or redemption stress |
| Wallet and approvals | Keep signing authority and permissions under control | Key loss, phishing, malicious approval or operator error |
The economic position is therefore not “long one token.” It is a stack of claims, software, legal entities and operational controls.
Now break one node and watch the failure travel
Suppose the collateral token falls 15%. That is market risk.
Now suppose liquidity also thins while the oracle updates sharply. The position can approach liquidation faster than the holder expected. That is market risk interacting with liquidity, oracle and leverage risk.
Or suppose the asset price is stable but the bridge pauses. The investment thesis can still be right while the exit route is unavailable.
Or the borrowed stablecoin depegs at the same time as collateral falls. What looked like diversification between “collateral” and “cash-like debt” may become a correlated failure.
This is why a list of risk categories is not enough. The dangerous events are usually paths through dependencies.
Separate loss of value from loss of access
Crypto positions can fail in two fundamentally different ways.
Value loss means the asset or claim becomes worth less because the thesis, liquidity, economics or market changed.
Access loss means you cannot exercise the claim you thought you owned: an exchange will not release it, a bridge is paused, a seed is lost, a contract cannot be exited, or a legal entity no longer serves you.
A stop-loss addresses some market losses. It cannot recover a lost seed or force an insolvent counterparty to process a withdrawal. Self-custody removes one counterparty and does not fix a broken token economy.
The control has to match the failure.
Find the common causes before you count diversification
Three different token symbols can still depend on the same exchange, stablecoin, oracle, chain, bridge or governance multisig.
Tag positions by shared infrastructure rather than ticker:
- custodian or exchange entity;
- blockchain, sequencer or validator set;
- bridge;
- oracle provider;
- stablecoin and reserve/custody chain;
- governance or upgrade authority;
- wallet, signer and recovery process.
If one node can impair several positions at once, that node is a portfolio concentration even when the assets look unrelated.
Replace false precision with consequence bands
I do not like assigning a neat 7.3/10 risk score to systems whose tail probabilities are poorly observed.
Use ranges that force a decision instead:
| Dimension | Question | Useful bands |
|---|---|---|
| Loss severity | What is the worst credible loss from this node? | Reversible / material / near-total |
| Recovery time | How long until access or function returns? | Hours-days / weeks-uncertain / potentially permanent |
| Control | Can I reduce the exposure before failure? | Direct / partial / external dependency |
| Correlation | How many other positions share this node? | Isolated / several / portfolio-wide |
| Evidence quality | How much of the mechanism is directly observable? | Primary / modelled / largely unknown |
The point is not to multiply those labels into a fake scientific number. The point is to expose which failures are both severe and outside your control.
Set acceptance gates before capital enters the stack
A risk framework becomes useful when it can say no.
For the example position, mandatory gates might be:
- the exchange legal entity and withdrawal route are verified;
- a small withdrawal has succeeded;
- the bridge mechanism and canonical asset representation are understood;
- the lending protocol’s liquidation rule and oracle source are documented;
- the stablecoin’s redemption and issuer/control model are acceptable;
- the wallet recovery path has been tested;
- no single dependency can create a loss larger than the predetermined maximum consequence.
If one required gate fails, “high expected return” is not a substitute.
Write the exit before the entry
The exit path should exist in calm conditions before it is needed under stress.
For a layered DeFi position, write the reverse sequence:
- repay or source the borrowed asset;
- withdraw collateral from the lending protocol;
- unwrap or redeem any derivative claim if necessary;
- cross the bridge or use an alternative verified venue;
- send to the intended exchange or custody route;
- sell through executable liquidity;
- withdraw cash through the applicable bank rail.
Then ask which step can be paused, permissioned, illiquid or dependent on another failing asset.
A position with no credible stressed exit should be sized as if the capital can become unavailable, because that is one of its real states.
Monitoring should be tied to action, not anxiety
A dashboard is only useful when a change triggers a defined response.
Examples:
- Collateral ratio deteriorates: reduce leverage or add independent collateral before liquidation becomes the decision-maker.
- Bridge or protocol pauses: stop increasing exposure and verify alternative exit paths.
- Stablecoin trades below its normal range: check primary redemption and reserve evidence before assuming the market price is noise.
- Governance proposes a material upgrade: identify which contract powers or economic rights change and whether an exit window exists.
- Exchange restricts withdrawals: stop treating the displayed account balance as immediately portable liquidity.
- Recovery process changes: re-test custody before increasing the protected balance.
Monitoring without a precommitted response can become a sophisticated way to watch risk accumulate.
Write one condition that kills the position
Every material thesis needs an invalidation condition. A risk framework needs one too.
Examples are mechanism-specific: loss of reliable redemption, a governance change that creates unacceptable unilateral control, repeated oracle failure, inability to withdraw through the required legal entity, or a dependency becoming too concentrated across the portfolio.
The condition should be observable enough that you can later admit it happened.
A position that can survive every imaginable piece of negative evidence is not a thesis. It is attachment.
Framework first, worksheet second
This framework maps the failure architecture: which dependencies exist, how failure can travel through them, and which risks can remove value or access. The Crypto Risk Assessment Worksheet is the execution layer for one specific position.
Use the worksheet after the dependency tree is clear. It turns the map into a pre-mortem, evidence record, risk controls, position-size constraints, liquidity and exit tests, invalidation triggers and a monitoring log. If you still cannot explain the dependency tree, stay with the framework. If you can explain it and are deciding whether—or how much—to own, move to the worksheet.
The framework in one pass
For any crypto exposure:
- Draw every dependency required to buy, hold, finance and exit it.
- Mark whether each dependency can cause value loss, access loss or both.
- Identify common causes shared with the rest of the portfolio.
- Rank failures by consequence, recovery time and how much control you actually have.
- Set mandatory acceptance gates.
- Write the stressed exit route.
- Attach monitoring signals to specific actions.
- Write the condition that invalidates the position or architecture.
The goal is not to predict every failure. It is to stop a hidden dependency from becoming an existential surprise.
For the custody branch of the map, use Hardware Wallet vs Exchange. For protocol exposure, use Smart Contract Risk Explained. For position discipline, continue with Crypto Position Sizing.








