jonk.eth

I’ve written plenty on it in the past so won’t spend an essay on it today, but when it comes to stablecoins (including those for ETH or other reference assets), hard-coded oracles are brittle. They work until they catastrophically don’t. In contrast, live oracles allow for real-time risk mitigation, but at the cost of punishing users for false positives if liquidity dries up. Both are a legitimate design choice, but need to follow different underwriting processes. Only hard code if you diligence the underlying asset and are confident in its ability to meet redemptions as designed. Both the technical and financial fundamentals must be solid, and assign a risk premium to rates or haircut to LTV as appropriate. Live oracles let you be relatively agnostic about the quality of the asset (beyond technical safety of the smart contracts) and stay focused on the liquidity availability. Let’s also remember that more complex oracle setups are also possible. I personally have advocated for stablecoins to have a hard code when n liquidity is viable in a redemption contract and then switch to market price oracles the moment liquidity falls below n. Ultimately, this is surfacing again a longstanding “credit migration” problem where DeFi relies on curators and risk consultants to manually flag when an asset goes from excellent to good to fair to poor as collateral. That’s far too slow in cases like USR, even if it was 100% accurate. DeFi automates, speeds up, and simplifies (even if it sometimes seems otherwise) finance compared to traditional alternatives. We’re ultimately building financial vending machines, and it’s just a fact that it’s really hard to make a machine that works as intended under all conditions. But there’s clear ways to improve on both oracle design and oracle use, and it’s disappointing to see slow innovation on that front.