A Thin DEX Pool Shouldn’t Automatically Define a Vault Token’s Value
Origami’s hOHM is an interesting example of a problem DeFi lending markets face with structured collateral.
A leveraged vault token can hold assets and liabilities whose combined value is calculable onchain. Yet its DEX price may temporarily diverge from that underlying value when liquidity dries up.
If a lending protocol relies entirely on the market price, a sharp discount can reduce borrowing capacity or trigger liquidations even when the vault’s balance-sheet valuation has not fallen by the same amount.
DIA’s hOHM feed uses a dual-methodology design:
• NAV: Read the onchain balance sheet and calculate per-share intrinsic value using oracle prices for the underlying assets and liabilities.
• Market price: Track the token’s secondary-market price in parallel.
• Aggregation: Apply max(NAV, market price) to select the higher of the two values.
The benefit is clear: a temporary market discount below NAV does not automatically become the collateral price.
But there is a trade-off. If the market price rises above NAV, the same rule chooses that higher price, which can overstate fundamental collateral value.
That is why oracle design cannot be separated from lending risk management. A feed must be evaluated not just by where its data comes from, but by how it combines competing valuation signals.
The important question isn't simply, “What is hOHM trading at?” It's, “Which valuation rule should the lending market trust under stress?” $DIA
Origami’s hOHM is an interesting example of a problem DeFi lending markets face with structured collateral.
A leveraged vault token can hold assets and liabilities whose combined value is calculable onchain. Yet its DEX price may temporarily diverge from that underlying value when liquidity dries up.
If a lending protocol relies entirely on the market price, a sharp discount can reduce borrowing capacity or trigger liquidations even when the vault’s balance-sheet valuation has not fallen by the same amount.
DIA’s hOHM feed uses a dual-methodology design:
• NAV: Read the onchain balance sheet and calculate per-share intrinsic value using oracle prices for the underlying assets and liabilities.
• Market price: Track the token’s secondary-market price in parallel.
• Aggregation: Apply max(NAV, market price) to select the higher of the two values.
The benefit is clear: a temporary market discount below NAV does not automatically become the collateral price.
But there is a trade-off. If the market price rises above NAV, the same rule chooses that higher price, which can overstate fundamental collateral value.
That is why oracle design cannot be separated from lending risk management. A feed must be evaluated not just by where its data comes from, but by how it combines competing valuation signals.
The important question isn't simply, “What is hOHM trading at?” It's, “Which valuation rule should the lending market trust under stress?” $DIA
