About

Newton Protocol is a policy engine that allows you to encode, verify, and enforce rules—such as spend limits, jurisdictional gating, or fraud prevention—directly within your smart contracts.

​

The Problem

Smart contracts are built to initiate onchain actions like mints, transfers, and swaps. However, they are inherently “blind” to offchain contexts, such as whether a user is sanctioned, if an AI agent is hallucinating, or if a transaction violates a corporate spend policy. Furthermore, traditional security often relies on “closed-loop” gates like frontend filters or centralized API checks. These measures leave protocols vulnerable to unauthorized actions initiated outside your controlled environment, such as through third-party aggregators, autonomous agents, or direct CLI interactions.

​

The Solution

Newton bridges this gap by informing onchain actions with real-time offchain data—including KYC status, market feeds, and proof of reserves—all while preserving privacy and decentralization. Because these rules are enforced at the smart contract level, your protocol remains protected regardless of where the transaction originates. This allows developers to move beyond static allowlists and implement dynamic, real-time guardrails that block high-risk or non-compliant actions at the source.

​

Modular and Chain-Agnostic

Newton is modular by design and integrates easily with most EVM-compatible networks, including Ethereum, Base, and Arbitrum. Non-EVM support is currently on our roadmap to provide a universal safety net for open protocols and autonomous agents across the entire ecosystem.

Try the demo

See a live example of a Newton-powered sanctions-checked transfer app

​

Core Concepts

To build with Newton, it helps to understand the three pillars of its architecture: Policies, Intents, and Tasks.

​

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: This layered structure separates policy definition, policy evaluation, and policy enforcement, allowing Newton to remain modular, verifiable, and chain-agnostic.

• 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 is a policy engine that allows you to program and enforce rules with both onchain and offchain data directly within your smart contracts. Whether you are adhering to jurisdictional requirements for cross-border payments, defining risk managed thresholds for vault trades, or setting safety guardrails for AI agents, Newton allows you to enforce dynamic, real-time policies that keep your protocol secure at the source. 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.