Policy
A Policy is a programmable rule set defining conditions that must be met for an action or transaction (an “intent”) to be executed. Policies are created and published by developers in a reusable manner and can be customized by users with parameters such as thresholds, allowlists, or time-based constraints. Policies can rely on offchain verification through Newton’s distributed node network, which can validate real-world data, attestations, and AI agent behavior without revealing sensitive information onchain. Examples:- A spend-limit policy restricting a wallet’s daily transfer limit.
- A jurisdictional policy preventing transfers to sanctioned addresses.
- A policy that requires multi-factor (2FA or TEE-based) validation for high-risk AI-driven actions.
Intent
An Intent represents a proposed transaction or action. It contains standard EVM fields such as from, to, data, and value, but also higher-level context — such as a user’s goal (“swap 1 ETH for USDC”), or an AI agent’s instruction (“rebalance portfolio”). Intents are submitted to Newton for verification against a defined policy. If compliant, a signed proof of compliance is returned, authorizing the transaction.Task
A Task pairs an Intent with its corresponding Policy and configuration. Tasks are the atomic unit of evaluation in Newton. Each Task is either compliant or non-compliant, depending on whether the proposed intent satisfies the active policy. Tasks are submitted by a calling address and evaluated by Newton’s AVS operators, which issue a verifiable proof representing the outcome.Walkthrough
End-to-End Flow
The typical policy lifecycle — from creation to verification — proceeds as follows:1. Developer Deploys a Policy
Developers publish a reusable policy to the Newton registry. Each policy defines:- The logic for compliance evaluation.
- The schema for configuration parameters.
- Optional offchain dependencies (data feeds, attestations, TEE requirements).
2. User Configures Their Policy Client
To activate a policy:- The user instantiates a Policy Client using a chosen policy.
- They supply configuration parameters (such as daily limit or allowlist root).
- The client contract stores this configuration and awaits verified proofs from Newton.
3. Calling Address Submits a Task
A developer or user submits an Intent that should be checked against the policy. This submission becomes a Task, consisting of:- The intent payload (transaction data).
- The linked policy client.
- Optional metadata and nonce.
4. AVS Operators Evaluate the Task
Newton AVS operators independently fetch required data and evaluate the policy. They verify whether the intent meets the defined conditions (e.g., within limits, allowed destination, proper session context). Each operator produces an attestation:- ECDSA signature over the task hash; or
- TEE attestation proving evaluation integrity; or
- Zero-knowledge proof certifying deterministic computation correctness.
5. Proof Returned to the Calling Address
The aggregated proof is returned to the calling address. The proof can now be submitted onchain to the NewtonVerifier contract alongside the original intent. If valid, the verifier emits an allow, reject, or cap decision — enabling the policy client to execute or block the transaction accordingly.Architecture Overview
At a high level, Newton Protocol consists of three interoperating layers:| Layer | Description | Components |
|---|---|---|
| Policy Layer | Defines policies and schemas for rules, thresholds, and offchain inputs. | Policy Registry, Policy Library |
| Compute & Consensus Layer | Offchain policy evaluation performed by the Newton AVS node network. Outputs verifiable proofs of compliance. | AVS Operators, Aggregator, Consensus Proofs |
| Verification & Execution Layer | Onchain contracts that verify proofs and enforce outcomes through composable interfaces. | NewtonVerifier, PolicyClient, SDKs |

- Policy Layer: Developers publish reusable policies; users configure them as Policy Clients with specific thresholds or conditions.
- Compute & Consensus Layer: When a Calling Address submits an Intent, Newton AVS operators independently evaluate it offchain using real-world and onchain data feeds.
- Each node verifies compliance under deterministic rules.
- A leader (Aggregator) collects and aggregates signatures into a Consensus Proof.
- Verification & Execution Layer: The NewtonVerifier contract checks the proof and returns an ALLOW / REJECT / CAP decision.
- The Policy Client enforces this outcome, executing or blocking the transaction.
- DataFeeds: Inputs such as RWA.xyz data, identity attestations, TEE proofs, or AI agent telemetry are validated offchain but never revealed onchain — preserving privacy and compliance.
Why Newton
- Verifiable Trust: Every compliance decision is backed by cryptographic proof, not reputation.
- Privacy-Preserving: Only hashes and commitments are onchain — no PII or sensitive data exposure.
- Composable: Works with wallets, dApps, AI agents, and DeFi protocols through a standard interface.
- Chain-Agnostic: Newton proofs can be verified across any EVM chain via lightweight verifier contracts.
- Extensible: Supports both open-source policies and enterprise modules for regulated financial institutions.