Hey, was reading through SCALE and had a question on the safety model. TP/SL and liquidation are enforced by a background monitor checking every 10 seconds, and the pool-never-loses guarantee depends on that close actually landing before price moves past the liquidation threshold. If that worker stalls (deploy, crash, RPC lag, DB contention under load) during a fast move, especially on a Degen-tier token with thin liquidity where a real Uniswap V3 buy can itself move the price a lot, is there any fallback path to close a position, or does execution require your specific backend service to be the one calling it?
Most lending/perps protocols make liquidation permissionless specifically to avoid this, anyone can call it and take a keeper fee, so liveness of any one operator's infrastructure isn't load-bearing for the safety guarantee. Curious whether that's on the roadmap, or whether the custodial/off-chain-monitor model makes that tradeoff intentionally (probably reasonable for an MVP).
Real Uniswap V3 buys instead of synthetic perps is a good call otherwise, means the "your long moves the actual chart" claim is literally true.
I build similar liveness-dependent safety logic myself, a cross-chain vault on Chainlink CCIP (https://github.com/aegonmyy/meridian), where I had to think hard about what happens when the thing that's supposed to react isn't there to react. Happy to talk through it if useful.
Hey, was reading through SCALE and had a question on the safety model. TP/SL and liquidation are enforced by a background monitor checking every 10 seconds, and the pool-never-loses guarantee depends on that close actually landing before price moves past the liquidation threshold. If that worker stalls (deploy, crash, RPC lag, DB contention under load) during a fast move, especially on a Degen-tier token with thin liquidity where a real Uniswap V3 buy can itself move the price a lot, is there any fallback path to close a position, or does execution require your specific backend service to be the one calling it?
Most lending/perps protocols make liquidation permissionless specifically to avoid this, anyone can call it and take a keeper fee, so liveness of any one operator's infrastructure isn't load-bearing for the safety guarantee. Curious whether that's on the roadmap, or whether the custodial/off-chain-monitor model makes that tradeoff intentionally (probably reasonable for an MVP).
Real Uniswap V3 buys instead of synthetic perps is a good call otherwise, means the "your long moves the actual chart" claim is literally true.
I build similar liveness-dependent safety logic myself, a cross-chain vault on Chainlink CCIP (https://github.com/aegonmyy/meridian), where I had to think hard about what happens when the thing that's supposed to react isn't there to react. Happy to talk through it if useful.