Price oracles for institutional lending: multi-source feeds, deviation checks, staleness protection
Price oracles for institutional lending: multi-source feeds, deviation checks, staleness protection
An oracle is how a smart contract learns the price of anything. A lending protocol can't liquidate an underwater position, or even know it's underwater, without a reliable answer to "what is this collateral worth right now," and since a blockchain can't see outside itself, that answer has to be delivered by an oracle. The quality of that oracle is, quietly, one of the most important things determining whether a lending market is safe.
How it works
A price oracle is a system that brings off-chain price data on-chain in a form smart contracts can use. The naive version, read the price from a single DEX pool, is dangerously fragile, because a single pool can be manipulated: an attacker with enough capital can temporarily distort the price in one pool, trick the oracle into reporting a false value, and exploit a lending protocol that trusted it. Oracle manipulation has been the root cause of some of the largest DeFi exploits on record.
Robust institutional oracles defend against this with several layers. Multi-source feeds aggregate prices from many venues rather than trusting one, so distorting a single pool isn't enough to move the reported price. Deviation checks flag or reject a price that has moved implausibly far from recent values or from other sources, catching both manipulation and genuine data errors before they reach the protocol. Staleness protection ensures the protocol never acts on an old price: if the feed hasn't updated within an acceptable window, the oracle reports the data as stale rather than serving a price that may no longer reflect reality, which matters enormously during fast-moving markets when a few minutes of staleness can be the difference between a clean liquidation and a bad-debt event.
For real-world assets, the oracle problem is different and harder. There's no continuous market price for a private credit receivable or a construction loan the way there is for ETH; pricing illiquid RWA collateral on-chain requires a fundamentally different oracle design based on periodic valuation rather than continuous market data.
Why it matters
The oracle is a single point of failure that sits underneath everything else a lending protocol does. Perfect collateral parameters, conservative LTVs, and well-designed liquidation logic are all worthless if the oracle feeding them can be manipulated or serves stale data at the worst possible moment. The security of the whole lending market is bounded by the security of its weakest oracle.
This is why serious institutional lending treats oracle design as a core risk decision, not an implementation detail. Multi-source aggregation, deviation bounds, and staleness thresholds aren't optional hardening; they're the difference between a lending market that survives a manipulation attempt or a flash crash and one that gets drained by it.
Where this shows up in Rekord
Rekord uses hardened, multi-source price oracles with deviation and staleness protection for crypto collateral, and a separate valuation-based approach for illiquid RWA collateral. For that separate approach, see NAV oracles: how illiquid RWA collateral gets priced on-chain.