@NewtonProtocol I have been thinking about what it really means when offchain code is allowed to influence onchain authorization, and Newton’s approach makes that question feel much more concrete. Its PolicyData oracles are compiled into WASM components, then executed by operators who provide structured inputs and expose the returned JSON back to the Rego policy as runtime data under data.wasm. At first, the obvious focus is on what the oracle can retrieve or calculate. But the more important part is what it is not permitted to touch, because that limit defines the actual shape of the system. Newton is not just running code; it is deciding how much reach that code should have, and that decision changes the entire security story.
The sandboxed Wasmtime environment is where that boundary becomes visible. Oracle components do not get unrestricted access to the surrounding network, which means private ranges, loopback addresses, and link-local addresses are blocked. In practical terms, any HTTP endpoint the oracle calls has to live somewhere publicly reachable. That immediately narrows the oracle’s world, and in a way that feels deliberate rather than restrictive for its own sake. The oracle can also ship with a JSON schema that defines the arguments it expects, so malformed inputs can be rejected before execution even begins. Together, those two pieces create a cleaner execution boundary: the code is constrained, and the caller is constrained too. That matters because a policy oracle is still executable logic, and executable logic without limits can become an unnecessary attack surface very quickly.
What makes this design interesting is that the isolation improves safety without making the underlying trust problem disappear. It simply moves the boundary to a different place. Some systems that hold risk scores, compliance decisions, or internal approval data are not meant to be exposed through public endpoints. If Newton needs information from those systems, the path forward is not automatic. It may require a public gateway, a redesigned access layer, or some other bridge that makes the data usable without exposing the private service directly. That means the sandbox is valuable, but it is not magical. It protects the operator from the oracle, yet it does not protect the policy from unreliable external information, and it certainly does not remove the need to design a trustworthy path between private infrastructure and public access.
That is the part I keep returning to. When an HTTP request fails, the oracle can return structured error data, but the Rego policy still has to be written so that missing valid data, or the presence of an error, results in denial. A full WASM execution failure is different, because Newton describes that as a DataProviderError, which means the evaluation itself may fail rather than simply resolving into an ordinary deny decision. So the application still has to make real choices about which public service sits beyond the sandbox and how that service is secured. The strength of the design is clear: arbitrary code is no longer given arbitrary reach. The harder question is whether that boundary will lead to cleaner, more disciplined integrations, or whether it will push sensitive infrastructure behind public interfaces that become dependencies in their own right. That tension is exactly what makes the model worth paying attention to.