Skip to content

Instantly share code, notes, and snippets.

@denniswon
Created March 20, 2026 11:53
Show Gist options
  • Select an option

  • Save denniswon/3a69aa0a1860aba3060c7eb226e69e8a to your computer and use it in GitHub Desktop.

Select an option

Save denniswon/3a69aa0a1860aba3060c7eb226e69e8a to your computer and use it in GitHub Desktop.
Newton Protocol: Comprehensive Overview
---
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