Created
March 20, 2026 11:53
-
-
Save denniswon/3a69aa0a1860aba3060c7eb226e69e8a to your computer and use it in GitHub Desktop.
Newton Protocol: Comprehensive Overview
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| --- | |
| Newton Protocol: Comprehensive Overview | |
| Vision | |
| Newton Protocol is the Authorization Layer for the Onchain Economy. Just as Visa authorizes payment transactions before settlement — | |
| checking fraud rules, verifying identity, enforcing spend limits in real time — Newton authorizes onchain transactions against | |
| programmable compliance and risk policies before they execute on any blockchain. | |
| The key insight: Newton is not another regulator, not another Visa-like centralized entity. It is credibly neutral infrastructure that | |
| uses blockchain as a coordination layer to automate policy enforcement. Decentralization comes "out of the box" by being an on-chain | |
| coordination layer — it's a property, not the pitch. | |
| --- | |
| The Problem Newton Solves | |
| 1. The Compliance Gap in Onchain Finance | |
| Onchain finance is growing rapidly — stablecoins exceed $298B in circulation with $700B+ monthly transfer volume, tokenized RWAs have | |
| crossed $21B — but the infrastructure to enforce compliance at the transaction level does not exist in a verifiable, decentralized form. | |
| Today's broken model: | |
| - UI-level controls are bypassable — sanctions screening in a frontend is trivially circumvented by interacting directly with the smart | |
| contract | |
| - Post-hoc monitoring is not enforcement — blockchain analytics flag transactions after funds have already moved | |
| - Centralized compliance is opaque — trusted intermediaries making decisions behind APIs, with no verifiable proof that policies were | |
| actually applied | |
| - Key compromise breaks everything — when a single private key controls asset operations, compromise bypasses all compliance logic | |
| The result: Onchain compliance is either centralized and opaque, or absent entirely. Neither satisfies institutional requirements. | |
| 2. The PII Data Burden | |
| Every application that needs to know something about its users (KYC status, identity verification, sanctions screening) must: | |
| - Store sensitive PII data in their own databases — a massive regulatory burden, licensing burden, and operational/financial burden | |
| - Duplicate KYC across applications — users re-do the same KYC on Lyft, Uber, Robinhood, Coinbase separately | |
| - Manage per-chain whitelists repetitively — the same allow-list replicated and maintained independently on every chain | |
| As Dennis put it in the VC overview meeting: "Blockchain is the next version of Internet where companies don't have to run their own | |
| server. Newton enables developers and businesses to not store private data of users on their own databases. You can delegate that to | |
| Newton in a decentralized way." | |
| 3. The AI Agent Risk | |
| Autonomous AI agents operating on crypto financial rails can initiate transactions at machine speed without human review. Without | |
| programmatic authorization guardrails, an AI agent with wallet access can execute transactions in sanctioned jurisdictions, interact with | |
| blacklisted addresses, or exceed velocity limits. The authorization layer for agent-initiated commerce cannot be a human approval queue | |
| — it must be programmatic, real-time, and verifiable. | |
| --- | |
| What Newton Does (Value Propositions) | |
| For Developers & Businesses | |
| ┌───────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ | |
| │ Value Prop │ Description │ | |
| ├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ No PII storage │ Developers never hold user private data in their own databases. Newton encrypts and manages it in a │ | |
| │ burden │ privacy-preserving, decentralized way — reducing regulatory, licensing, and operational costs │ | |
| ├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Verifiable, not │ Newton produces cryptographic attestations (BLS aggregate signatures backed by economic stake), not API │ | |
| │ advisory │ responses applications can ignore. Smart contracts require the attestation to execute │ | |
| ├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Automated │ Policies are programmable rules (authored in Rego/OPA) that automate sanctions screening, identity │ | |
| │ compliance │ verification, source-of-funds analysis, velocity limits, investor eligibility, and more │ | |
| ├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Cross-chain from │ A single policy configuration works across all EVM-compatible chains — no per-chain compliance fragmentation, │ | |
| │ day one │ no ecosystem lock-in │ | |
| ├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Credential reuse │ Users don't repeat KYC for every application. A credential verified once (e.g., via Persona) can be checked by │ | |
| │ │ any integrated developer — like how Google Sign-On works across apps │ | |
| ├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Credibly neutral │ No single entity controls Newton. An independent operator network validated through EigenLayer restaking means │ | |
| │ │ no vendor lock-in, no proprietary protocols. Applications retain full control of their policy logic │ | |
| └───────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ | |
| For Users | |
| ┌──────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ | |
| │ Value Prop │ Description │ | |
| ├──────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Privacy-preserving │ The blockchain sees proofs and attestations, never underlying identity data. Users maintain sovereignty │ | |
| │ │ over their credentials │ | |
| ├──────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Consent-based │ Data is only used with explicit user + developer bilateral consent (similar to Google Sign-On consent flow) │ | |
| │ sharing │ │ | |
| ├──────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ One-time KYC │ Submit identity data once, reuse across applications — no redundant verification │ | |
| ├──────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Data control │ Users can unlink applications, and credentials have expiration times for freshness guarantees │ | |
| └──────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ | |
| For Institutions | |
| ┌──────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ | |
| │ Value Prop │ Description │ | |
| ├──────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Audit-ready evidence │ Cryptographic proofs that policies were evaluated and satisfied — not just logs that monitoring was │ | |
| │ │ performed │ | |
| ├──────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Regulatory alignment │ Designed for GENIUS Act, MiCA, FATF Travel Rule, and Hong Kong Stablecoin Ordinance compliance requirements │ | |
| ├──────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Coordination without │ Banks and institutions that struggle to coordinate and trust each other can use Newton as neutral │ | |
| │ trust │ infrastructure — automated coordination without a central bank coordinator │ | |
| └──────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ | |
| --- | |
| How It Works (Simplified) | |
| Core Flow | |
| Developer registers policy → User submits data → Newton encrypts & stores privately | |
| → At transaction time, policy evaluates against encrypted data | |
| → Operators sign with BLS keys → Aggregated attestation produced | |
| → Smart contract requires attestation to execute | |
| Verifiable Credentials Flow | |
| 1. Registration: Developer collects user data (e.g., KYC from Persona) and submits via Newton SDK | |
| 2. User consent: A consent popup (hosted at id.newton.xyz — like Google Sign-On) appears. User reviews the data and clicks to encrypt | |
| 3. Encryption: Data is encrypted client-side. A data_ref_id (hash reference, NOT the data itself) is stored on-chain | |
| 4. Storage: Encrypted data is sharded across multiple node operators via threshold encryption — no single party can decrypt | |
| 5. Linking: Users can link additional application wallets to their master identity (bilateral commitment between user and developer) | |
| 6. Policy evaluation: At transaction time, data is threshold-decrypted only during policy evaluation, never exposed raw. Policies can | |
| check: is user over 18? Is KYC less than 48 hours old? Is user on a blacklist? Is passport valid for 2+ years? | |
| 7. Attestation: Operators evaluate the policy, sign with BLS keys, and produce an aggregated cryptographic attestation that the smart | |
| contract requires | |
| Privacy Architecture | |
| Newton does NOT store user PII in a centralized database that can be encrypted or decrypted by one entity. Instead: | |
| - Data is sharded and distributed across independent node operators | |
| - Threshold decryption means no single operator can access the data alone | |
| - Decryption happens only during policy evaluation, not at rest | |
| - The protocol produces proofs and attestations — the blockchain never sees raw identity data | |
| - This means no single regulator can go after any one operator — the decentralized architecture provides structural privacy protection | |
| --- | |
| Competitive Differentiation | |
| Five Pillars (from the marketing strategy discussion) | |
| ┌───────────────────┬──────────────────────────────────────────────────────────┬─────────────────────────────────────────────────────┐ | |
| │ Pillar │ Newton │ Traditional/Competitors │ | |
| ├───────────────────┼──────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────┤ | |
| │ Credible │ No single entity controls the network; independent │ Centralized vendors (single point of control), or │ | |
| │ Neutrality │ operator set via EigenLayer restaking │ permissioned chains (ecosystem lock-in) │ | |
| ├───────────────────┼──────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────┤ | |
| │ │ Data/identity privacy — private information stays │ Centralized compliance vendors see all data; │ | |
| │ Privacy │ private but verifiable on-chain. NOT transaction privacy │ on-chain whitelists expose user addresses publicly │ | |
| │ │ (like Tornado Cash) — identity and data privacy │ │ | |
| ├───────────────────┼──────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────┤ | |
| │ Transparency & │ Cryptographic attestations verifiable by anyone; │ Opaque API responses; compliance decisions behind │ | |
| │ Verifiability │ audit-ready proofs on-chain │ black boxes │ | |
| ├───────────────────┼──────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────┤ | |
| │ Automation │ Programmable Rego policies automate compliance checks at │ Manual compliance workflows; expensive human review │ | |
| │ │ transaction speed; no human-in-the-loop bottleneck │ processes │ | |
| ├───────────────────┼──────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────┤ | |
| │ Flexibility │ Multi-chain native — one policy, all chains; no │ Chainlink: broad reach but less neutral. │ | |
| │ (Cross-Chain) │ ecosystem lock-in; customers don't have to choose a │ Permissioned chains: locked to one ecosystem. Most │ | |
| │ │ single blockchain │ competitors: single-chain only │ | |
| └───────────────────┴──────────────────────────────────────────────────────────┴─────────────────────────────────────────────────────┘ | |
| vs. ZK-TLS / MPC-TLS | |
| Newton's approach is lighter and faster than ZK-TLS solutions: | |
| - ZK-TLS requires heavy ZK proof computation (costly, slower) | |
| - Newton uses threshold decryption + BLS signatures — same privacy guarantees, much faster | |
| - Newton uses ZK proofs only for challenge and slashing (the dispute path), not the happy path | |
| - Both handle the same underlying PII data — Newton's approach to data processing is actually stricter (threshold decryption vs. | |
| centralized attestation server) | |
| vs. Centralized Compliance Vendors | |
| - Centralized vendors produce API responses that applications can choose to ignore | |
| - Newton produces cryptographic attestations that smart contracts require at execution time | |
| - Centralized vendors are single points of failure and control; Newton is credibly neutral infrastructure | |
| vs. Permissioned Chains | |
| - Permissioned chains lock customers into one ecosystem | |
| - Newton is chain-agnostic — works across Ethereum, Base, Arbitrum, Solana (future), any EVM chain | |
| - Customers can leverage their existing infrastructure without migration | |
| --- | |
| Key Use Cases | |
| 1. Privacy-Preserving Compliance Whitelists (Current Pilot) | |
| RWA/stablecoin issuers replace on-chain whitelists (publicly visible, per-chain, manually managed) with Newton's cross-chain private | |
| allow-list. One whitelist for all chains, privacy-preserving, policy-engine checked. | |
| "Right now how it's being done is unimaginably [painful] — putting the whitelist on-chain, managing it repetitively for all chains." — | |
| Dennis, Marketing sync | |
| 2. Reusable KYC Credentials | |
| Applications check for existing verified credentials before requiring new KYC — like the Lyft/Uber analogy. Users do KYC once, reuse | |
| everywhere. Policies can enforce freshness (e.g., credential must be less than 48 hours old). | |
| 3. Shared Blacklists (Privacy-Preserving) | |
| Industries like online gambling (FanDuel, DraftKings, MGM) maintain separate problem-gambler blacklists they cannot share due to privacy | |
| regulations. Newton enables cross-checking against multiple blacklists without revealing the underlying PII — each company's list stays | |
| separate as a policy check, no data is cross-contaminated. | |
| 4. AI Agent Authorization | |
| Programmatic guardrails for autonomous AI agents operating on financial rails — spending limits, sanctions checks, velocity controls | |
| enforced at machine speed before transactions execute. | |
| 5. Institutional DeFi Access | |
| Banks and asset managers get compliance-grade infrastructure for participating in onchain lending, trading, and yield strategies — with | |
| audit-ready evidence for regulators. | |
| --- | |
| Market Positioning | |
| The On-Chain Economy Stack | |
| Newton occupies two critical layers in the emerging on-chain economy infrastructure: | |
| ┌────────────────────────────┬─────────────────────────────────────────────────────────┐ | |
| │ Layer │ Description │ | |
| ├────────────────────────────┼─────────────────────────────────────────────────────────┤ | |
| │ Application Layer │ DeFi, RWAs, Stablecoins, Payments, AI Agents │ | |
| ├────────────────────────────┼─────────────────────────────────────────────────────────┤ | |
| │ Newton Authorization Layer │ Policy evaluation, compliance enforcement, attestations │ | |
| ├────────────────────────────┼─────────────────────────────────────────────────────────┤ | |
| │ Newton Privacy Layer │ Identity privacy, data privacy, credential management │ | |
| ├────────────────────────────┼─────────────────────────────────────────────────────────┤ | |
| │ Settlement Layer │ Ethereum, Base, Arbitrum, Solana, etc. │ | |
| ├────────────────────────────┼─────────────────────────────────────────────────────────┤ | |
| │ Infrastructure │ EigenLayer, oracles, bridges │ | |
| └────────────────────────────┴─────────────────────────────────────────────────────────┘ | |
| Newton's privacy layer is specifically about data and identity privacy — not on-chain transaction privacy (which is what most people | |
| think of when they hear "privacy" in web3). This distinction is important for messaging. | |
| Target Audiences | |
| ┌──────────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────┐ | |
| │ Audience │ Message │ | |
| ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Crypto/DeFi developers │ Embed compliance without building a compliance team. One SDK, all chains │ | |
| ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Institutional/TradFi leaders │ Credibly neutral coordination layer — automated compliance without trusting a single intermediary │ | |
| ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ AI agent developers │ Programmatic authorization guardrails for autonomous financial agents │ | |
| ├──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤ | |
| │ RWA/Stablecoin issuers │ Replace per-chain whitelists with cross-chain private allow-lists │ | |
| └──────────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────┘ | |
| Messaging Guidelines (from marketing sync) | |
| - Lead with practical benefits, not "decentralization" — automation, privacy, credible neutrality, cross-chain flexibility | |
| - Replace "decentralized" with "credibly neutral" in customer-facing messaging — target customers don't want to feel like they're giving | |
| up control | |
| - "You don't have to choose" — a campaign theme around cross-chain flexibility (don't force customers to pick one blockchain) | |
| - Automation is the most practical value prop — institutions care about reducing manual compliance overhead | |
| - Privacy is a core requirement, not a feature — it's the engineering investment priority | |
| --- | |
| Key Numbers | |
| ┌─────────────────────────────────────────┬─────────────────────────────┐ | |
| │ Metric │ Value │ | |
| ├─────────────────────────────────────────┼─────────────────────────────┤ | |
| │ Stablecoin market cap │ $298B+ │ | |
| ├─────────────────────────────────────────┼─────────────────────────────┤ | |
| │ Monthly stablecoin transfer volume │ $700B+ │ | |
| ├─────────────────────────────────────────┼─────────────────────────────┤ | |
| │ Tokenized RWAs │ $21B+ │ | |
| ├─────────────────────────────────────────┼─────────────────────────────┤ | |
| │ Global financial crime compliance costs │ $206B/year │ | |
| ├─────────────────────────────────────────┼─────────────────────────────┤ | |
| │ Average institutional AML/KYC spend │ $72.9M/year per institution │ | |
| ├─────────────────────────────────────────┼─────────────────────────────┤ | |
| │ Challenge window │ 100 blocks │ | |
| ├─────────────────────────────────────────┼─────────────────────────────┤ | |
| │ Slashing penalty │ 10% of staked amount │ | |
| └─────────────────────────────────────────┴─────────────────────────────┘ | |
| --- | |
| Summary: Why Newton, Why Now | |
| 1. Regulatory crystallization — GENIUS Act, MiCA, FATF Travel Rule, HK Stablecoin Ordinance all demand enforceable transaction-level | |
| controls, not just onboarding checks | |
| 2. Institutional onchain adoption is real — the question shifted from "whether" to "which infrastructure." Newton is that infrastructure | |
| 3. AI agents need guardrails — autonomous financial agents operating at machine speed require programmatic, real-time, verifiable | |
| authorization | |
| 4. Privacy is non-negotiable — institutions won't put user data on public blockchains. Newton makes private data usable without exposing | |
| it | |
| 5. Cross-chain fragmentation is painful — managing compliance separately per chain is unsustainable. Newton abstracts it away | |
| 6. The compliance cost is massive — $206B/year globally. Verifiable automation can meaningfully reduce this | |
| Newton is not asking institutions to choose between compliance and decentralization. It provides the layer where both coexist — enforced | |
| by cryptographic proofs rather than trust in any single intermediary. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment