Skip to main content
Newton Protocol is a decentralized policy engine that enables developers and institutions to encode, verify, and enforce programmable compliance rules and security guardrails across both onchain and offchain systems. It serves as a verifiable execution layer for trust and compliance — capable of protecting users against malicious AI agents, enforcing regulatory policies for tokenized assets, or governing financial transactions under jurisdictional rules. Newton is chain-agnostic and modular by design. It integrates easily with most EVM-compatible networks such as Ethereum, Base, and Arbitrum, with non-EVM support planned through standardized verification interfaces and cross-chain proof relays. Newton transforms compliance from a human-centric, offchain process into a verifiable compute primitive — enabling developers to embed rules directly into application logic, while still preserving privacy, composability, and decentralization.

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).
On mainnet, Newton will maintain a catalog of canonical policies — e.g., spend limit, KYC-verified transfer, AI guardrail — that can be easily customized.

2. User Configures Their Policy Client

To activate a policy:
  1. The user instantiates a Policy Client using a chosen policy.
  2. They supply configuration parameters (such as daily limit or allowlist root).
  3. 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.
The task is signed and sent to the Newton AVS network for evaluation.

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.
Once quorum is reached, the operators’ signatures are aggregated into a single Consensus Proof (threshold ECDSA or BLS).

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:
LayerDescriptionComponents
Policy LayerDefines policies and schemas for rules, thresholds, and offchain inputs.Policy Registry, Policy Library
Compute & Consensus LayerOffchain policy evaluation performed by the Newton AVS node network. Outputs verifiable proofs of compliance.AVS Operators, Aggregator, Consensus Proofs
Verification & Execution LayerOnchain contracts that verify proofs and enforce outcomes through composable interfaces.NewtonVerifier, PolicyClient, SDKs
This layered structure separates policy definition, policy evaluation, and policy enforcement, allowing Newton to remain modular, verifiable, and chain-agnostic. image.png
  • 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.

Summary

Newton Protocol redefines compliance as a programmable, verifiable primitive for decentralized systems. Developers can encode logic once — from security limits to AI safety checks — and have it enforced consistently across users, agents, and chains. By combining deterministic policy computation, offchain consensus verification, and onchain composability, Newton establishes a new foundation for trust, compliance, and safety in autonomous systems — powered by the NEWT token and sustained through a decentralized, self-reinforcing economic model.