Policy Engine and Composability
Rego Policy Language
Newton’s policy engine is built on Newton Rego, an extended version of the official Rego language from the Open Policy Agent (OPA) project — an enterprise-grade, battle-tested, open-source policy infrastructure widely adopted for Kubernetes admission control, API gateway authorization, and CI/CD pipeline policies. Newton extends the base Rego engine with privacy-preserving cryptographic operations and extensible cryptographic primitives for cross-chain signature verification and hash computation, while preserving full compatibility with the existing OPA ecosystem, tooling, and policy libraries. Rego policies are pure functions: given the same input data and policy rules, evaluation always produces the same result. This determinism is essential for Newton’s security model — it enables challengers to independently verify any evaluation and prove correctness via zero-knowledge proofs. Policies are content-addressed on IPFS via CID, ensuring all operators fetch and evaluate the exact same rule set.Newton-Crypto Extensions
Newton Rego adds Ethereum-specific cryptographic builtins to the Rego evaluator:| Function | Arguments | Return | Purpose |
|---|---|---|---|
newton.crypto.ecdsa_recover_signer(sig, hash) | 65-byte hex signature, 32-byte hex keccak256 hash | Checksummed Ethereum address (0x-prefixed) | Recover signer from raw hash |
newton.crypto.ecdsa_recover_signer_personal(sig, msg) | 65-byte hex signature, raw message string | Checksummed Ethereum address (0x-prefixed) | Recover signer from personal_sign message |
newton.* namespace convention and are registered at engine initialization. The cryptographic extensions are isolated to minimize upstream divergence from the base Rego engine. The extension model is designed for cross-chain extensibility — the newton.crypto namespace provides a unified surface for adding signature verification and hash computation primitives across blockchain cryptographic schemes, enabling policies that operate across chain boundaries without per-chain policy rewrites.
WASM-Sandboxed Data Providers
External data (sanctions lists, risk scores, oracle feeds, API responses) is fetched through WASM plugins that execute in a sandboxed Wasmtime environment. Each plugin implements the WebAssembly Component Model interface, receiving JSON arguments and returning JSON data. The sandbox enforces strict resource limits to prevent denial-of-service and resource exhaustion:| Resource | Reference Default | Purpose |
|---|---|---|
| CPU instructions | 100 million | Prevent infinite loops |
| Stack memory | 64 MiB | Prevent stack overflow |
| HTTP requests | 50 per execution | Rate limiting |
| HTTP request size | 1 MiB per request | Memory protection |
| WASM binary cache | 100 MiB | Disk usage limit |
NPE-Encrypted Secrets
Policy data providers often require API keys, authentication tokens, or other secrets to access external data sources. Newton encrypts these secrets using the Newton Privacy Envelope (NPE), the same HPKE-based construction used for policy data privacy (Privacy Architecture):- Clients encrypt secrets into a SecureEnvelope using the system’s combined X25519 public key (the DKG-produced threshold key stored on-chain in the operator registry).
- Encrypted envelopes are uploaded and stored in the encrypted data store.
- During the Prepare Phase, when operators execute WASM data providers, the encrypted secrets are distributed alongside the task payload.
- Each operator produces a partial decryption share using its DKG-produced share of the threshold private key and exchanges shares with peers via encrypted NATS messages (see Privacy Data Flow). Once t shares are collected, the operator reconstructs the secret locally.
- The decrypted secret is injected into the WASM sandbox for the duration of the data provider execution. Decrypted secrets exist only in memory during execution and are never persisted in plaintext.
- After WASM execution completes, the decrypted material is dropped.