every mechanism ive gone through so far in this series, the liquidation threshold, the fairness surplus, all of it, quietly assumes one thing works correctly in the background. price. none of that math means anything if the price feed feeding it is wrong, and thats worth actually looking at instead of taking for granted.
liquidation triggers off a BTC/USD price feed crossing a threshold relative to the debt owed. the fairness payment calculation, figuring out whether a seized vault exceeded what was actually owed, runs on that same kind of pricing, plus a WBTC/USD feed for whenever the surplus gets settled in that specific asset. these arent side details bolted onto the design. theyre load-bearing. get the price wrong at the wrong moment and you get a liquidation that shouldnt have happened, or a fairness payment that shortchanges someone who was never actually underwater.
what makes this different from the rest of the design ive covered is that everything else so far was verifiable through cryptography or bitcoin script directly, hashlocks, proofs, timelocks, things you can check are correct just by looking at them. price is not that. price is external by definition, its an oracle's job to report something happening in the outside world, and no amount of clever contract design changes the fact that the contract is trusting a number it cant independently verify against reality.
this is where the "trustless" framing gets genuinely harder to hold onto without qualification. everything upstream of liquidation is enforced by math thats checkable on-chain. the trigger for liquidation itself depends on a feed thats reporting from outside the system, and however that oracle is secured becomes, quietly, one of the more important trust assumptions in the entire stack.
so does the oracle setup here actually get talked about with the same scrutiny as the cryptographic parts, or does it slide under the radar because "price feed" sounds routine compared to hashlocks and zk proofs.
#baby @BabylonLabs_io $BABY
liquidation triggers off a BTC/USD price feed crossing a threshold relative to the debt owed. the fairness payment calculation, figuring out whether a seized vault exceeded what was actually owed, runs on that same kind of pricing, plus a WBTC/USD feed for whenever the surplus gets settled in that specific asset. these arent side details bolted onto the design. theyre load-bearing. get the price wrong at the wrong moment and you get a liquidation that shouldnt have happened, or a fairness payment that shortchanges someone who was never actually underwater.
what makes this different from the rest of the design ive covered is that everything else so far was verifiable through cryptography or bitcoin script directly, hashlocks, proofs, timelocks, things you can check are correct just by looking at them. price is not that. price is external by definition, its an oracle's job to report something happening in the outside world, and no amount of clever contract design changes the fact that the contract is trusting a number it cant independently verify against reality.
this is where the "trustless" framing gets genuinely harder to hold onto without qualification. everything upstream of liquidation is enforced by math thats checkable on-chain. the trigger for liquidation itself depends on a feed thats reporting from outside the system, and however that oracle is secured becomes, quietly, one of the more important trust assumptions in the entire stack.
so does the oracle setup here actually get talked about with the same scrutiny as the cryptographic parts, or does it slide under the radar because "price feed" sounds routine compared to hashlocks and zk proofs.
#baby @BabylonLabs_io $BABY