A risk framework for onchain allocation

A DeFi risk framework is a layered inventory of the ways an onchain position can lose value, each layer paired with the control that actually reduces it and the signal that tells you it is moving. Eight layers cover most of what an allocator meets: contract, oracle, parameter, venue, counterparty, liquidity, dependency and operational.

Key takeaways

Most published risk material stops at smart contract risk. That is the layer with the best tooling, not the layer that most often costs money, and parameters, keys and dependencies sit outside an audit's scope by definition.
Every layer has a different control. A cap does nothing about oracle error, a timelock does nothing about a bank holiday, and an audit does nothing about an admin key. Matching control to layer is most of the work.
Sizing a risk means being able to observe it first. Before allocating, establish what signal each layer produces and where it is published.

Just the basics

Traditional allocation starts from a credit rating, a prospectus and a counterparty you can name. Onchain, the same money is exposed to a stack of things at once: the code that holds it, the price feed the code trusts, the settings someone chose for that market, the people who can change those settings, whoever ultimately owes the underlying asset, and whether the position can be exited at the price it is marked at. None of those is captured by a yield number. A risk framework is a way of writing each one down separately, so an investment committee can see what it is accepting rather than accepting all of it implicitly.

What is a DeFi risk framework?

It is the document that lets an allocator say what they are exposed to, in what size, under whose control, and what would have to be true for the exposure to lose money. It is not a score or a rating: a score compresses eight independent failure surfaces into one number and hides the binding one. The same objection applies to the headline figure venues are ranked by, because total value locked records how much capital sits in a contract at one moment and says nothing about whose capital it is, what terms it sits on, how fast it could leave, or whether one depositor supplies most of it. Size is not safety. A large number is compatible with every layer below it being unexamined, and with the whole of it belonging to two depositors who leave together.

The framework has three parts and the third is the one usually missing. First, a taxonomy: the list of layers, so that nothing is exposed by omission. Second, a control map: for each layer, the mechanism that reduces it, and honestly, the layers where no mechanism exists. Third, an observation plan: for each layer, the signal that tells you the exposure has changed, and where that signal is published. A framework without the third part is a description of the world on the day it was written.

Onchain work has one structural advantage over traditional credit work: most of the state is public and readable continuously. It also takes something away. There is no issuer with a legal duty to notify you before the terms change, and a supply cap can be raised by a governance vote you did not read. Both facts should shape the framework more than any individual protocol choice.

Why is an audit not a risk framework?

An audit is a point-in-time review of code against intent, performed by people who were not given control of the keys, the parameters or the market. It is genuine evidence, it belongs in the file, and it answers one layer. Three things sit outside its scope. The reason is structural, not a failing of the auditor.

The first is authority. Audited code frequently contains, correctly and by design, functions that let privileged addresses change how the system behaves. Aave's pool configurator exposes loan-to-value, liquidation threshold, liquidation bonus, supply cap, borrow cap and reserve factor as configurable per reserve, guarded by risk admin and pool admin roles. Every one of those is a lever over your position that a clean audit does not remove. Who holds the roles is a separate question from whether the code is correct, and it is the question an allocator has to answer.

The second is time. Parameters change, markets get added, adapters get listed. Morpho's V2 vaults protect potentially harmful curator actions with configurable timelocks between zero and three weeks. A timelock is a notice period, a notice period only helps a party who is watching, and if nobody on your side reads the pending queue then a three-week timelock and no timelock produce the same outcome.

Third comes everything that is not code: key custody, signer processes, the operations team's coverage on a Sunday, the offchain issuer's banking rails. Morpho's own documentation recommends a 4-of-6 multisig for the vault owner rather than a single externally owned account, and a 2-of-4 or 3-of-5 for the curator role. That recommendation exists because the signing arrangement, not the contract, is the exposure at that layer.

None of that is a criticism of auditing. An audit tells you the code does what it says; the framework has to tell you what happens when someone holding the right role tells it to do something else.

What are the layers of onchain risk?

Eight layers, ordered by how directly the allocator can observe them. Each has a distinct failure signature, and separating them stops the strongest control on one layer from being mistaken for coverage of another.

Contract risk is the code doing something other than what its documentation says, and failure looks like assets drained, assets locked, or accounting that silently diverges from reality. Audits, formal verification, code age and value-at-stake history all speak to it before the fact. None of them speak to it in real time. Oracle risk sits one step out, where the price the system believes differs from the price the market would transact at, so liquidations happen that should not have happened, or shares get minted at a price that transfers value from existing holders. ERC-4626's own security considerations warn that preview methods "are manipulable by altering the on-chain conditions and are not always safe to be used as price oracles". The suggested mitigation is to use the convert methods for pricing instead, a distinction real enough to be written into the specification.

Settings are the next layer up. Parameter risk is the case where the code is correct and the values are wrong for current conditions, or right for current conditions and about to change: a collateral asset whose liquidation threshold no longer reflects its liquidity, or a supply cap raised into an asset that cannot absorb it. Here a correct system produces a bad outcome, and that is why the layer is so often absent from a review that starts from code.

At the venue layer, the protocol itself changes its posture toward you. Aave distinguishes freezing a reserve from pausing it: a freeze prevents new supply and borrowing while still allowing repayments and withdrawals, and a pause suspends all interactions with that reserve. Between those two states lies the difference between an inconvenience and an inability to exit. An allocation memo that does not distinguish them has not modelled the venue.

Counterparty risk arrives the moment someone owes you the underlying and that someone is not a smart contract; tokenized real-world assets bring the whole traditional apparatus with them. Ondo's USDY documentation states that Ondo USDY LLC "can only redeem USD via bank wire to non-US bank accounts", with redemption for USDC available through a separate BVI entity. The obligor, the entity, the jurisdiction and the payment rail are all part of the position.

The liquidity layer is about marking. A position can be marked at a price at which it cannot be exited in the size held, in the time available, and the failure then shows up as a redemption queue, a discount on the way out, or a forced sale into the move that caused the redemption. Settlement design and risk meet here, and the mechanics are treated at length in how settlement works in an onchain fund.

Dependency risk has a recursive shape. The asset held is a claim on another system that is itself a claim on another system, and wrapped assets, bridged assets, liquid staking receipts and yield-bearing collateral all take that form. Failure propagates: the market you allocated to prices a receipt, the receipt references a protocol you never reviewed, and a problem three steps away arrives as bad debt in the market you did review.

Keys, roles, upgrade paths, monitoring coverage and the internal process for approving a change make up the operational layer. Failure looks like an unauthorised transaction signed with valid credentials, and onchain that is indistinguishable from an authorised one.

Matching a control to each layer

Every layer has one or two controls that reduce it and several that look like they do; the table below records the residual for each one, since a framework that claims full coverage of every layer is not describing this asset class.

Risk layer	Control that mitigates it	Control that does not	What residual remains
Contract	Audit, formal verification, value-at-stake seasoning, exposure cap sized to survive total loss	Diversifying across forks of the same code	Unknown unknowns in unaudited paths and new deployments
Oracle	Independent price source, deviation bounds, using convert rather than preview methods for pricing	Trusting a share price computed by the vault being priced	Correlated feed failure and thin-market reference prices
Parameter	Reading the pending change queue, absolute and relative caps per risk identifier, a defined tripwire that reduces exposure on change	Assuming today's parameters persist because they are conservative	Governance can change terms faster than a committee can meet
Venue	Modelling freeze and pause separately, pre-agreed exit path, position sizing against the slowest exit	Historical uptime	A venue can pause for reasons unrelated to your position
Counterparty	Named obligor, jurisdiction, payment rail, eligibility terms read before allocation	Onchain transparency of the token contract	The obligor's balance sheet is not onchain
Liquidity	Queue design, redemption windows matched to the slowest leg, forced exit paths such as a permissionless deallocation	Headline market depth on a calm day	Correlated redemption across holders
Dependency	Mapping collateral to its terminal obligor, relative caps on shared factors such as one oracle or one wrapper	Counting a wrapped asset as its underlying	Contagion arrives through venues you did review
Operational	Multisig thresholds, role separation between the party that sets policy and the party that executes, time-delayed admin transfer, reactive risk-reduction roles	A signed policy document	Valid credentials used by the wrong hands look normal onchain

One nuance from the same documentation is worth carrying into any control design. In Morpho's V1 vaults the guardian can revoke a pending market cap increase, a pending timelock decrease and a pending guardian change, but it "cannot revoke a pending fee". A veto power is only as broad as the list of actions it covers, and the list is usually shorter than the word "guardian" suggests.

How does an allocator size an exposure?

Size against the layer with the slowest recovery rather than the layer with the highest probability, since a one-in-fifty event you can exit from in an hour is cheaper than a one-in-five-hundred event that locks capital for a quarter. A workable sequence runs as follows.

Map the position to its terminal obligor. Write down what the fund actually holds at the end of the chain rather than the ticker at the top of it, because if three venues in the strategy all reference the same wrapper, that is one exposure wearing three names.
Set an absolute cap on the risk identifier rather than the market. Morpho's V2 vaults model this directly, letting a curator cap total exposure to a collateral identifier across markets and set a relative cap such as a maximum share of the vault allocated to markets using one specific oracle. Caps at market level miss the concentration that matters.
Assume the slowest exit path. For each venue, take the exit that applies when conditions are bad: the queue, the cooldown, the non-instant redemption route. Ondo's OUSG offers instant redemption above a $5,000 minimum subject to daily limits, while amounts above those limits use the non-instant route with a $50,000 redemption minimum. A position sized to the instant path is sized to the good day.
Set the parameter tripwire before allocating. Decide in advance what parameter change reduces the position automatically, and who has the authority to act inside the timelock window without waiting for a committee.
Test the exposure against total loss of the largest single layer. This is not a portfolio-wide stress scenario, since averaging across positions removes the point. Take one venue, one contract or one obligor and assume it is gone. If the answer is unacceptable, the cap is wrong.
Write the residual down. The layers you have not controlled are the position's real risk profile, and naming them is what distinguishes a framework from a marketing document.

If you are building this out for a live mandate, talk to the Railnet team about what your venue set actually exposes you to; the mapping work is specific to the strategy.

What should be monitored, and how often?

The layers that publish state can be watched continuously. Everything else runs on a schedule, since an offchain layer emits its signal when someone sends an email rather than block by block.

Continuous monitoring covers utilisation and available liquidity per venue, oracle deviation against an independent reference, position value against expected value, queue depth and time-in-queue for outstanding redemptions, and the pending change queue for every venue whose parameters bind your position. That last item is the most neglected and the cheapest to add. A timelock is only protection if somebody is reading it.

On a schedule: obligor and issuer standing for any real-world asset leg, eligibility and access terms, the composition of signer sets and role holders, and whether the recovery path you documented at allocation still exists. Quarterly is a defensible cadence for most of these, and monthly is better for anything with an offchain counterparty.

The awkward part is that most allocators are assembling this per venue. Ten protocols means ten dashboards, ten definitions of utilisation, and ten places to look for a pending parameter change, so exposures end up hiding in the gaps between systems rather than inside any one of them. Consolidating the view matters for a substantive reason: a correlation between two positions is invisible until both are described in the same terms.

Multi-venue failure in practice

A multi-venue failure looks like several small, individually survivable events arriving on the same afternoon because they share a factor nobody had written down. Take a strategy holding a lending position collateralised by a wrapped asset, a second lending position in a different market that also accepts that wrapper, and a tokenized treasury leg for duration. On paper this is three venues and two asset classes. In dependency terms it is two exposures, because the wrapper is one obligor appearing twice, and the treasury leg's exit runs through a payment rail that is closed on a weekend.

Now suppose the wrapper's reference price moves against the collateral. Both lending positions see the same oracle move at the same time, both markets tighten together in exactly the correlation the position sizing assumed away, and the natural response is to raise cash from the leg that is not affected, the treasury leg, whose redemption runs on the slowest clock in the book. Nothing here requires a hack, a bug or a bad actor. It requires only that dependency risk and liquidity risk were tracked in different documents.

The controls that would have caught it are unglamorous: a relative cap on shared oracles, a mapping from each position to its terminal obligor, and a liquidity assumption drawn from the slowest exit rather than the fastest. All three are in the table above, and all three are cheap compared to the alternative.

How does Railnet fit?

Railnet is the operating layer for onchain asset management, and its contribution to risk work is that positions across venues are described in one model rather than ten.

Every capital movement runs as a Query through one state machine, whether the underlying venue settles in a block or on a cooldown, so an in-flight position is a readable state rather than a gap in the ledger. Movements are recorded as transfers between sectors under double-entry rules, and that is what makes an exportable audit trail possible rather than a reconstruction after the fact.

The layer this data sits at determines whether it can be assembled at all. Protocols publish their own parameters and nothing about who else holds what. Curators set risk limits inside a single vault. Asset managers hold the mandate, and distributors see only their own users. The vault infrastructure holding the strategy is the one place where every leg is expressed in common terms at the same moment, and that is where cross-venue correlation and shared-dependency exposure become readable rather than inferred from five reporting formats. Railnet operates at that layer.

Dedicated tooling for the decisioning half of this was still a proof of concept as of July 2026, so it is not something to plan a process around yet. What exists today is the position record described above. Implementation detail sits in the Railnet developer documentation.

What should you do next?

Start with the layer you currently cannot observe. For most allocators that is parameter risk or dependency risk. Both are readable onchain and both usually go unread. Write the taxonomy for the venues you already hold, fill in the control column honestly including the blanks, then decide whether the residual is inside the mandate. The order matters more than the format, because a taxonomy assembled after the controls have been chosen tends to list the layers those controls already cover and to leave out the pending parameter queue nobody is reading and the wrapper sitting in three positions under three different names. Start it before the next allocation.

The compliance dimension, meaning what the architecture must do rather than what the risk is, is treated separately in how compliance is enforced onchain.

FAQ

What is a DeFi risk framework?

A layered inventory of how an onchain position can lose value, with a control and an observation signal attached to each layer. It is not a score. A single number compresses independent failure surfaces and hides the one that binds, and that is exactly the information an investment committee needs when deciding whether an exposure fits the mandate.

Why is an audit not enough?

An audit reviews code against intent at one point in time, and it does not cover who holds the admin roles, what parameters those roles can change, how keys are custodied, or whether an offchain obligor can pay. Audited code routinely contains privileged functions by design, and those functions are levers over your position that a clean report does not remove.

What are the layers of onchain risk?

Contract, oracle, parameter, venue, counterparty, liquidity, dependency and operational. Each has a distinct failure signature, and the point of separating them is that a strong control on one layer is frequently mistaken for coverage of another. A supply cap is not oracle protection, and a timelock is not custody.

How should an allocator size a DeFi position?

Against the layer with the slowest recovery rather than the highest probability. Map the position to its terminal obligor, cap exposure at the risk identifier rather than the market, assume the slowest exit path applies, define a tripwire for parameter changes, and test the position against total loss of its largest single layer.

What is parameter risk?

The case where the code is correct and the settings are wrong, or are about to change. Loan-to-value, liquidation threshold, supply and borrow caps and reserve factors are all configurable per reserve by privileged roles, and those roles do not need your consent. Reading the pending change queue is the cheapest control in the whole framework.

What is the difference between a frozen and a paused venue?

Freezing a reserve prevents new supply and borrowing while still allowing repayments and withdrawals. Pausing suspends all interactions with it. One is an inconvenience, the other removes your exit, and an allocation memo that treats them as the same state has not modelled the venue.

How is dependency risk different from counterparty risk?

Counterparty risk is a named obligor who owes you the underlying, usually offchain. Dependency risk is structural: the asset is a claim on a system that is itself a claim on another system, so a failure two or three steps away arrives at your position as bad debt in a market you did review.

Talk to the team

Railnet builds the operating layer that asset managers use to run strategies across multiple venues with one risk model and one reporting standard. If you are writing a risk framework for an onchain mandate or trying to see correlated exposures across venues, talk to the team. There is no form to fill in first.