Hmm. Not sure how you’d do a local bypass? (since any call to the oracle is noted and the oracle’s state changes with every call).
The UX price you can handle by wrapping the oracle interaction in handled libs/having your program run on a random seed that gets pulled initially/periodically (which for sidechannel reasons is better anyway)
I can query my own node’s oracle locally, as if txs from the network were received. If I see a result I like I can rewind my local node to the network’s state and broadcast the same ‘good’ tx to the network.
It all collapses to the same solution we have now - there’s shared randomness/hidden internal state. That, alongside some external public information can lead to fresh pseudo-randomness, but this is risky since it can be manipulated. Surely, there are ways to minimize that exposure (e.g., your suggestion, or others that make it really hard to predict that oracle locally and then broadcast that to the network), but it’s tricky, and in that case I’d argue that using other solutions like commit-reveal or threshold signatures are better.
Clearly, I’m playing devil’s advocate here. I’m happy to be proven wrong on this, but to do so you should propose a more complete solution that carefully examines the issue of oracle manipulation/predictability.
You don’t need to query it directly, but because all nodes run the same calculations and have the same state you can run calculations locally without broadcasting them, specifically calculations that use the oracle’s state after the “request for x bits of randomness” you described. If the response is on-chain like you said then it’s part of the state of every node (even if it’s encrypted), and there’s no way calling the oracle, waiting for the response and using the randomness in the same tx/block, because then we are exposed to reentrancy attack https://www.cosmwasm.com/docs/getting-started/smart-contracts#avoiding-reentrancy-attacks