Skip to main content
Stablecoin issuers, payment processors, and tokenized asset platforms need transaction-level compliance without sacrificing speed or decentralization. Newton Protocol provides programmable policy enforcement that runs at the transaction layer — every transfer can be evaluated against configurable rules before execution.

​
The Problem

Payment and stablecoin protocols face competing demands:
  • Regulatory compliance — sanctions screening, jurisdiction checks, transfer limits
  • Fraud prevention — velocity checks, anomaly detection, blocklist enforcement
  • Speed — sub-second authorization decisions, not batch review
  • Decentralization — no single point of failure or censorship
Traditional approaches force a choice: either centralized compliance (a server that can block transfers) or no compliance at all. Newton removes this tradeoff by decentralizing the compliance decision.

​
How Newton Solves It

Newton evaluates every transaction against a Rego policy before it executes on-chain. The evaluation is performed by a decentralized network of EigenLayer operators, and the result is cryptographically attested via BLS signatures.

​
Sanctions Screening

A policy can call an external sanctions API via a WASM data oracle and block transfers involving sanctioned addresses: 
package newton

default allow = false

allow if {
    not data.data.is_sanctioned_sender
    not data.data.is_sanctioned_recipient
}

​
Transfer Limits

Enforce per-transaction or rolling-window spend limits without modifying your token contract: 
package newton

default allow = false

allow if {
    input.intent.value <= data.params.max_transfer_amount
}

cap := data.params.max_transfer_amount if {
    input.intent.value > data.params.max_transfer_amount
}

​
Jurisdiction Gating

Use oracle data to restrict transfers based on sender/recipient jurisdiction, enabling compliant cross-border payments.

​
Use Cases

ScenarioPolicy approach
Stablecoin issuer complianceSanctions screening + jurisdiction checks on every mint/transfer
Payment network authorizationPer-transaction limits + velocity checks + merchant allowlists
RWA token transfersAccredited investor verification + transfer restrictions
Cross-border remittanceCountry-level policy rules + amount thresholds
Card-to-crypto on-rampKYC status verification + daily limits

​
Architecture for Payment Protocols

The payment contract inherits from NewtonPolicyClient, which validates the attestation before executing the transfer. No off-chain server sits in the critical path.

​
Why Newton Over Centralized Compliance

Centralized serverNewton Protocol
Single point of failureYesNo — distributed operators
Censorship riskYes — operator can block arbitrarilyNo — policy rules are transparent and auditable
LatencyDepends on serverSub-second (parallel operator evaluation)
AuditabilityServer logs (opaque)On-chain attestations (verifiable)
CustomizationVendor-defined rulesYour own Rego policies

​
Get Started

Quickstart

Simulate a sanctions screening policy in 5 minutes

Write a Policy

Author Rego rules for transfer limits and compliance checks

Integrate Your Contract

Add NewtonPolicyClient to your payment or token contract