The Problem
Institutions face barriers that retail users do not:- Regulatory requirements — mandated sanctions screening, transaction monitoring, and reporting
- Risk controls — exposure limits, counterparty restrictions, approved protocol lists
- Audit requirements — verifiable proof that every transaction was evaluated against compliance rules
- Operational security — multi-party authorization for large transactions, time-locked operations
- Fiduciary duty — fund managers must demonstrate that trades comply with investment mandates
How Newton Solves It
Newton inserts a policy evaluation step into every transaction. The policy is defined in Rego and evaluated by a decentralized network of EigenLayer operators. The result is a BLS attestation that proves the transaction was evaluated and approved.Exposure Limits
Approved Protocol Lists
Restrict interactions to audited, approved DeFi protocols:Transaction-Level Compliance
Combine sanctions screening, jurisdiction checks, and risk limits in a single policy:Architecture for Institutional Wallets
Compliance Patterns
| Pattern | Institutional need |
|---|---|
| Sanctions screening | Regulatory mandate for all financial transactions |
| Exposure limits | Per-protocol, per-asset, and aggregate position limits |
| Approved protocol lists | Only interact with audited DeFi protocols |
| Daily/weekly volume caps | Risk management and regulatory reporting thresholds |
| Multi-party authorization | Large transactions require multiple signers |
| Time-locked operations | Withdrawals above threshold require a delay period |
| Investment mandate compliance | Fund trades must align with stated strategy |
| Counterparty restrictions | Restrict interactions to known, verified counterparties |
Audit Trail
Every Newton policy evaluation produces an on-chain attestation — a BLS signature proving that the transaction was evaluated by the operator network and the result. This provides:- Verifiable compliance proof for regulators and auditors
- Immutable record of every policy decision
- Transparent rules — policies are content-addressed on IPFS and can be audited independently
Why Newton Over Centralized Compliance
| Centralized middleware | Newton Protocol | |
|---|---|---|
| Trust model | Trust the compliance vendor | Trust the math — cryptographic attestations |
| Availability | Single point of failure | Distributed EigenLayer operators |
| Auditability | Vendor-provided logs | On-chain attestations + IPFS-stored policies |
| Customization | Vendor-defined rules | Your own Rego policies |
| Latency | API round-trip | Sub-second (parallel evaluation) |
| Verifiability | ”Trust us” | BLS proofs verifiable by anyone |
Get Started
Quickstart
Simulate a compliance policy evaluation in 5 minutes
Write Compliance Policies
Author Rego rules for sanctions screening, exposure limits, and approved lists
Privacy Layer
Evaluate policies on encrypted data for confidential transactions