Newton Protocol: Decentralized Policy Engine for Onchain Compliance and the Agentic Economy

Abstract
The global financial system is being reshaped by two transformative trends.
First, public blockchains have matured beyond speculative activity into programmable infrastructure, now settling trillions of dollars annually through stablecoins, tokenized real-world assets (RWAs) and decentralized finance (DeFi). Yet despite this growth, institutions remain on the sidelines, constrained by the absence of a trusted compliance framework capable of reconciling regulatory obligations with the openness of onchain ecosystems. In 2023, global compliance expenditures exceeded $274 billion, underscoring the persistence of inefficient, fragmented systems designed for a paper-based, pre-digital era.
Second, AI agents are emerging as autonomous participants in financial interactions, demonstrated by their rapidly expanding capabilities in agentic finance and commerce. Experiments with agentic wallets and self-operating trading bots highlight both the opportunities and risks of machine actors in financial markets. However, while the industry has heavily emphasized expanding agentic capabilities, it has underinvested in the infrastructure required to ensure security and compliance, leaving systems vulnerable to a growing number of exploits. Without embedded guardrails, AI agents operating on crypto rails could launder funds, exploit DeFi, or evade sanctions at machine speed, creating risks far beyond the reach of traditional oversight.
The future of both institutional adoption and safe AI integration depends on embedding compliance directly into the execution fabric of programmable money and digital assets. Regulators have begun to acknowledge this need: the U.S. Treasury’s 2025 Request for Comment explicitly calls for cryptographic systems capable of enforcing identity verification and detecting illicit activity while preserving privacy.
Newton Protocol addresses this challenge with a decentralized policy engine for programmable compliance. It enables institutions, issuers and developers to codify compliance, risk and business rules as enforceable policies evaluated at the point of execution. Policies are validated by decentralized operators secured through Ethereum’s restaked security model, with results attested via cryptographic receipts or zero-knowledge proofs for privacy-preserving verification. In doing so, Newton Protocol transforms compliance from a static, after-the-fact burden into a neutral, programmable and composable substrate that institutions, regulators and AI systems can build on.
This paper outlines the inefficiencies of traditional compliance, the unique opportunities enabled by onchain enforcement, the architecture of Newton Protocol, and its applications across institutional DeFi, stablecoins, RWAs and AI agent guardrails.
1. Compliance as Artifacts
Compliance in traditional finance is dominated by manual, document-heavy processes. Institutions are generally bound by several broad categories of obligations, including:
- Customer due diligence (KYC): verifying customer identity and assessing risk.
- Counterparty screening: checking against sanctions lists and politically exposed person (PEP) databases.
- Transaction monitoring: detecting suspicious patterns, unusual flows, or structuring behavior.
- Regulatory reporting: filing Suspicious Activity Reports (SARs) and Currency Transaction Reports (CTRs); providing audit trails to supervisors.
(Source: FATF Recommendations, U.S. Bank Secrecy Act, EU AML Directives)
Despite their importance, these processes remain largely reactive, fragmented and costly. In 2023, the U.S. Financial Crimes Enforcement Network (FinCEN) received nearly 25 million compliance reports, the majority of them retrospective. Auditors often rely on sampling and reconstructed narratives after the fact, while compliance officers devote significant resources to producing documents that fulfill formal requirements but offer little in the way of real-time risk mitigation.
As regulations expand, such as the FATF “Travel Rule” mandating beneficiary and originator data for transfers, or the EU’s extension of these requirements to all crypto transactions, the burden only intensifies. Compliance costs scale linearly with transaction volume, creating bottlenecks that stall liquidity and embed structural inefficiencies. The core problem is that compliance is still treated as a matter of paperwork, not of live, verifiable enforcement.
2. The Onchain Opportunity
Blockchains have already introduced two primitives that reshaped finance:
- Smart contracts made execution programmable.
- Oracles made data composable.
The next critical primitive is now emerging: Policies to enable compliance-as-code.
The supporting infrastructure is already in place. Transactions are transparent, timestamped and secured by cryptographic signatures. Smart contracts enforce rules deterministically at the point of execution. Oracles connect onchain logic with offchain realities. Zero-knowledge proofs now make it possible to validate compliance conditions without exposing sensitive information.
The first elements of compliance-as-code are already visible. For example:
- Chainlink Proof-of-Reserve provides real-time assurance that stablecoins remain fully collateralized.
- TRM and similar providers publish sanctions and fraud data as oracle feeds.
- Polygon ID and World ID allow wallets to prove facts such as “I am over 18” or “I am not sanctioned” without disclosing the underlying credential.
Even regulators have begun to encourage such approaches. The U.S. Treasury, for instance, has explicitly called for cryptographic systems that can enforce identity verification and detect illicit activity while preserving privacy.
Yet these components remain fragmented. Stablecoin issuers still manage KYC through centralized databases. RWA platforms often operate on permissioned ledgers. Institutional DeFi pilots rely on whitelisted walled gardens. These models sacrifice openness and composability, the core advantages of public blockchains.
What is needed is the consolidation of these efforts into a neutral, decentralized compliance substrate: a shared layer where institutions, regulators and developers can define and enforce policies that are verifiable, privacy-preserving and composable. Just as smart contracts became the execution primitive and oracles became the data primitive, policies can become the compliance primitive, establishing compliance-as-code as the foundation for the next phase of finance, with institutions moving onchain and AI agents operating safely within programmable markets.
3. Newton Protocol: Compliance-as-Code
Newton Protocol is designed as this substrate. At its core, Newton Protocol is a decentralized policy engine that enables the encoding and enforcement of compliance rules, risk controls and business logic as machine-executable policies.
A Newton Policy is a programmable rule set that determines whether a transaction should proceed, be delayed, or be denied. Unlike offchain compliance processes, Newton Policies are enforced as part of smart contract execution. Each transaction is evaluated by decentralized operators against the relevant policies, with the results signed and attached as cryptographic receipts. Where privacy is critical, zero-knowledge proofs allow compliance checks to be proven without revealing underlying data.
By turning compliance into programmable infrastructure, Newton Protocol transforms enforcement from an overhead process into a compliance primitive for programmable financial infrastructure. Institutions can meet regulatory requirements without losing composability, regulators gain real-time supervision and users maintain privacy-preserving sovereignty.
3.1 Solving Real-World Compliance Challenges
- Traditional KYC/AML stacks are batch-heavy (collect → review → file), creating delays, manual errors and high false positive rates.
- “Travel rule” and cross-jurisdiction obligations require originator/beneficiary metadata to move with value, today glued on by off-chain vendors, not enforced at settlement.
- Stablecoins, 24/7 rails and non-custodial wallets collapse settlement windows; compliance must therefore shift from retrospective paperwork to pre-trade and in-flight controls.
- Regulators increasingly seek continuous assurance (proofs, logs and controls) versus annual screenshots.
3.2 Design Philosophy
Objective | Newton Protocol mechanism | Outcome |
---|---|---|
Security | Decentralized, but incentivized network of slashing-secured operators; tamper-evident Merkle logs | Integrity, accountability, recoverability |
Flexibility | Rego/DSL policies compiled to SP1 zkVM; hot-swappable policy versions | New rules without app redeploys |
Privacy | ZK & TEE based verifiable data oracles for private but compliance friendly audits | Minimum disclosure; GDPR-friendly |
Scalability | Off-chain evaluation + succinct proofs; batched verification; event-driven indexer | High TPS with bounded on-chain cost |
Efficiency | In-flight gatekeeping (no wasted gas), proof aggregation, cacheable oracle attestations | Low latency; predictable gas |
Compliance | Onchain ledger for protocol history at individual policy evaluation level | Continuous compliance, audit-ready using Newton Protocol explorer |
Decentralization | Operator set as AVS; permissionless verification; multi-chain composability | Avoids single-vendor choke points |
Composability | Any onchain transactions can be clients of Newton Policies by integrating Newton Policy Client contract | Plug-and-play across DeFi & fintech |
4. Architecture and Mechanism
Newton Protocol operates through a layered architecture. Policies are authored at the definition layer, enforced by decentralized operators at the validation layer and informed by data providers at the integration layer.
Policy Definition
Policies are expressed in high-level languages such as Rego or WASM, making them flexible, modular and updatable as regulations evolve. A policy can range from a simple jurisdiction filter to complex logic enforcing multiple simultaneous conditions.
Validation by Operators
A decentralized network of operators, secured by Ethereum restaking, evaluates transactions against Policies. Operators are economically bonded and subject to slashing for dishonest behavior. Their attestations serve as proof that a transaction has satisfied all relevant rules.
Data Providers
Policies are powered by oracles and services that supply the facts required for enforcement. These may include sanctions and AML lists, proof-of-reserves attestations, geolocation checks, investor accreditation credentials, or fraud detection signals.
Receipts and Zero-Knowledge Proofs
Every policy evaluation produces a cryptographic receipt that can be audited or streamed to regulators. When privacy is essential, zero-knowledge proofs confirm compliance without revealing the underlying credential or transaction metadata.
Together, these components create a verification infrastructure for programmable compliance, ensuring that every transaction is subject to rules that are live, transparent and auditable.
4.1 Components & Responsibilities
- Policy Engine: human-readable rules (e.g., “allow ≤ $5k/day to whitelist,” “block sanctioned/PEP,” “require travel-rule attestations above threshold”). Executed as onchain Newton Open Policy Agent DSL (Rego) or privacy preserving SP1 zkVM programs for verifiable evaluation.
- Newton Protocol Core Contracts (on-chain): receives transaction intents from apps; invokes policy evaluation; stores hash commitments to inputs/outputs and emits events.
- Operator Network (AVS): independent but incentivized operators fetch the task, run the policy evaluation with verifiable oracles in real-time, and produce (a) a succinct proof that the policy evaluation was correct and (b) a BLS quorum signature over the allowed intent.
- Network Consensus: verifies proofs, aggregates signatures and returns an Authorization Receipt.
- Oracle Adapter Layer: TEE-based real-time oracle layer to various onchain or offchain data sources for policy evaluations with verifiable proofs enabling Newton Policies to incorporate both onchain and offchain in a privacy-preserving but verifiable manner.
- Compliance Receipts & Log Vault: append-only, Merkle-addressable transcripts (policy version, inputs, proof hash, operator quorum ID), with optional encrypted payloads for regulators.

4.2 Policy Evaluation & Information Flow
- Submit Transaction: The application submits a request to the Newton AVS Task Manager containing the transaction intent
- Broadcast to Operators: The Task Manager (onchain) broadcasts policy evaluation request to the Operators
- Validate, Aggregate, & Sign: The Operators verify that the transaction adheres to the application’s policy, sign a response and submit the signed evaluated transaction intent to the Aggregator, who verifies and generates the final BLS signature signed policy evaluation result back to the Task Manager (onchain)
- Submit: The application interface nests the aggregated signatures into the transaction, signs the nested transaction and submits it onchain


4.3 Examples
Example Policy (Human-Readable Rego-Style)
Javascript
package newton.tx
default allow = false
allow {
input.sender in data.whitelist.addresses
input.amount <= data.limits.daily_remaining[input.sender]
not blacklist[input.recipient]
travel_rule_ok(input) # attested O/B data present for thresholded tx
kyc_ok(input.sender) # VC proof: KYC level >= 2
sanctions_clear(input) # oracle attestations fresh within SLA
risk_score(input) < 700 # model threshold (oracle/adapter)
}
Travel-Rule Payload (Selective Disclosure)
- Wallet presents zero-knowledge credentials proving “KYC-ed, not on sanctions list, ≥18” without revealing PII.
- An encrypted metadata blob (originator/beneficiary identifiers, reference IDs) is posted to a relay or stored off-chain; Newton Protocol binds its content hash to the transaction intent.
- Supervisors with keys can decrypt; the public chain sees only commitments and pass/fail attestations.
Example policy including Travel Rules, Sanctions and Limits
Javascript
package newton.travel
# Thresholds and adapters
threshold := 1000
max_daily := 5000
allow {
# Travel rule: for amounts above threshold, an encrypted TR payload must be present
input.amount <= threshold
} else {
input.travel_rule_hash != ""
tr_attested(input.travel_rule_hash) # relay attestation fresh
}
# Sanctions / PEP must be clear for both sides
not denied {
sanctioned(input.sender) # adapter: list_version >= required
}
not denied {
pep(input.recipient) # policy can permit with manual override token
}
# Dynamic daily limit
input.amount <= daily_remaining(input.sender, max_daily)
# Zero-knowledge proof of KYC level (no PII disclosed)
kyc_zk_ok(input.sender, level >= 2)
Execution Path (Happy Case)
- App constructs a transaction intent (target, value, calldata, travel-rule hash).
- Task Manager emits NewTaskCreated(id, intent, policyVersion).
- Operators evaluate policy and conduct consensus, during which the data oracle proofs are verified and make a quorum-based decision on the policy evaluation result, producing a succinct, multi-chain composable zero-knowledge proof + BLS partials.
- The Aggregator verifies the succinct proof and the aggregated signatures → responds to the final response with authorization receipt to Newton Protocol Core Contracts on the destination chains.
- App nests the authorization proof into the call and submits its corresponding Newton Policy Client contract to execute the authorized intent.
- At the time of execution of the intent, the proof is first verified , allowing the execution of the authorized intent.
4.4 Threats & Mitigations
- Stale/forged data: Oracle adapters include timestamped attestations; policies can encode max_age; receipts bind to hashes.
- Collusion/Byzantine operators: BLS quorum threshold + slashing + on-chain challenge window for fraud proofs.
- Data leakage: Only commitments and pass/fail results are public; PII sits in encrypted payloads or ZK credentials.
- Denial of service: Multiple operator clusters + fallback policy (e.g., lower limits) + rate-limited retries.
- Key compromise: Threshold BLS, hardware-backed keys and periodic key rotation baked into operator SLA.
4.5 Performance, Costs and Scaling Tactics
- Latency: Operator evaluation targets sub-second wall time for common policies; on-chain verification is one proof + one aggregated signature.
- Gas: Single succinct proof verification amortized across checks; oracle attestations cached by hash; receipts are compact.
- Throughput: Parallel operator execution; batch proofs for high-volume venues; L2-first deployment with L1 finalization.
- SLA: Policies can specify fallback states (e.g., “deny if adapters stale,” “allow ≤ $N pending adapter refresh”) to avoid halts.
4.6 Governance and Decentralization
- Operator selection: permissionless join with stake; performance-weighted selection; slashing on provable misbehavior.
- Quorums: Apps choose risk-graded quorums (e.g., ⅔ of “Retail” set vs. ¾ of “Institutional” set).
- Policy lifecycle: versioned; every receipt binds the policy hash + adapter versions; rollbacks and A/B policy tests supported.
- Transparency: public dashboards show policy hashes, adapter freshness and operator health, auditing by watching.
5. Key Applications
5.1 Institutional Applications
Newton Protocol’s utility is best understood through its applications across core institutional domains.
Stablecoins
Today, issuers depend on centralized KYC and post-facto monitoring. With Newton Protocol, stablecoin contracts can enforce compliance at the protocol level. Transfers can automatically block sanctioned wallets, restrict usage to certain jurisdictions and carry encrypted Travel Rule payloads. Every transaction becomes compliant at the point of execution, removing reliance on backend oversight.
Real-World Assets (RWAs)
Tokenized assets must respect real-world constraints such as investor eligibility, redemption windows and jurisdictional transfer rules. With Newton Protocol, these constraints are encoded directly into the token’s contract, allowing RWAs to remain composable within DeFi while preserving enforceability in traditional legal frameworks.
Institutional DeFi
Uniswap v4’s hook architecture allows custom logic at the pool level. Newton Protocol enables liquidity pools to incorporate institutional-grade controls, such as whitelisting accredited investors, applying dynamic rate limits, or running AML checks on counterparties. For the first time, institutional liquidity can participate in open, permissionless venues without abandoning regulatory safeguards.
Supervisory Oversight
Auditing today is retrospective and document-heavy. With Newton Protocol, regulators can subscribe to streams of cryptographic receipts proving that each transaction was evaluated against the relevant policies. Oversight becomes continuous, efficient and machine-readable.

5.2. AI Agents and Guardrails
The rise of autonomous AI agents introduces both opportunity and risk. Agents capable of transacting in crypto can execute strategies in real time, but they can also act unpredictably or maliciously. Researchers warn that access to cryptocurrency represents a dangerous capability for misaligned AI, creating vectors for fraud, manipulation, or uncontrolled resource accumulation.
Newton Protocol provides the guardrails for agentic finance. By embedding policies into AI-controlled wallets, Newton Protocol ensures that every action taken by an agent respects compliance and safety constraints. Spending limits can be enforced at the cryptographic level, destination addresses can be whitelisted or blacklisted, and behaviors can be rate-limited to prevent abuse. Zero-knowledge credentials allow agents to prove authorization without leaking sensitive information. Regulators can monitor agent activity through policy receipts, ensuring that supervision extends to the autonomous actors now entering financial markets.
In this way, Newton Protocol functions not only as compliance infrastructure for institutions but also securing the agentic economy, ensuring alignment, safety and trust.
6. Conclusion
Finance is moving from paperwork to programmable infrastructure. Compliance, once a reactive burden, is becoming an execution-time requirement. Just as smart contracts made execution programmable and oracles made data composable, policies enabling compliance-as-code are emerging as the next primitive, the critical foundation for institutions and AI agents entering programmable markets.
Newton Protocol provides this missing layer. By combining Ethereum’s restaked security, flexible policy languages, privacy-preserving zero-knowledge proofs and decentralized enforcement, Newton Protocol transforms compliance from a bottleneck into an enabler. Institutions reduce operational overhead while gaining safe access to DeFi and stablecoins. Regulators obtain a real-time, machine-readable, privacy-preserving view into financial activity. Users retain sovereignty without compromising safety. For AI, Newton Protocol introduces the guardrails that make autonomy safe: agents can act on behalf of users or organizations with cryptographic assurance that every action remains within defined policies.
Crucially, Newton Protocol preserves decentralization and composability. It does not dictate rules or act as a gatekeeper, but provides a neutral substrate where policies authored by institutions and regulators can be enforced in an open environment. This design protects the core ethos of public blockchains while unlocking institutional capital and extending trust to autonomous systems.
With the Newton Protocol, compliance is no longer a tax on innovation. It becomes programmable, verifiable and composable, the foundation for the next trillion dollars of onchain finance and the secure architecture for an agentic economy.
For developers building stablecoin, RWA or AI agent projects, sign up for the SDK
Note: Please reference this document for the Newton Protocol litepaper published April 27, 2025.