A stop-loss is only as alive as whatever holds it. A faster bot doesn't fix that, something off-chain still has to stay awake. It's structural. Stop-loss held by a bot vs held by the chain. Same long, same stop, then I cut the bot's connection. Only the @Somnia_Network one fired. The setup, on testnet: - a bot that checks the price every 2 s and sends the sell itself - a contract the chain wakes every 5 s, checks the price, sells if it's past the stop What happened: - the chain checked 27 times, every one above the stop - the price crossed, the chain sold on its next check. Nobody signed that transaction, the contract sent it itself - the bot's stop was down for 162 s. For all that time, it couldn't fire. @dreamDEXSomnia perps TP/SL already work this way: the chain wakes each one every 5 s, and each holds 0.15 STT to pay for its trigger.

Reactivity vs the polling loop. Same job on 8 EVM chains, a contract reacts to an on-chain event. Only @Somnia_Network did it with no keeper. Two facts never moved: - on Somnia the reaction runs in the trigger's own block, one transaction, nothing watching - the other seven need an off-chain keeper and a second transaction the chain can't react on its own. The honest number is overhead after the trigger is mined: - zero on Somnia because the reaction is in the same block, - a real second transaction everywhere else. A faster keeper doesn't close it. It's structural. "React to this event" becomes a subscription the validators honor in the block the event lands. Everything, reproducible, clone repo and try yourself: reactivity-somnia-test.irony…