An institution holding tokenized collateral inherits a risk surface that conventional custody does not produce. A data feed can reprice the asset, a contract can seize it, and a venue can lose depth and leave the position stranded.
That does not make on-chain collateral unmanageable, but it does move the controls: functions that belong to named institutions in conventional markets sit inside code and parameter files instead. An asset risk management framework has to account for that. It should name each control, assign an owner, and set a monitoring cadence matched to the speed of the risk.
This article sets out that framework. It covers the four risk categories that apply to on-chain collateral, the controls for each, why liquidation parameters are risk policy rather than product design, and why the choice of price source belongs to governance.
The Four Categories of On-Chain Collateral Risk
Risk on a tokenized position resolves into four categories. Each fails independently and requires a different control.
Category | What goes wrong | How it differs on-chain |
|---|---|---|
Market | Collateral value falls and a position breaches its threshold | Enforcement is automatic and indifferent to circumstance |
Liquidity | The position cannot be exited at the price the model assumes | Applies to the collateral asset and to the lending market at the same time |
Oracle | The price the system acts on differs from the price a market would pay | An incorrect price becomes an executed liquidation within one block |
Smart contract | Code holding or governing the asset behaves unexpectedly | Produces total loss on the affected position rather than a move along a curve |
Automatic enforcement is what makes this different from conventional collateral management. A position that breaches its threshold at three in the morning in a thin market is liquidated on the same terms as one that breaches at midday, because no credit officer intervenes and no cure period applies. The framework has to hold without human judgment in the loop.
The categories also fail together, which compounds the problem. Utilization spikes and collateral illiquidity arrive in the same event, so a framework that treats them as independent will size exposure against conditions that do not hold at the moment the exposure matters.
Controls for Market and Liquidity Risk
The primary control for market risk is the haircut. On-chain it appears as a collateral factor or a maximum loan-to-value ratio. The haircut converts a view about volatility into a number that limits borrowing.
Setting that number well requires a view on the asset's realized volatility, on the depth a liquidator will find at the moment of sale, and on the reliability of the price feed that triggers the liquidation.
Volatility alone is not enough. A collateral factor derived from it will be wrong for any thin asset, because the liquidation executes into a book that cannot absorb it.
Position limits sit above the haircut. While portfolio weight is a standard metric, sizing positions against exit depth provides a more robust approach to risk management. During stress events, the binding constraint is determined by the actual market liquidity available rather than mandate-based limits alone.
Liquidity risk on the lending side is controlled through supply caps and utilization monitoring. Utilization measures how much supplied capital has been borrowed. A market near full utilization is a market where depositors cannot withdraw. Curators respond by adjusting caps and reallocating capital between markets. Utilization is one of the few metrics that requires continuous monitoring rather than periodic review.
Venue whitelists complete the structure. A whitelist restricts which protocols, markets, and chains the collateral can touch. It caps smart contract exposure and keeps assets where the risk team has done the work.
Liquidation Parameters as Risk Policy
Liquidation parameters are often presented as product features, on the reasoning that a higher permitted loan-to-value ratio makes a better borrowing product. That framing misstates their function. The parameter set is a risk policy written in numbers. Each value decides who absorbs a loss and when.
Parameter | What it controls | The risk decision it encodes |
|---|---|---|
Loan-to-value ceiling | How much can be borrowed against a collateral value | How much price movement the position absorbs before it becomes a problem |
Liquidation threshold | The ratio at which the position becomes liquidatable | The size of the buffer between borrowing capacity and enforcement |
Liquidation incentive | The discount a liquidator receives on seized collateral | Whether liquidators act at all in a stressed market, and how much loss the borrower bears |
Supply and borrow caps | Total exposure permitted in a market | How much loss the system absorbs if the other three are set wrong |
The liquidation incentive carries the most weight. Liquidation depends on third parties choosing to act. If the discount fails to cover execution cost and price risk during a volatile period, positions go unliquidated. The shortfall becomes bad debt held by depositors.
Some designs remove this from discretion by fixing the incentive to a formula tied to the liquidation loan-to-value ratio. That makes the relationship between permitted leverage and liquidator compensation explicit.
Architecture matters as much as the numbers.
Design | Strength | Cost |
|---|---|---|
Isolated markets | A parameter error stays in the market where it was made | Liquidity fragments across markets |
Pooled liquidity | Depth aggregates across the whole protocol | A single bad listing has a wide blast radius |
Immutable parameters | Terms at withdrawal match terms at deposit | An aggressive parameter cannot be corrected later |
Each design trades a known weakness for a known strength. The choice belongs in the risk framework rather than the integration plan.
Oracle Selection Is a Governance Decision
The price source decides what the system believes an asset is worth. Every other control depends on it. A haircut calculated against an unreliable feed provides no protection, because the feed decides when the haircut is tested.
Price source | Manipulation profile | Lag profile |
|---|---|---|
Spot price from a single venue | Vulnerable to anyone able to move that venue temporarily | None |
Time-weighted average price | Resists single-block manipulation, exposed to pressure sustained across the window | Acts on stale valuations during a genuine repricing |
Decentralized oracle network | Manipulation requires corrupting the node set | Bounded by the update policy |
Redemption or net asset value price | Reflects what the issuer will pay rather than what a thin market quotes | Updates on the issuer's cycle |
The Mango Markets exploit of October 2022 remains the reference case. The protocol valued collateral using prices from a thin market for its own token. An attacker built a large position, pushed the price up, and borrowed against the inflated collateral value. Reported losses reached approximately $117 million. The code performed as written: the failure sat in the decision to trust that price source for that asset.
The decision belongs to governance because of what it allocates and who it empowers. Choosing a price source distributes loss between borrowers, depositors, and the protocol, which is a policy judgment rather than a technical one. Whoever can change a feed holds effective authority over every position priced by it, which makes the change process a control question. The right source also depends on what the asset is and who holds it, so the choice requires a view on the asset rather than on the integration.
A complete oracle policy states four things: the price source and its fallback, the staleness tolerance after which the system refuses to act, the deviation limit that halts activity when the feed diverges from an external reference, and the party authorized to change any of it.
Controls for Smart Contract Risk
Smart contract risk resists quantitative treatment. The loss distribution has no useful shape, so the controls are structural. Five checks carry most of the weight:
Audit history. Whether the code has been reviewed, by whom, and whether findings were resolved.
Deployment age and value held. Evidence that the code has been tested by market conditions rather than only by reviewers.
Upgrade authority. Who can change the code, and whether a timelock gives holders time to exit before a change takes effect.
Pause authority. Whether anyone can halt the contract during an incident, and which party holds that power.
Exposure caps. The only control that limits the size of a loss once one occurs.
Immutability cuts across two of those checks, since it removes upgrade risk and the ability to patch a discovered flaw at the same time. Of the five, exposure caps do the most work. A venue whitelist paired with a per-venue limit protects more capital than any amount of diligence on the code.
The Framework
A framework earns its place by assigning each control to a named owner with a defined cadence. Controls without owners are documentation.
Risk category | Primary controls | Owner | Monitoring cadence |
|---|---|---|---|
Market | Collateral factors, position limits, concentration limits | Risk committee sets policy, curator implements | Continuous on price and position health, formal review quarterly |
Liquidity | Supply caps, exposure sized to exit depth, utilization thresholds, venue whitelists | Curator, with whitelist changes at committee level | Continuous on utilization and depth, formal review monthly |
Oracle | Source and fallback selection, staleness tolerance, deviation limits, change authority | Governance body with a defined approval path | Continuous automated monitoring, policy review quarterly |
Smart contract | Venue whitelist, per-venue caps, upgrade and pause authority mapping, timelock requirements | Governance body, informed by security review | Reassessed on any protocol upgrade, formal review semiannually |
Speed of authority decides whether the framework can function under pressure. A governance vote measured in days protects against unilateral action and prevents any response to a fast-moving event, while delegated authority measured in minutes inverts both properties. Neither setting is correct in the abstract, so the choice should be made deliberately and documented alongside the parameters it governs.
Indirect holdings deserve the same scrutiny as direct ones. A vault deposit inherits the risk parameters its curator selected, which means the depositor's real exposure runs to the curator's judgment. That dependency belongs on the risk register under its own name rather than inside a line about the underlying assets.
Where Sentora Sits in This Structure
Sentora operates as a risk curator for on-chain credit markets. The work covers collateral eligibility, collateral factors, rate caps, and exposure limits. It also covers continuous monitoring of collateral quality, utilization ratios, and liquidity conditions.
The problems in this article sharpen when the collateral is a tokenized real-world asset. Liquidating a tokenized equity position while the stock market is closed is an open design question. So is selecting a price source for an asset that stops trading at the weekend. Our work on tokenized equity as productive collateral and gold as on-chain collateral covers how each category behaves.
Sentora Co-founder Jesus Rodriguez, joined by Katya Ternopolska, VP of Sales and Partnerships, and Lucas Outumuro, VP of Institutional DeFi, takes this up in Beyond the Wrapper: What Tokenized Assets Do Next. They discuss what it takes for equities to function as productive collateral for borrowing, hedging, and yield. The session also covers how liquidation, oracle, and liquidity risk are solved at scale, and where the tokenised asset market is heading across Treasuries, credit, and gold.
