#newt $NEWT @NewtonProtocol
#newt $JCT
Was going through Newton’s multi-oracle guide today and one small sentence changed how I was thinking about policy composition.
When a policy references several data oracles, Newton runs every referenced WASM oracle first, merges all of their outputs into "data.wasm", and only then evaluates the Rego policy.
So adding another oracle isnt just adding another condition.
It is adding another live dependency to the authorization path.
Newton recommends handling multi-oracle policies through a deny set, where every oracle can contribute its own reason for rejection and the transaction is allowed only when nothing denies it. It also recommends failing closed when an oracle returns an error.
That design makes sense from a security perspective. A sanctions provider going offline probably shouldnt quietly turn sanctions screening off. A broken risk feed shouldnt be treated as proof that risk is acceptable.
But the tradeoff landed differently for me today.
The more independent signals a policy requires, the stronger its coverage can become, while its availability can move in the opposite direction. Under a fail-closed design, one unavailable provider can stop the entire authorization even when every other signal looks fine.
Not necessarily a flaw.
More like the cost of treating missing information as risk instead of permission.
Still curious whether Newton eventually supports conditional oracle execution, where the transaction type determines which providers actually need to run, or whether institutions will need separate policies to avoid making every action depend on every oracle.
Does stronger policy composition eventually create better security, or just a larger collection of systems that must all stay online at once??
#Newt @NewtonProtocol
#newt $JCT
Was going through Newton’s multi-oracle guide today and one small sentence changed how I was thinking about policy composition.
When a policy references several data oracles, Newton runs every referenced WASM oracle first, merges all of their outputs into "data.wasm", and only then evaluates the Rego policy.
So adding another oracle isnt just adding another condition.
It is adding another live dependency to the authorization path.
Newton recommends handling multi-oracle policies through a deny set, where every oracle can contribute its own reason for rejection and the transaction is allowed only when nothing denies it. It also recommends failing closed when an oracle returns an error.
That design makes sense from a security perspective. A sanctions provider going offline probably shouldnt quietly turn sanctions screening off. A broken risk feed shouldnt be treated as proof that risk is acceptable.
But the tradeoff landed differently for me today.
The more independent signals a policy requires, the stronger its coverage can become, while its availability can move in the opposite direction. Under a fail-closed design, one unavailable provider can stop the entire authorization even when every other signal looks fine.
Not necessarily a flaw.
More like the cost of treating missing information as risk instead of permission.
Still curious whether Newton eventually supports conditional oracle execution, where the transaction type determines which providers actually need to run, or whether institutions will need separate policies to avoid making every action depend on every oracle.
Does stronger policy composition eventually create better security, or just a larger collection of systems that must all stay online at once??
#Newt @NewtonProtocol