Ammar1112_

I had three packs open in Newton's policy editor, vaults.fyi, RedStone, Chainalysis, checking whether a vault action should be allowed to execute.
Vaults.fyi returned a risk_score of 0.72. RedStone returned a divergence_bps of 38. Chainalysis returned its own risk_score, "low", plus a sanctioned flag set to false.
Two of those three responses use the exact same field name, risk_score, for two completely different things. One is a numeric vault health rating. The other is a categorical sanctions label. Nothing in either provider's JSON warns you in advance, because neither team built their schema knowing the other one existed.
If a naive merge just wrote both responses into one object, the second write wins. Vaults.fyi's 0.72 gets silently replaced by "low". The policy keeps running. No error, no warning, no red text anywhere. It starts comparing a threshold against a value that no longer exists.
I went looking for where Newton actually stops this, because it clearly isn't left to whoever writes the Rego file to notice.
Every pack namespaces its output under its own pack id before anything merges. Vaults.fyi's risk score lives at data.wasm.vaultsfyi.risk_score. Chainalysis's sits at data.wasm.chainalysis.risk_score, a completely different address, even with the identical field name. RedStone's divergence value sits at data.wasm.redstone.divergence_bps. Running Simulate against all three at once, the merged data panel showed exactly that, three separate paths, none touching each other.
That's not a rule telling developers to be careful with naming. It's the merge itself refusing to let the collision happen, before a policy author ever writes a single comparison.
What stayed with me wasn't the bug I didn't hit. It was how unglamorous the fix actually is. Nobody markets namespaced JSON keys. But it's the exact detail standing between a vault policy that correctly blocks a risky action, and one quietly approving it because two unrelated providers happened to agree on a word.
@NewtonProtocol #Newt $NEWT

Since 2016, Open Policy Agent has been the language enterprises write access rules in. Kubernetes admission control, API gateways, CI/CD pipelines, cloud infrastructure everywhere. Ten years of writing rules that decide who gets to do what.
In all that time, Rego could never answer one specific question on its own.
Who actually signed this.
That sounds like something a policy language should obviously handle. It cannot, not natively. Rego compares values, checks membership in lists, combines conditions with boolean logic. Recovering an address from a signature, or confirming a signature matches a specific public key, requires cryptographic math the language was never built to do. Every team that needed that check had to build it somewhere else, outside the policy, then hand Rego a yes or no it had no way to verify on its own.
Newton Protocol extended Rego with a set of functions under a newton.crypto namespace. One is ecdsa_recover_signer. Give it a signature and a hash, it returns the address that actually signed it. Another is verify_signature, which checks a signature against a specific public key using whichever scheme you specify, ECDSA or Ed25519.
That sounds like a small addition. What it unlocks is not small.
A policy can now require two of three authorized signers before approving an action, all inside a single Rego file, no external service confirming who signed what. The policy recovers each signer directly from the signatures it receives and counts how many are on the authorized list.
A policy can verify a delegation chain the same way. Alice signs a delegation giving Bob authority to act. Bob signs the actual transaction. The policy recovers both signers directly, confirms Alice is an authorized principal, confirms the delegation actually names Bob, confirms it has not expired. All of that, one policy, one evaluation.
A policy can even check identity across two different chains at once. Verify a secp256k1 signature proves control of an Ethereum key. Verify an Ed25519 signature proves control of a second chain's key. Confirm both keys are linked in the same identity record. Approve only if all of it holds.
None of these were separate systems duct taped to Rego. They are Rego, extended just enough to answer the one question the original language could never ask by itself.
What stays with me is how the extension was built. NEWT Protocol kept everything under its own namespace so standard Rego, the same OPA a Kubernetes admin already knows, still works exactly the same way. Nobody has to relearn a language to write a sanctions check or a velocity limit. They only reach for newton.crypto when a policy actually needs to know who signed something, and the rest of the policy runs on the same tooling that has existed since 2016.
A multisig approval, a delegation chain, a cross-chain identity check. Three different problems, one language, one evaluation, one attestation at the end.
Rego spent a decade deciding what was allowed. Newton just gave it a way to also confirm who is actually asking.
@NewtonProtocol #Newt $NEWT