-
-
Save denniswon/e997c1073ad7af8c5521ed10b0ab787b to your computer and use it in GitHub Desktop.
| --- | |
| Rhinestone Chain Abstraction (Warp) — Technical Summary | |
| What It Is | |
| Rhinestone Warp is an intent-based cross-chain execution engine built on ERC-7579 smart account modules. Users express desired outcomes ("send 100 USDC | |
| from Optimism to Base and deposit into a vault"), and a competitive solver/relayer market fulfills them — handling bridging, swapping, and gas | |
| abstraction transparently. | |
| ★ Insight ───────────────────────────────────── | |
| 1. ERC-7683 standardization — Rhinestone implements the ERC-7683 cross-chain intent standard, which defines a generic order struct and settlement | |
| contract interface. This is the same standard that Across, UniswapX, and other intent protocols converge on. Newton's policy evaluation could validate | |
| ERC-7683 orders before they reach the solver market. | |
| 2. ERC-7579 modular accounts — The Intent Executor is installed as an ERC-7579 module on smart accounts. Newton could potentially ship as an adjacent | |
| ERC-7579 validator module that enforces policy checks before the Intent Executor fires. | |
| 3. Permit2-based signing — The EIP-712 signature scheme wraps PermitBatchWitnessTransferFrom with a nested Mandate struct. This means intent | |
| authorization is already structured data — perfect for Newton's Rego policy evaluation. | |
| ───────────────────────────────────────────────── | |
| Architecture Components | |
| ┌─────────────────────────┬─────────────────────────────────────────┬────────────────────────────────────────────────────────────────────────────────┐ | |
| │ Component │ Location │ Role │ | |
| ├─────────────────────────┼─────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Orchestrator │ Off-chain │ Routes intents, indexes balances, encodes transactions, enforces resource │ | |
| │ │ (v1.orchestrator.rhinestone.dev) │ locks, prevents double-spending │ | |
| ├─────────────────────────┼─────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Relayer/Solver Market │ Off-chain │ Competitive marketplace of solvers with cross-chain liquidity inventory │ | |
| ├─────────────────────────┼─────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Intent Router │ On-chain │ Entry point with dynamic dispatch adapters for multiple settlement layers │ | |
| ├─────────────────────────┼─────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Intent Executor │ On-chain (ERC-7579 module) │ Installed on smart accounts; handles destination chain execution + post-fill │ | |
| │ │ │ hooks │ | |
| ├─────────────────────────┼─────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────┤ | |
| │ Resource Locks (The │ On-chain (ERC-6909) │ Optional escrow-based token locking for deterministic settlement │ | |
| │ Compact) │ │ │ | |
| └─────────────────────────┴─────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────┘ | |
| Intent Lifecycle | |
| 1. Quote → POST /intents/route (get intentOp + cost + token requirements) | |
| 2. Prepare → Fulfill token requirements (ERC-20 approvals to Permit2, ETH→WETH wraps) | |
| 3. Sign → EIP-712 sign each element (per input chain), reuse final sig for destination | |
| 4. Submit → POST /intent-operations (signed intentOp → Orchestrator → solver market) | |
| 5. Fill → Solver fills on destination chain (tokens + calldata execution) | |
| 6. Claim → Origin chain settlement (repay solver via settlement layer) | |
| 7. Complete → Status transitions: PENDING → PRECONFIRMED → FILLED → CLAIMED → COMPLETED | |
| Each intent breaks into elements (one per input chain-token pair), each independently routable to different settlement layers. | |
| API Surface | |
| Base URL: https://v1.orchestrator.rhinestone.dev | |
| ┌────────────────────────────────────┬────────┬─────────────────────────────────────────────────────────────┐ | |
| │ Endpoint │ Method │ Purpose │ | |
| ├────────────────────────────────────┼────────┼─────────────────────────────────────────────────────────────┤ | |
| │ /intents/route │ POST │ Get quote — returns intentOp, intentCost, tokenRequirements │ | |
| ├────────────────────────────────────┼────────┼─────────────────────────────────────────────────────────────┤ | |
| │ /intent-operations │ POST │ Submit signed intent for execution │ | |
| ├────────────────────────────────────┼────────┼─────────────────────────────────────────────────────────────┤ | |
| │ /intent-operation/{id} │ GET │ Poll status (PENDING→COMPLETED lifecycle) │ | |
| ├────────────────────────────────────┼────────┼─────────────────────────────────────────────────────────────┤ | |
| │ /intents/split-intent-by-liquidity │ POST │ Split amounts based on solver liquidity │ | |
| ├────────────────────────────────────┼────────┼─────────────────────────────────────────────────────────────┤ | |
| │ /portfolio │ GET │ User token balances across all chains │ | |
| ├────────────────────────────────────┼────────┼─────────────────────────────────────────────────────────────┤ | |
| │ /withdrawals │ POST │ Batch/single withdrawal signatures │ | |
| └────────────────────────────────────┴────────┴─────────────────────────────────────────────────────────────┘ | |
| Auth: x-api-key header (testnets don't require a key). | |
| Key Data Structures | |
| Intent Route Request (the "quote"): | |
| { | |
| account: { address, accountType: "EOA"|"smartAccount"|"ERC7579", setupOps }, | |
| destinationChainId: 8453, // e.g. Base | |
| tokenRequests: [{ tokenAddress, amount }], | |
| destinationExecutions: [{ to, value, data }], // arbitrary calldata on dest chain | |
| destinationGasUnits: 500000, | |
| accountAccessList: { chainIds?, tokens?, chainTokens? }, // restrict funding sources | |
| options: { sponsorSettings: { gasSponsored, bridgeFeesSponsored, swapFeesSponsored } } | |
| } | |
| IntentOp Element (per input chain): | |
| { | |
| arbiter: address, | |
| chainId: number, | |
| idsAndAmounts: [{ id, amount }], // token ID = lowest 160 bits = token address | |
| mandate: { | |
| recipient, tokenOut, fillDeadline, | |
| destinationChainId, destinationOperations, | |
| originOperations | |
| }, | |
| qualifier: "ACROSS"|"ECO"|"RELAY"|"OFT"|"SAME_CHAIN"|"INTENT_EXECUTOR" | |
| } | |
| Settlement Layers | |
| ┌─────────────────┬─────────────────┬────────────────────────────────┐ | |
| │ Layer │ Type │ Notes │ | |
| ├─────────────────┼─────────────────┼────────────────────────────────┤ | |
| │ Across │ Bridge protocol │ Primary cross-chain settlement │ | |
| ├─────────────────┼─────────────────┼────────────────────────────────┤ | |
| │ Relay │ Fast relay │ Low-latency fills │ | |
| ├─────────────────┼─────────────────┼────────────────────────────────┤ | |
| │ Eco │ Intent network │ Alternative settlement │ | |
| ├─────────────────┼─────────────────┼────────────────────────────────┤ | |
| │ OFT │ LayerZero OFT │ Token-specific bridges │ | |
| ├─────────────────┼─────────────────┼────────────────────────────────┤ | |
| │ SAME_CHAIN │ Local │ No bridging needed │ | |
| ├─────────────────┼─────────────────┼────────────────────────────────┤ | |
| │ INTENT_EXECUTOR │ Module │ Direct smart account execution │ | |
| └─────────────────┴─────────────────┴────────────────────────────────┘ | |
| Supported Chains | |
| Mainnet (10): Ethereum (1), Base (8453), Optimism (10), Arbitrum (42161), Polygon (137), Avalanche (43114), Gnosis (100), Scroll (534352), BNB Chain | |
| (56), ZKsync Era (324) | |
| Testnet (9): Sepolia, Base Sepolia, OP Sepolia, Arb Sepolia, Polygon Amoy, Avalanche Fuji, Scroll Sepolia, BNB Testnet, ZKsync Sepolia | |
| EIP-712 Signing Scheme | |
| The signature wraps a Permit2 PermitBatchWitnessTransferFrom with a nested Mandate witness type. For multi-chain intents: | |
| - One signature per input chain element | |
| - Final signature is reused for destination chain validation | |
| - Domain separation ensures cross-chain safety | |
| - Qualifiers are keccak256-hashed before inclusion in typed data | |
| Smart Sessions (Policy Layer) | |
| Rhinestone has its own on-chain policy framework via Smart Sessions (ERC-7579 validator module): | |
| ┌────────────────┬────────────────────────────────────────────────┐ | |
| │ Policy Type │ Description │ | |
| ├────────────────┼────────────────────────────────────────────────┤ | |
| │ Sudo │ Unrestricted (no constraints) │ | |
| ├────────────────┼────────────────────────────────────────────────┤ | |
| │ Call │ Restrict by target address + function selector │ | |
| ├────────────────┼────────────────────────────────────────────────┤ | |
| │ Spending Limit │ Cap ERC-20 transfer/approve amounts │ | |
| ├────────────────┼────────────────────────────────────────────────┤ | |
| │ Timeframe │ Time-windowed access │ | |
| ├────────────────┼────────────────────────────────────────────────┤ | |
| │ Usage Limit │ Max transaction count │ | |
| ├────────────────┼────────────────────────────────────────────────┤ | |
| │ Value Limit │ Cap native ETH transfers │ | |
| └────────────────┴────────────────────────────────────────────────┘ | |
| Sessions combine Owners (ECDSA/multisig/passkey) + Actions (OR logic) + Policies (AND logic). | |
| Fee Structure | |
| - Core infra + SDK: Free, open source | |
| - Same-chain intents: No fee | |
| - Cross-chain: 3 bps during private beta | |
| - No API fee | |
| - Gas costs: Borne by client; solvers earn a small gas premium | |
| --- | |
| Integration Opportunities with Newton | |
| ★ Insight ───────────────────────────────────── | |
| 1. Newton as a pre-execution policy gate — Rhinestone's Orchestrator routes intents before solvers fill them. Newton could sit between the Orchestrator | |
| and the solver market, validating that each intent complies with policy (AML, spending limits, whitelisted counterparties) before it's broadcast. The | |
| destinationExecutions field (arbitrary calldata) is especially policy-relevant — it could encode DeFi interactions that need compliance checks. | |
| 2. Newton validator module for smart accounts — Rhinestone's Smart Sessions already has a policy framework, but it's limited to on-chain checks (spending | |
| limits, timeframes). Newton's Rego-based policies can express much richer logic (off-chain data, oracle feeds, identity checks) and provide BLS-attested | |
| proofs of compliance. A Newton ERC-7579 validator module could enforce policies that Smart Sessions can't express. | |
| 3. Overlapping chain coverage — Rhinestone supports all of Newton's target chains (Ethereum, Base, Optimism, Arbitrum, Polygon). Newton's multichain | |
| gateway architecture (Gateway::from_multi_chain_config()) already handles per-chain routing, which maps well to Rhinestone's per-chain intent elements. | |
| ───────────────────────────────────────────────── | |
| Concrete Integration Points | |
| ┌───────────────────────────┬─────────────────────────────────────────────────────────────────────────────────┬─────────────────────────────────────┐ | |
| │ Integration Point │ How It Works │ Newton Component │ | |
| ├───────────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────┤ | |
| │ Intent policy validation │ Orchestrator calls Newton RPC before routing to solvers │ Gateway (newt_createTask) │ | |
| ├───────────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────┤ | |
| │ Destination execution │ Validate destinationExecutions calldata against Rego policies │ Operator (policy eval + BLS sign) │ | |
| │ policy │ │ │ | |
| ├───────────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────┤ | |
| │ ERC-7579 validator module │ On-chain module that requires Newton attestation before Intent Executor fires │ Smart contract (new) │ | |
| ├───────────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────┤ | |
| │ Privacy-preserving │ HPKE-encrypt sensitive intent data (amounts, recipients), Newton decrypts for │ Privacy layer (existing) │ | |
| │ intents │ policy eval │ │ | |
| ├───────────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────┤ | |
| │ Cross-chain attestation │ Newton BLS attestation travels with the intent to destination chain via │ Transporter + │ | |
| │ │ Rhinestone's settlement │ BN254CertificateVerifier │ | |
| └───────────────────────────┴─────────────────────────────────────────────────────────────────────────────────┴─────────────────────────────────────┘ | |
| What Newton Adds That Rhinestone Doesn't Have | |
| ┌─────────────────────────────────────┬───────────────────────────┬──────────────────────────────────────────────────────┐ | |
| │ Capability │ Rhinestone Smart Sessions │ Newton │ | |
| ├─────────────────────────────────────┼───────────────────────────┼──────────────────────────────────────────────────────┤ | |
| │ Off-chain data in policies │ No │ Yes (WASM data providers, oracle feeds) │ | |
| ├─────────────────────────────────────┼───────────────────────────┼──────────────────────────────────────────────────────┤ | |
| │ Rich policy language │ Fixed policy types only │ Rego (arbitrary logic) │ | |
| ├─────────────────────────────────────┼───────────────────────────┼──────────────────────────────────────────────────────┤ | |
| │ Cryptographic attestation │ No (just on-chain checks) │ BLS aggregate signatures + optional ZK proofs │ | |
| ├─────────────────────────────────────┼───────────────────────────┼──────────────────────────────────────────────────────┤ | |
| │ Privacy-preserving evaluation │ No │ HPKE encryption + threshold decryption │ | |
| ├─────────────────────────────────────┼───────────────────────────┼──────────────────────────────────────────────────────┤ | |
| │ Cross-chain attestation portability │ No │ BN254 certificate verification on destination chains │ | |
| ├─────────────────────────────────────┼───────────────────────────┼──────────────────────────────────────────────────────┤ | |
| │ Challengeable results │ No │ 100-block challenge window + slashing │ | |
| └─────────────────────────────────────┴───────────────────────────┴──────────────────────────────────────────────────────┘ |
★ Insight ─────────────────────────────────────
Why x402 + Newton is a compelling wedge: x402 has 75M+ transactions but zero policy enforcement — agents pay whatever servers ask for. Newton is the
first protocol to add a cryptographic policy layer to x402 payments. The "Policy Session" design makes this practical: evaluate once, cache the BLS
attestation, reuse for N payments at <100ms. This makes policy-gated x402 payments latency-competitive with ungated ones.
The upto scheme is the sleeper feature — metered AI payments (LLM tokens, compute, bandwidth) are the highest-frequency x402 use case, and they map
perfectly to Newton's budget-tracking accumulator. An agent authorizes "up to $1" but gets charged $0.03 for actual usage, and the on-chain accumulator
tracks real spend, not worst-case authorizations.
─────────────────────────────────────────────────
Changes Made (v0.3 → v0.4)
┌────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Section │ Change │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 0.3 → 0.4 │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Competitive │ Fixed x402 description: wallet-agnostic, multi-chain (CAIP-2) — not custodial/Base-only │
│ table (1) │ │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Section 3.2 │ Rewrote x402 Auto-Pay with accurate v2 protocol flow (three-party model, PAYMENT-REQUIRED/PAYMENT-SIGNATURE headers, base64 │
│ Flow 1 │ JSON). Added Policy Session fast path (<100ms) vs slow path (~2-3s). Added latency breakdown. │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Section 5.2 │ Added "x402 upto (Metered Pay)" and "Policy Sessions" as Phase 1 features │
│ Feature Matrix │ │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Section 8 │ Added Phase 1 deliverables: Policy Sessions, x402 upto scheme, x402 MCP transport │
│ Roadmap │ │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Section 9 │ Refined x402 timing mitigations with maxTimeoutSeconds (60s), cached vs uncached latency │
│ Risks │ │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Open Question │ Expanded from brief question to recommended design with cross-reference to Appendix G │
│ #1 │ │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Appendix C │ Expanded from 7 bullet points to full x402 v2 reference: three-party model, payment schemes (exact/upto), HTTP/MCP/A2A │
│ │ transports, supported networks (CAIP-2), SDKs, key integration properties │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Appendix G │ Full x402 integration architecture with 8 sections: (1) Why x402 is the right primitive, (2) End-to-end flows with sequence │
│ (NEW, ~350 │ diagrams (same-chain + cross-chain), (3) Policy Sessions design (struct, two execution paths, on-chain accumulator, cache │
│ lines) │ invalidation, security tradeoffs, ERC-7715/7710 relation), (4) upto scheme for metered AI payments, (5) Cross-chain policy-aware │
│ │ chain selection, (6) MCP and A2A transport support, (7) Implementation phases, (8) x402-specific success metrics │
├────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Memory │ Updated newton-agent-account-prd.md with x402 integration context │
└────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
All three memory systems are now saved successfully.
Save status:
┌─────────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ System │ Status │ Details │
├─────────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Local │ Complete │ memory/newton-agent-account-prd.md + memory/MEMORY.md updated with v0.4 context │
│ memory │ │ │
├─────────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Supermemory │ Complete │ ID 9LEoCQMyX59DsaVN3bjpQY — PRD v0.4 with x402/Policy Sessions/integration models │
├─────────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Recall │ Complete │ 8 memories stored across newton-agent-account category — PRD overview, integration models, two-signature invariant, x402 │
│ │ │ architecture, Policy Sessions, upto scheme, smart account compatibility, roadmap │
└─────────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
★ Insight ─────────────────────────────────────
The three-tier memory strategy serves different recall patterns:
- Local memory (memory/*.md) loads automatically into every conversation context — best for quick-reference facts and file locations
- Supermemory provides semantic search across projects — useful when you ask "what did we decide about x402?" in a future session
- Recall offers structured categorized retrieval with importance ranking — the 8 entries are tagged by topic (x402, policy-sessions, rhinestone, etc.)
for precise future lookups
─────────────────────────────────────────────────
Your PRD v0.4 context is now fully persisted. The branch prd/agent-account-x402-integration is pushed to origin with commit 8045fd4b. You can pick up
from any of the next implementation steps documented in the PRD — Phase 0 M0.1 (NewtonValidatorModule.sol) being the first concrete deliverable.
★ Insight ─────────────────────────────────────
These two items are connected: the skill marketplace creates demand for x402 payments from agent fleets, and the Rego templates provide
the policy enforcement layer that makes those payments safe and controlled. Together they form a complete "payment + policy" loop that
demonstrates Newton Agent NeoBank's value proposition end-to-end.
─────────────────────────────────────────────────
- Skill Marketplace as a Phase 1/2 Use Case for Agent Fleets
The Problem It Solves for Newton
PRD A currently describes agent payment use cases somewhat generically — "agents pay for APIs, data, compute." The Unbrowse skill
marketplace gives us a concrete, already-being-built ecosystem where agents need exactly what Newton provides. This turns a theoretical
value prop into a tangible integration story.
How It Works
Unbrowse's marketplace is a directory of reverse-engineered web APIs packaged as "skills." Each skill is a structured bundle: OpenAPI
spec, TypeScript client, auth handling, quality metrics. Agents discover skills they need, pay via x402 ($0.005-$0.01 per execution), and
execute them.
Here's why this matters for Newton:
Without Newton: An agent with a raw EOA wallet pays for skills with no controls. If the agent gets prompt-injected, it drains the wallet
buying garbage skills. No spending visibility across a fleet. No quality enforcement. The operator has zero insight into what 100 agents
are purchasing.
With Newton Agent NeoBank: The operator deploys a vault with NewtonVaultModule. Each agent EOA has a policy slot in the vault. The
policies control:
┌──────────────────────────────┬─────────────────────────────────────────────────────┬───────────────────────────────────────────────┐
│ Policy Dimension │ Example Rule │ Enforcement │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Spending limit per skill │ Max $5/day on social media API skills │ NewtonVaultModule.sessionSpent accumulator │
│ domain │ │ │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Quality tier minimum │ Only Gold/Silver tier skills (>= 85% success rate) │ Rego policy reading ERC-8004 Reputation │
│ │ │ Registry │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Skill provider allowlist │ Only skills from verified publishers (Validation │ Rego policy reading ERC-8004 Validation │
│ │ Registry) │ Registry │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Per-agent budget allocation │ Trading bot agents get $50/day, social agents get │ Per-agent policy slots in vault │
│ │ $10/day │ │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Fleet-wide cap │ Total fleet spend on skill purchases <= $500/day │ Vault-level spending limit │
└──────────────────────────────┴─────────────────────────────────────────────────────┴───────────────────────────────────────────────┘
The Product Story
This gives Newton a reference use case for every section of the PRD:
- Fleet management: "Operator manages 50 agents, each autonomously purchasing API skills from marketplaces. The vault enforces per-agent
budgets and fleet-wide caps." - Policy Sessions: "Agent purchases the same Twitter API skill 200 times/day. First purchase gets full BLS attestation. Subsequent
purchases hit the Policy Session cache for sub-100ms authorization." This is where the sub-100ms latency target actually matters —
high-frequency micropayments. - ERC-8004 integration: The skill marketplace already uses ERC-8004 for skill provenance. Newton reads the same registries to make policy
decisions. No new infrastructure needed — both sides are already speaking ERC-8004. - x402 facilitator strategy: Skill marketplace purchases are the exact transaction type Newton's facilitator optimizes for — high volume,
low value, same-chain (Base), repeat patterns.
Where It Fits in the Roadmap
Phase 0: Not yet — Phase 0 is basic vault + factory + SDK + x402 handler. The marketplace integration doesn't need to be built, but the
infrastructure it would use is being built.
Phase 1: Natural fit. Phase 1 adds Policy Sessions (needed for high-frequency skill purchases), the self-hosted facilitator (needed for
batch settlement of micropayments), and ERC-8004 Reputation + Validation Registry reading. An Unbrowse integration demo at this point
would be a powerful proof-of-concept.
Phase 2: Platform partnerships. Unbrowse/OpenClaw is explicitly listed as an agent platform partner target. At this phase, Newton could
be the default payment infrastructure for the Unbrowse marketplace — every skill purchase goes through a Newton-attested policy check.
Why This Is Better Than Generic Examples
Current PRD A examples: "Agent pays for API call." "Agent buys compute."
With Unbrowse context: "An operator runs 50 web research agents. Each agent discovers and purchases API skills from a crowdsourced
marketplace. The vault enforces: (1) only Gold/Silver tier skills from verified publishers, (2) $10/day per agent, $200/day fleet-wide,
(3) no skills from domains on the operator's blocklist. When agent-23 gets prompt-injected and tries to buy 500 junk skills, the vault's
per-agent accumulator blocks it after $10. The operator sees the anomaly in fleet spend monitoring and revokes agent-23's session via the
MCP Server's revoke_session tool."
That's a story that sells. It demonstrates every piece of Newton's stack working together.
- Reputation-Aware Rego Policy Templates Consuming ERC-8004 Quality Tiers
The Connection
Unbrowse assigns quality tiers to skills based on runtime success rates:
┌──────────┬──────────────┬───────────────────────────┐
│ Tier │ Success Rate │ Marketplace Impact │
├──────────┼──────────────┼───────────────────────────┤
│ Gold │ >= 95% │ Featured, 1.5x visibility │
├──────────┼──────────────┼───────────────────────────┤
│ Silver │ >= 85% │ Standard, quality badge │
├──────────┼──────────────┼───────────────────────────┤
│ Bronze │ >= 70% │ Normal listing │
├──────────┼──────────────┼───────────────────────────┤
│ Unranked │ >= 50% │ Reduced visibility │
├──────────┼──────────────┼───────────────────────────┤
│ Poor │ < 50% │ Hidden, warning displayed │
└──────────┴──────────────┴───────────────────────────┘
These tiers are stored in ERC-8004's Reputation Registry — the same registry Newton already integrates with in PRD A Section 4.1.
Newton's Rego policy engine can read these on-chain reputation scores and enforce purchasing policies.
What This Looks Like in Practice
Newton's Rego policy templates (PRD A Section 4.3) currently describe three categories:
- Spending limits
- Recipient allowlists
- Chain restrictions
The Unbrowse paper suggests a fourth category: reputation-gated authorization. Here's how it works:
Template: Marketplace Quality Gate
package newton.policy.marketplace_quality
import future.keywords.in
Policy: Only allow payments to skill providers meeting quality threshold
default allow := false
allow {
# Check spending limit (existing template)
input.amount <= data.policy.max_per_transaction
# Check recipient is a skill marketplace (existing allowlist template)
input.recipient in data.policy.allowed_marketplaces
# NEW: Check skill provider's ERC-8004 reputation score
provider_reputation := data.erc8004.reputation[input.skill_provider_address]
provider_reputation.success_rate >= data.policy.min_quality_tier_threshold
# NEW: Check skill provider is in ERC-8004 Validation Registry
data.erc8004.validation[input.skill_provider_address].is_validated == true
}
Deny reason for observability
deny_reason := "skill provider below quality threshold" {
provider_reputation := data.erc8004.reputation[input.skill_provider_address]
provider_reputation.success_rate < data.policy.min_quality_tier_threshold
}
deny_reason := "skill provider not validated" {
not data.erc8004.validation[input.skill_provider_address].is_validated
}
Policy config (per agent or per vault):
{
"max_per_transaction": "0.05",
"allowed_marketplaces": ["0xUnbrowseMarketplace..."],
"min_quality_tier_threshold": 85,
"require_validation_registry": true
}
Why This Matters Architecturally
This is the first concrete example of ERC-8004 reputation as a Rego policy input — which is listed as a Phase 2 feature in PRD A's
roadmap. The Unbrowse paper provides the demand-side justification:
- Data source is already on-chain: ERC-8004 Reputation Registry stores success rates, accuracy, and freshness. Newton's data provider
(WASM execution) can fetch this data and feed it into the Rego evaluation context as data.erc8004.reputation. - Newton is already a Validation Registry provider: PRD A Section 4.1 positions Newton as a Validation Registry provider (one of
ERC-8004's three registries). This means Newton both writes validation attestations AND reads reputation scores. Closed loop. - Three trust tiers map to policy strictness:
┌──────────────────┬──────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────┐
│ Newton Trust │ ERC-8004 Source │ Rego Policy Behavior │
│ Tier │ │ │
├──────────────────┼──────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────┤
│ Reputation │ Reputation Registry (success rate, feedback score) │ Soft gate: allow if score >= threshold, warn │
│ │ │ otherwise │
├──────────────────┼──────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────┤
│ Crypto-economic │ Validation Registry (Newton BLS attestation) │ Hard gate: require Newton validation before payment │
├──────────────────┼──────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────┤
│ TEE │ Validation Registry (TEE attestation from Unbrowse Mode │ Maximum trust: allow higher spending limits │
│ │ B) │ │
└──────────────────┴──────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────┘
An operator could configure different agents with different trust tier requirements:
- Trading bot agents: require crypto-economic validation (high stakes)
- Social media agents: reputation tier sufficient (low stakes, high volume)
- Research agents: TEE validation for anything over $1 (sensitive data access)
The Feedback Loop
The most interesting part: Newton's policy decisions feed back into ERC-8004 reputation. If Newton attests that a skill provider's output
was valid (the policy evaluation succeeded), that attestation can be written to the Reputation Registry. Over time, Newton becomes a
reputation oracle — the more agents use Newton-attested skills, the better the reputation data becomes.
This is the Phase 2 feature "ERC-8004 reputation as Rego policy input" plus "agent platform partnerships" combined into one integration:
Agent purchases skill via x402
→ Newton Rego policy checks ERC-8004 reputation (read)
→ Payment authorized, skill executes
→ Newton attests execution result (write to Reputation Registry)
→ Next agent's policy check sees updated reputation
→ Virtuous cycle
Concrete Deliverables This Implies
Phase 1:
- newton.erc8004.reputation_score(address) — Rego extension function that reads from Reputation Registry
- newton.erc8004.is_validated(address) — Rego extension function that reads from Validation Registry
- 1-2 Rego policy templates: "marketplace quality gate" and "reputation-weighted spending limit"
- Data provider WASM plugin for ERC-8004 registry reads
Phase 2:
- Newton writes reputation attestations after successful policy evaluations
- Reputation score as a dynamic policy input (higher rep = higher spending limit)
- Cross-marketplace reputation aggregation (Unbrowse + other skill providers)
Bottom Line
The Unbrowse paper provides Newton with something the PRD currently lacks: a concrete end-to-end product scenario that exercises every
component of the stack simultaneously (vault, policy sessions, x402, ERC-8004, Rego templates, fleet management). Instead of describing
features in isolation, we can describe them as parts of one coherent workflow: "operator manages a fleet of agents that autonomously
discover, evaluate, purchase, and execute API skills from a crowdsourced marketplace, all under policy-controlled spending limits with
reputation-based quality gates."
That's the "Brex for AI agents" pitch made tangible.
★ Insight ─────────────────────────────────────
These two items are connected: the skill marketplace creates demand for x402 payments from agent fleets, and the Rego templates provide
the policy enforcement layer that makes those payments safe and controlled. Together they form a complete "payment + policy" loop that
demonstrates Newton Agent NeoBank's value proposition end-to-end.
─────────────────────────────────────────────────
- Skill Marketplace as a Phase 1/2 Use Case for Agent Fleets
The Problem It Solves for Newton
PRD A currently describes agent payment use cases somewhat generically — "agents pay for APIs, data, compute." The Unbrowse skill
marketplace gives us a concrete, already-being-built ecosystem where agents need exactly what Newton provides. This turns a theoretical
value prop into a tangible integration story.
How It Works
Unbrowse's marketplace is a directory of reverse-engineered web APIs packaged as "skills." Each skill is a structured bundle: OpenAPI
spec, TypeScript client, auth handling, quality metrics. Agents discover skills they need, pay via x402 ($0.005-$0.01 per execution), and
execute them.
Here's why this matters for Newton:
Without Newton: An agent with a raw EOA wallet pays for skills with no controls. If the agent gets prompt-injected, it drains the wallet
buying garbage skills. No spending visibility across a fleet. No quality enforcement. The operator has zero insight into what 100 agents
are purchasing.
With Newton Agent NeoBank: The operator deploys a vault with NewtonVaultModule. Each agent EOA has a policy slot in the vault. The
policies control:
┌──────────────────────────────┬─────────────────────────────────────────────────────┬───────────────────────────────────────────────┐
│ Policy Dimension │ Example Rule │ Enforcement │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Spending limit per skill │ Max $5/day on social media API skills │ NewtonVaultModule.sessionSpent accumulator │
│ domain │ │ │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Quality tier minimum │ Only Gold/Silver tier skills (>= 85% success rate) │ Rego policy reading ERC-8004 Reputation │
│ │ │ Registry │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Skill provider allowlist │ Only skills from verified publishers (Validation │ Rego policy reading ERC-8004 Validation │
│ │ Registry) │ Registry │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Per-agent budget allocation │ Trading bot agents get $50/day, social agents get │ Per-agent policy slots in vault │
│ │ $10/day │ │
├──────────────────────────────┼─────────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Fleet-wide cap │ Total fleet spend on skill purchases <= $500/day │ Vault-level spending limit │
└──────────────────────────────┴─────────────────────────────────────────────────────┴───────────────────────────────────────────────┘
The Product Story
This gives Newton a reference use case for every section of the PRD:
- Fleet management: "Operator manages 50 agents, each autonomously purchasing API skills from marketplaces. The vault enforces per-agent
budgets and fleet-wide caps." - Policy Sessions: "Agent purchases the same Twitter API skill 200 times/day. First purchase gets full BLS attestation. Subsequent
purchases hit the Policy Session cache for sub-100ms authorization." This is where the sub-100ms latency target actually matters —
high-frequency micropayments. - ERC-8004 integration: The skill marketplace already uses ERC-8004 for skill provenance. Newton reads the same registries to make policy
decisions. No new infrastructure needed — both sides are already speaking ERC-8004. - x402 facilitator strategy: Skill marketplace purchases are the exact transaction type Newton's facilitator optimizes for — high volume,
low value, same-chain (Base), repeat patterns.
Where It Fits in the Roadmap
Phase 0: Not yet — Phase 0 is basic vault + factory + SDK + x402 handler. The marketplace integration doesn't need to be built, but the
infrastructure it would use is being built.
Phase 1: Natural fit. Phase 1 adds Policy Sessions (needed for high-frequency skill purchases), the self-hosted facilitator (needed for
batch settlement of micropayments), and ERC-8004 Reputation + Validation Registry reading. An Unbrowse integration demo at this point
would be a powerful proof-of-concept.
Phase 2: Platform partnerships. Unbrowse/OpenClaw is explicitly listed as an agent platform partner target. At this phase, Newton could
be the default payment infrastructure for the Unbrowse marketplace — every skill purchase goes through a Newton-attested policy check.
Why This Is Better Than Generic Examples
Current PRD A examples: "Agent pays for API call." "Agent buys compute."
With Unbrowse context: "An operator runs 50 web research agents. Each agent discovers and purchases API skills from a crowdsourced
marketplace. The vault enforces: (1) only Gold/Silver tier skills from verified publishers, (2) $10/day per agent, $200/day fleet-wide,
(3) no skills from domains on the operator's blocklist. When agent-23 gets prompt-injected and tries to buy 500 junk skills, the vault's
per-agent accumulator blocks it after $10. The operator sees the anomaly in fleet spend monitoring and revokes agent-23's session via the
MCP Server's revoke_session tool."
That's a story that sells. It demonstrates every piece of Newton's stack working together.
- Reputation-Aware Rego Policy Templates Consuming ERC-8004 Quality Tiers
The Connection
Unbrowse assigns quality tiers to skills based on runtime success rates:
┌──────────┬──────────────┬───────────────────────────┐
│ Tier │ Success Rate │ Marketplace Impact │
├──────────┼──────────────┼───────────────────────────┤
│ Gold │ >= 95% │ Featured, 1.5x visibility │
├──────────┼──────────────┼───────────────────────────┤
│ Silver │ >= 85% │ Standard, quality badge │
├──────────┼──────────────┼───────────────────────────┤
│ Bronze │ >= 70% │ Normal listing │
├──────────┼──────────────┼───────────────────────────┤
│ Unranked │ >= 50% │ Reduced visibility │
├──────────┼──────────────┼───────────────────────────┤
│ Poor │ < 50% │ Hidden, warning displayed │
└──────────┴──────────────┴───────────────────────────┘
These tiers are stored in ERC-8004's Reputation Registry — the same registry Newton already integrates with in PRD A Section 4.1.
Newton's Rego policy engine can read these on-chain reputation scores and enforce purchasing policies.
What This Looks Like in Practice
Newton's Rego policy templates (PRD A Section 4.3) currently describe three categories:
- Spending limits
- Recipient allowlists
- Chain restrictions
The Unbrowse paper suggests a fourth category: reputation-gated authorization. Here's how it works:
Template: Marketplace Quality Gate
package newton.policy.marketplace_quality
import future.keywords.in
Policy: Only allow payments to skill providers meeting quality threshold
default allow := false
allow {
# Check spending limit (existing template)
input.amount <= data.policy.max_per_transaction
# Check recipient is a skill marketplace (existing allowlist template)
input.recipient in data.policy.allowed_marketplaces
# NEW: Check skill provider's ERC-8004 reputation score
provider_reputation := data.erc8004.reputation[input.skill_provider_address]
provider_reputation.success_rate >= data.policy.min_quality_tier_threshold
# NEW: Check skill provider is in ERC-8004 Validation Registry
data.erc8004.validation[input.skill_provider_address].is_validated == true
}
Deny reason for observability
deny_reason := "skill provider below quality threshold" {
provider_reputation := data.erc8004.reputation[input.skill_provider_address]
provider_reputation.success_rate < data.policy.min_quality_tier_threshold
}
deny_reason := "skill provider not validated" {
not data.erc8004.validation[input.skill_provider_address].is_validated
}
Policy config (per agent or per vault):
{
"max_per_transaction": "0.05",
"allowed_marketplaces": ["0xUnbrowseMarketplace..."],
"min_quality_tier_threshold": 85,
"require_validation_registry": true
}
Why This Matters Architecturally
This is the first concrete example of ERC-8004 reputation as a Rego policy input — which is listed as a Phase 2 feature in PRD A's
roadmap. The Unbrowse paper provides the demand-side justification:
- Data source is already on-chain: ERC-8004 Reputation Registry stores success rates, accuracy, and freshness. Newton's data provider
(WASM execution) can fetch this data and feed it into the Rego evaluation context as data.erc8004.reputation. - Newton is already a Validation Registry provider: PRD A Section 4.1 positions Newton as a Validation Registry provider (one of
ERC-8004's three registries). This means Newton both writes validation attestations AND reads reputation scores. Closed loop. - Three trust tiers map to policy strictness:
┌──────────────────┬──────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────┐
│ Newton Trust │ ERC-8004 Source │ Rego Policy Behavior │
│ Tier │ │ │
├──────────────────┼──────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────┤
│ Reputation │ Reputation Registry (success rate, feedback score) │ Soft gate: allow if score >= threshold, warn │
│ │ │ otherwise │
├──────────────────┼──────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────┤
│ Crypto-economic │ Validation Registry (Newton BLS attestation) │ Hard gate: require Newton validation before payment │
├──────────────────┼──────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────┤
│ TEE │ Validation Registry (TEE attestation from Unbrowse Mode │ Maximum trust: allow higher spending limits │
│ │ B) │ │
└──────────────────┴──────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────┘
An operator could configure different agents with different trust tier requirements:
- Trading bot agents: require crypto-economic validation (high stakes)
- Social media agents: reputation tier sufficient (low stakes, high volume)
- Research agents: TEE validation for anything over $1 (sensitive data access)
The Feedback Loop
The most interesting part: Newton's policy decisions feed back into ERC-8004 reputation. If Newton attests that a skill provider's output
was valid (the policy evaluation succeeded), that attestation can be written to the Reputation Registry. Over time, Newton becomes a
reputation oracle — the more agents use Newton-attested skills, the better the reputation data becomes.
This is the Phase 2 feature "ERC-8004 reputation as Rego policy input" plus "agent platform partnerships" combined into one integration:
Agent purchases skill via x402
→ Newton Rego policy checks ERC-8004 reputation (read)
→ Payment authorized, skill executes
→ Newton attests execution result (write to Reputation Registry)
→ Next agent's policy check sees updated reputation
→ Virtuous cycle
Concrete Deliverables This Implies
Phase 1:
- newton.erc8004.reputation_score(address) — Rego extension function that reads from Reputation Registry
- newton.erc8004.is_validated(address) — Rego extension function that reads from Validation Registry
- 1-2 Rego policy templates: "marketplace quality gate" and "reputation-weighted spending limit"
- Data provider WASM plugin for ERC-8004 registry reads
Phase 2:
- Newton writes reputation attestations after successful policy evaluations
- Reputation score as a dynamic policy input (higher rep = higher spending limit)
- Cross-marketplace reputation aggregation (Unbrowse + other skill providers)
Bottom Line
The Unbrowse paper provides Newton with something the PRD currently lacks: a concrete end-to-end product scenario that exercises every
component of the stack simultaneously (vault, policy sessions, x402, ERC-8004, Rego templates, fleet management). Instead of describing
features in isolation, we can describe them as parts of one coherent workflow: "operator manages a fleet of agents that autonomously
discover, evaluate, purchase, and execute API skills from a crowdsourced marketplace, all under policy-controlled spending limits with
reputation-based quality gates."
That's the "Brex for AI agents" pitch made tangible.
✻ Churned for 1m 21s
❯ https://paysponge.com/ this is a similar product to Newton Agent Neobank, although ours is fundamentally differentiated (Brex like
neobank for AI Agents) with Newton Policies as the main differentiator, I want to analyze/research into how this platform paysponge.com
provides AI gent native developer / user experience for their customers (such as Agent skills, MCP servers, SDKs, APIs, Claude/Claude
code/Openclaw plugin, etc. for example: https://paysponge.com/docs/claude-integration/. Use this as just one of the examples of
agent-native developer experience. After doing similar research on Agent-native developer experience/tools (skills, mcp, api, etc.),
include the most optimal developer experiences (by phases of execution) for customers of this Agent Neobank product in our PRD/tasks, etc.
⏺ ★ Insight ─────────────────────────────────────
PaySponge is a direct competitor in the "payments for AI agents" space. Understanding their developer experience gives us concrete
benchmarks for what Newton Agent NeoBank's agent-native DX should look like — and where Newton's policy layer creates differentiation.
─────────────────────────────────────────────────
Let me research PaySponge and the broader agent-native DX landscape in parallel.
⏺ 2 oh-my-claudecode:researcher agents finished (ctrl+o to expand)
├─ Research PaySponge agent DX · 10 tool uses · 75.3k tokens
│ ⎿ Done
└─ Research agent-native DX landscape · 78 tool uses · 98.3k tokens
⎿ Done
⏺ ★ Insight ─────────────────────────────────────
The research reveals a critical gap across the entire landscape: no platform has solved per-agent spend isolation with policy-based
authorization as a single primitive. PaySponge comes closest with SpongeAdmin fleet management + spending limits, but their controls are
purely numeric (daily/weekly/monthly caps) — no conditional logic, no on-chain enforcement, no reputation-based gating. This is exactly
where Newton's Rego policy engine + NewtonVaultModule creates structural differentiation.
─────────────────────────────────────────────────
Competitive DX Analysis: Agent-Native Payment Platforms
Landscape Summary
┌────────────────┬──────────────┬────────────────┬─────────────────────┬─────────┬─────────────────┬────────────────┬─────────────┐
│ Platform │ MCP │ SDK Languages │ Claude Plugin │ x402 │ Policy Layer │ Fleet Mgmt │ Identity │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ PaySponge │ 15 tools │ TS only │ Yes (MCP) │ No │ Numeric limits │ Yes │ No │
│ │ │ │ │ │ only │ (SpongeAdmin) │ │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ Coinbase │ Dynamic (50+ │ TS + Python │ Via MCP │ Yes │ No │ No │ No │
│ AgentKit │ actions) │ │ │ │ │ │ │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ Coinbase │ Via skills │ CLI-first │ Via MCP │ Yes │ Per-session │ No │ No │
│ Agentic Wallet │ │ │ │ │ caps │ │ │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ Stripe Agent │ 28 tools │ TS + Python │ Yes (native │ No │ Via Restricted │ No │ No │
│ Toolkit │ │ │ .claude-plugin) │ │ API Keys │ │ │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ x402 (raw) │ No │ TS + Python + │ No │ Yes │ No │ No │ No │
│ │ │ Go + Java │ │ (core) │ │ │ │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ Skyfire │ No │ TS + Python │ No │ No │ No │ No │ Yes (KYA) │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ Crossmint │ No │ REST-first │ No │ No │ No │ No │ No │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ Privy │ No │ REST + viem │ No │ No │ Yes (deepest) │ No │ No │
├────────────────┼──────────────┼────────────────┼─────────────────────┼─────────┼─────────────────┼────────────────┼─────────────┤
│ Newton Agent │ Planned (10 │ TS + Python │ Planned │ Yes │ Yes (Rego + │ Yes (vault) │ Yes │
│ NeoBank │ tools) │ (planned) │ │ (core) │ on-chain) │ │ (ERC-8004) │
└────────────────┴──────────────┴────────────────┴─────────────────────┴─────────┴─────────────────┴────────────────┴─────────────┘
PaySponge Deep Dive — What They Do Well
PaySponge is the most direct competitor. Their DX is polished:
-
MCP-first with inline embedding
// PaySponge's slickest pattern — MCP server embedded in Anthropic SDK call
const response = await anthropic.messages.create({
model: "claude-sonnet-4-20250514",
mcp_servers: { wallet: wallet.mcp() }
});
This is genuinely good DX. Zero external process, zero config files. The MCP server lives inside the SDK call. -
Under-5-minute onboarding: npm install → connect() → requestFaucet() → transfer(). Built-in testnet faucet means no hunting for test
tokens. -
SpongeAdmin fleet management: Programmatic agent creation, per-agent spending limits (6 time windows: per_transaction, per_minute,
hourly, daily, weekly, monthly), allowlist management, pause/resume, audit logs. -
Clean test/live separation: sponge_test_* vs sponge_live_* API keys, enforced at the API level.
-
15 MCP tools covering wallet, transfers, swaps, transactions, funding.
PaySponge's Gaps — Newton's Opportunity
┌──────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────────┐
│ PaySponge Gap │ Newton Differentiator │
├──────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ Numeric limits only (daily cap, per-tx limit) │ Rego policy engine: conditional logic, reputation-gated spending, │
│ │ category-based rules │
├──────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ No on-chain enforcement — all limits are API-level │ NewtonVaultModule: on-chain per-agent policy slots with BLS-attested │
│ (centralized) │ enforcement │
├──────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ No x402 — pure wallet-and-transfer model │ x402 native: HTTP 402 payment protocol for machine-to-machine commerce │
├──────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ No agent identity — agents are just API keys │ ERC-8004: on-chain identity with reputation and validation registries │
├──────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ Allowlist is mandatory — can't pay arbitrary │ Policy-controlled open spending: Rego rules decide at evaluation time, not │
│ counterparties │ via static allowlist │
├──────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ TypeScript only │ TS + Python SDKs planned │
├──────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ Custodial — keys in PaySponge infrastructure │ Non-custodial — Turnkey secure enclaves, operator controls keys │
├──────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ No cross-agent intelligence — each agent isolated │ Fleet-wide policy: shared vault budgets, cross-agent spending visibility │
└──────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────────┘
Best DX Patterns to Adopt (From Across the Landscape)
From PaySponge:
- Inline MCP embedding (wallet.mcp() inside Anthropic SDK call)
- Built-in testnet faucet in SDK
- SpongeAdmin-style fleet class with programmatic agent creation
- Clean test/live key prefix separation
From Stripe:
- Native .claude-plugin file for direct Claude Code integration (not just MCP)
- Remote MCP server with OAuth (no local credential management)
- search_documentation MCP tool — agent can self-service API questions
- Restricted API Keys as per-agent permission scoping
From Coinbase AgentKit:
- CLI scaffolding: npm create onchain-agent@latest (interactive project bootstrap)
- Dynamic MCP tool generation from action providers
- Multi-framework support (LangChain, Vercel AI, OpenAI Agents SDK, CrewAI, Pydantic AI)
From x402:
- HTTP-native payment primitive (wrap fetch with payment capability)
- Multi-language SDKs (TS, Python, Go, Java)
- Framework-specific middleware (@x402/express, @x402/hono, @x402/next)
From Privy:
- Deep policy engine (allowlisted contracts, transfer limits, M-of-N quorum)
- Transaction idempotency for agent reliability
- TEE key security with user-controlled export
Recommended Agent-Native DX for Newton Agent NeoBank — By Phase
Phase 0 (MVP)
Goal: A vibe coder can create a vault, register an agent, and make a policy-controlled x402 payment in under 5 minutes.
┌────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────┬──────────┐
│ Interface │ Deliverable │ Priority │
├────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┼──────────┤
│ TypeScript SDK │ @newton/agent-sdk with NewtonVault and NewtonAdmin classes │ P0 │
├────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┼──────────┤
│ CLI │ npx newton-agent init — interactive project bootstrap (like AgentKit's npm create onchain-agent) │ P0 │
├────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┼──────────┤
│ MCP Server │ @newton/mcp — 10 core tools via npx @newton/mcp --api-key KEY │ P0 │
├────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┼──────────┤
│ REST API │ Base URL + OpenAPI spec for all vault/agent/policy operations │ P0 │
├────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┼──────────┤
│ Testnet faucet │ Built into SDK: vault.requestFaucet({ chain: "base-sepolia" }) │ P0 │
└────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────┴──────────┘
SDK design (learning from PaySponge's two-class pattern):
// === NewtonAdmin — fleet management (like SpongeAdmin) ===
import { NewtonAdmin } from "@newton/agent-sdk";
const admin = NewtonAdmin.fromMasterKey(process.env.NEWTON_MASTER_KEY);
// Create vault (one per operator)
const vault = await admin.createVault({
chain: "base-sepolia",
testnet: true,
});
// Register agent EOA in vault with policy
const agent = await admin.registerAgent(vault.address, {
name: "Research Bot Alpha",
eoa: "0xAgentAddress", // or auto-generate via Turnkey
policy: {
dailyLimit: "50.0",
perTransactionLimit: "5.0",
allowedRecipients: ["0xUnbrowseMarketplace"],
// Newton differentiator: Rego policy template
regoTemplate: "marketplace_quality_gate",
regoParams: {
minReputationScore: 85,
allowedCategories: ["api_skill", "data_feed"],
},
},
});
// === NewtonVault — agent-facing operations ===
const wallet = NewtonVault.fromAgentKey(agent.sessionKey);
// x402 payment (Newton differentiator — not in PaySponge)
const response = await wallet.x402Fetch("https://api.weather.com/forecast", {
maxAmount: "0.01",
currency: "USDC",
});
// Standard transfer
const tx = await wallet.transfer({
to: "0xRecipient",
amount: "10.0",
currency: "USDC",
});
MCP Server tools (Phase 0 — 10 tools):
┌────────────────────┬───────────────────────────────────────────────┬────────────────────────────────────────┐
│ Tool │ Description │ Equivalent in PaySponge │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ create_vault │ Deploy operator vault on-chain │ No equivalent (PaySponge is custodial) │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ register_agent │ Add agent EOA to vault with policy slot │ createAgent (SpongeAdmin) │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ update_policy │ Modify agent's Rego policy params │ setSpendingLimit (numeric only) │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ get_fleet_spend │ Vault-wide spending breakdown by agent │ No equivalent │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ get_agent_spend │ Per-agent spending history + remaining budget │ Partial (get_transaction_history) │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ revoke_session │ Invalidate agent's Turnkey session key │ pauseAgent │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ emergency_shutdown │ Revoke all sessions + disable vault │ No equivalent │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ list_agents │ List agents registered in vault with status │ listAgents │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ create_session │ Generate new Turnkey session key for agent │ rotateAgentKey │
├────────────────────┼───────────────────────────────────────────────┼────────────────────────────────────────┤
│ rotate_key │ Rotate agent's underlying Turnkey key │ rotateAgentKey │
└────────────────────┴───────────────────────────────────────────────┴────────────────────────────────────────┘
CLI (npx newton-agent):
Interactive bootstrap (like AgentKit's scaffolding)
npx newton-agent init
→ Choose: TypeScript / Python
→ Choose: Base Sepolia (testnet) / Base (mainnet)
→ Choose: New Turnkey wallet / Existing EOA
→ Generates: project with vault setup, agent registration, first x402 payment
Fleet management
npx newton-agent vault create --chain base-sepolia
npx newton-agent agent register --vault 0x... --name "Bot Alpha" --policy marketplace_quality_gate
npx newton-agent agent list --vault 0x...
npx newton-agent agent spend --vault 0x... --agent 0x...
npx newton-agent agent revoke --vault 0x... --agent 0x...
npx newton-agent agent emergency-shutdown --vault 0x...
Policy management
npx newton-agent policy list-templates
npx newton-agent policy apply --vault 0x... --agent 0x... --template spending_limit --params '{"daily": "50.0"}'
Test/live separation (adopting PaySponge's pattern):
- newton_test_* — testnet keys (Base Sepolia), no mainnet access
- newton_live_* — mainnet keys (Base), requires approval
- Enforced at SDK and API level
Phase 1 (Production)
Goal: Full fleet management, self-hosted facilitator, Policy Sessions, multi-framework support.
┌──────────────────────┬─────────────────────────────────────────────────────────────────────────┬──────────┐
│ Interface │ Deliverable │ Priority │
├──────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┤
│ Python SDK │ newton-agent-sdk (pip) — feature parity with TS │ P0 │
├──────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┤
│ Claude Code plugin │ .claude-plugin file (like Stripe) for direct IDE integration │ P0 │
├──────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┤
│ OpenClaw plugin │ Extension for OpenClaw agent framework │ P0 │
├──────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┤
│ Inline MCP │ vault.mcp() embeddable in Anthropic SDK calls (like PaySponge) │ P1 │
├──────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┤
│ Framework adapters │ LangChain, Vercel AI SDK, CrewAI, Pydantic AI │ P1 │
├──────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┤
│ search_docs MCP tool │ Agent can query Newton docs (like Stripe's search_stripe_documentation) │ P1 │
├──────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┤
│ Dashboard API │ Fleet spend analytics, agent health, policy violation alerts │ P2 │
└──────────────────────┴─────────────────────────────────────────────────────────────────────────┴──────────┘
New MCP tools (Phase 1 additions):
┌──────────────────────┬──────────────────────────────────────────────────────────────┐
│ Tool │ Description │
├──────────────────────┼──────────────────────────────────────────────────────────────┤
│ x402_pay │ Make x402 payment through vault policy │
├──────────────────────┼──────────────────────────────────────────────────────────────┤
│ get_policy_templates │ List available Rego policy templates │
├──────────────────────┼──────────────────────────────────────────────────────────────┤
│ get_agent_reputation │ Query ERC-8004 reputation for an address │
├──────────────────────┼──────────────────────────────────────────────────────────────┤
│ check_policy │ Dry-run a payment against agent's policy (without executing) │
├──────────────────────┼──────────────────────────────────────────────────────────────┤
│ get_vault_health │ Vault balance, active agents, policy violation count │
├──────────────────────┼──────────────────────────────────────────────────────────────┤
│ search_newton_docs │ Agent self-service documentation queries │
└──────────────────────┴──────────────────────────────────────────────────────────────┘
Claude Code plugin (.claude-plugin):
{
"name": "Newton Agent NeoBank",
"description": "Manage AI agent payment vaults with policy controls",
"mcp": {
"command": "npx",
"args": ["@newton/mcp", "--api-key", "${NEWTON_API_KEY}"]
}
}
Inline MCP pattern (from PaySponge, enhanced):
import { NewtonVault } from "@newton/agent-sdk";
import Anthropic from "@anthropic-ai/sdk";
const vault = NewtonVault.fromAgentKey(process.env.AGENT_SESSION_KEY);
const anthropic = new Anthropic();
// Embed Newton MCP server directly in Claude call
const response = await anthropic.messages.create({
model: "claude-sonnet-4-20250514",
messages: [{ role: "user", content: "Buy the Twitter API skill from the marketplace" }],
mcp_servers: {
newton: vault.mcp({
// Newton differentiator: policy-filtered tool exposure
allowedTools: ["x402_pay", "get_agent_spend", "check_policy"],
policySession: true, // Enable sub-100ms cached attestations
}),
},
});
Framework adapters (Phase 1):
// LangChain
import { NewtonToolkit } from "@newton/langchain";
const tools = new NewtonToolkit({ vault }).getTools();
// Vercel AI SDK
import { newtonTools } from "@newton/vercel-ai";
const result = await generateText({
model: openai("gpt-4o"),
tools: newtonTools({ vault }),
});
// CrewAI (Python)
from newton_agent_sdk.crewai import NewtonTools
tools = NewtonTools(vault=vault).get_tools()
Phase 2 (Platform)
Goal: Ecosystem integrations, advanced policy features, marketplace support.
┌───────────────────────────────┬──────────────────────────────────────────────────────────┬──────────┐
│ Interface │ Deliverable │ Priority │
├───────────────────────────────┼──────────────────────────────────────────────────────────┼──────────┤
│ Agent platform partnerships │ AutoGPT, CrewAI, LangChain, OpenClaw native integrations │ P0 │
├───────────────────────────────┼──────────────────────────────────────────────────────────┼──────────┤
│ Skill marketplace integration │ Unbrowse/similar marketplace as payment destination │ P1 │
├───────────────────────────────┼──────────────────────────────────────────────────────────┼──────────┤
│ Reputation-aware policies │ ERC-8004 reputation as live Rego policy input │ P1 │
├───────────────────────────────┼──────────────────────────────────────────────────────────┼──────────┤
│ Multi-language SDKs │ Go, Rust SDKs for non-JS/Python stacks │ P2 │
├───────────────────────────────┼──────────────────────────────────────────────────────────┼──────────┤
│ White-label SDK │ Rebrandable SDK for agent platforms │ P2 │
├───────────────────────────────┼──────────────────────────────────────────────────────────┼──────────┤
│ A2A transport │ Agent-to-Agent payment protocol support │ P2 │
└───────────────────────────────┴──────────────────────────────────────────────────────────┴──────────┘
Reputation-aware Rego template (Phase 2):
package newton.policy.reputation_weighted_limit
Dynamic spending limit based on counterparty reputation
max_amount := 5.0 {
data.erc8004.reputation[input.recipient].score >= 95 # Gold tier
}
max_amount := 1.0 {
data.erc8004.reputation[input.recipient].score >= 85 # Silver tier
}
max_amount := 0.1 {
data.erc8004.reputation[input.recipient].score >= 70 # Bronze tier
}
max_amount := 0 {
data.erc8004.reputation[input.recipient].score < 70 # Deny
}
Newton vs PaySponge — DX Comparison After Implementation
┌─────────────────────────┬────────────────┬───────────────────────────┬──────────────────────────────┐
│ DX Dimension │ PaySponge │ Newton (Phase 0) │ Newton (Phase 1) │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ Time to first payment │ ~5 min │ ~5 min │ ~3 min (CLI scaffold) │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ MCP tools │ 15 │ 10 │ 16+ │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ SDK languages │ TS │ TS │ TS + Python │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ Claude Code integration │ Via MCP │ Via MCP │ Native .claude-plugin │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ Fleet management │ SpongeAdmin │ NewtonAdmin CLI + SDK │ + dashboard API │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ Policy controls │ Numeric limits │ Rego templates + on-chain │ + reputation-aware │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ x402 payments │ No │ Yes (core) │ + Policy Sessions │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ Agent identity │ No │ ERC-8004 │ + reputation feedback │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ Non-custodial │ No (custodial) │ Yes (Turnkey) │ + threshold keys │
├─────────────────────────┼────────────────┼───────────────────────────┼──────────────────────────────┤
│ Framework support │ Anthropic only │ Anthropic │ LangChain, Vercel AI, CrewAI │
└─────────────────────────┴────────────────┴───────────────────────────┴──────────────────────────────┘
The key takeaway: PaySponge has shipped a polished DX layer on top of a simple custodial wallet model. Newton's DX should match their
polish (MCP-first, under-5-min onboarding, clean test/live separation) while layering on the structural differentiators that PaySponge
can't replicate without a fundamental architecture change: Rego policies, on-chain enforcement, ERC-8004 identity, x402 native payments,
and non-custodial key management.
PRD grew from ~1430 to 1629 lines (~200 lines of DX content added). All three sections are complete:
★ Insight ─────────────────────────────────────
- Section 7.1 (Agent-Native DX): Expanded from a simple interface table to a comprehensive DX specification with CLI scaffolding (npx
newton-agent init), inline MCP embedding, Claude Code .claude-plugin, framework adapters (LangChain/Vercel AI/CrewAI), search_docs RAG
tool, test/live key separation, and NewtonAdmin fleet management class. Each pattern is sourced from a proven competitor (PaySponge,
Stripe, AgentKit) but adapted for Newton's policy-first architecture. - Section 8 (Roadmap): Phase 0 grew from 8 to 13 deliverables — adding CLI scaffolding (M0.4), MCP server with inline embedding (M0.6),
testnet faucet + API key separation (M0.9), and docs search tool (M0.10). Phase 1 adds Python SDK, Claude Code plugin, OpenClaw plugin,
framework adapters, remote MCP server, and inline MCP embedding. Phase 2 adds multi-language SDKs (Go, Rust), agent platform partnerships
as co-marketed launches, and web dashboard as a nice-to-have. - Section 10 (Metrics): New "Developer Experience Metrics" table with 11 metrics across all phases — scaffold creation rate,
time-to-first-payment, SDK downloads (npm + PyPI), MCP tool invocations, inline embedding adoption %, Claude Code plugin installs,
framework adapter usage, docs search queries, REST API active keys, and testnet faucet requests.
─────────────────────────────────────────────────
The competitive DX research is now fully incorporated into PRD A. The key differentiator across all DX surfaces: every interface (CLI,
SDK, MCP, Claude Code plugin, framework adapter) converges on the same Rego policy engine + on-chain BLS enforcement pipeline.
Competitors offer convenience (PaySponge's inline MCP, AgentKit's scaffolding) or breadth (Stripe's docs tool), but none combine
policy-based authorization with fleet management as a single primitive.
★ Insight ─────────────────────────────────────
Effective BD outreach on Telegram needs to be:
- Short — Telegram is a chat medium, not email. Wall of text = ignored.
- Tailored hook — Show you understand their product before pitching yours.
- One clear CTA — Link to the one-pager or a call, not both.
─────────────────────────────────────────────────
Here are three tailored drafts — one per prospect type. Adapt the tone/details as needed.
- For Virtuals Protocol (agent launchpad/marketplace)
Hey team — Dennis from Newton Protocol.
We've been watching what you're building with Agent Commerce Protocol — autonomous agent-to-agent commerce is exactly where this space is
heading.
One thing we keep hearing from agent platforms: once agents start transacting autonomously, there's no spending controls. A compromised
agent with wallet access is an open ATM.
We built Newton Agent NeoBank — non-custodial, policy-controlled payment accounts for agent fleets. Operators deploy one vault, set
per-agent spending limits and allowlists, and agents pay autonomously via x402. Every payment is BLS-attested by EigenLayer operators.
Sub-250ms cached payments after the first one.
Think Brex for AI agents — but on-chain, non-custodial, and with cryptographic compliance proofs.
Dropped a one-pager here: [link]
Would love to explore what an integration looks like for Virtuals agents. Open to a quick call this week?
- For Bankr.bot (AI agent finance)
Hey — Dennis from Newton Protocol.
We're building in the same space — payment infrastructure for AI agents. Curious what you're seeing on the policy/controls side.
We built Newton Agent NeoBank: non-custodial payment accounts where operators set per-agent spending policies (daily limits, recipient
allowlists, chain restrictions) enforced on-chain via BLS attestations from EigenLayer operators. Agents pay autonomously via x402 —
sub-250ms for cached payments. Privacy-preserving compliance built in (threshold decryption, encrypted policy data — sensitive inputs
never touch the chain).
One-pager: [link]
Would be great to compare notes. Open to a chat this week?
- For Coinbase Developer Platform / Agentic Wallets team
Hey team — Dennis from Newton Protocol.
We've been following the Agentic Wallets launch — great to see Coinbase pushing the agent payments space forward.
We've taken a different approach with Newton Agent NeoBank: non-custodial (agents hold their own keys via Turnkey enclaves, not TEE),
with programmable policy enforcement backed by EigenLayer economic security. Every payment gets a BLS attestation from decentralized
operators — on-chain verifiable compliance proofs, not trust-the-enclave.
We're x402 native (both exact and upto schemes), with fleet management for operators running 10-1000 agents: one vault, per-agent
budgets, policy sessions for sub-250ms payments, ERC-8004 agent identity, and privacy-preserving compliance via threshold decryption.
One-pager: [link]
Think there's an interesting conversation around how Newton's policy layer could complement Coinbase's x402 facilitator infrastructure.
Open to exploring?
Generic template (for any agent platform / prospect)
Hey — Dennis from Newton Protocol.
We built Newton Agent NeoBank — non-custodial, policy-controlled payment accounts for AI agent fleets.
The problem: agents need to pay for APIs, data, and compute autonomously, but there's no spending controls. A prompt-injected agent with
wallet access is an open ATM.
Our approach: operators deploy one vault, set per-agent policies (spending limits, allowlists), and agents auto-pay via x402. Every
payment is cryptographically attested by EigenLayer operators. Sub-250ms cached payments. Privacy-preserving compliance built in.
One-pager: [link]
Happy to walk through how this could plug into what you're building. Open to a quick call?
★ Insight ─────────────────────────────────────
Key differences across the three:
- Virtuals: Lead with their ACP product, position Newton as the missing policy/controls layer for their agent economy
- Bankr.bot: Peer-to-peer tone ("same space"), lead with technical differentiation (threshold decryption, BLS attestation)
- Coinbase: Respectful positioning against their TEE model, frame Newton as complementary to their x402 facilitator rather than
competitive
─────────────────────────────────────────────────
what is the benefit of using ERC 7579, specifically for our use case? and why did you/we decide to implement using ERC 4337 smart
accounts? What are pros vs cons of implementing as a smart account vs just a vault contract?
⏺ Great question — this is worth revisiting critically before writing any code. Let me trace the actual payment flow to see where
ERC-4337/7579 fits (or doesn't).
The actual x402 settlement flow
Agent (EOA) → HTTP 402 → signs payment → Facilitator verifies → settles on-chain
The key question is: who calls the vault contract to release funds?
Path A: ERC-4337 Smart Account vault
Agent constructs UserOp → Bundler → EntryPoint → Vault Account → NewtonVaultModule validates → transfer
Path B: Minimal vault contract
x402 Facilitator calls vault.settle(recipient, amount, blsAttestation, agentSig) → vault validates → transfer
Why ERC-7579/4337 was in the PRD
The PRD positioned the vault as an ERC-7579 smart account because:
- Modularity narrative — "install NewtonVaultModule like any other module"
- Ecosystem composability — operator could add recovery, multisig, timelock modules later
- Standards alignment — ERC-7579 is the modular account standard, looks good in a PRD
- Rhinestone module registry — discoverability (though PRD A explicitly doesn't use Rhinestone)
The honest tradeoff for our use case
┌──────────────────────────────┬───────────────────────────────────────────────────────────────────┬──────────────────────────────────┐
│ Dimension │ ERC-7579 Smart Account │ Minimal Vault Contract │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ Who submits the tx? │ Bundler (via UserOp) │ x402 Facilitator (direct call) │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ Gas overhead │ ~40-50k extra for EntryPoint validation │ None — direct function call │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ Infrastructure needed │ Bundler + EntryPoint + Paymaster │ Just the vault contract │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ Deployment cost │ Higher (account + module installation) │ Lower (single contract) │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ Audit surface │ EntryPoint + Account impl + Module │ Just the vault │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ Debug complexity │ EntryPoint → Account → Module → Validation │ vault.settle() → done │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ Time to build │ Need to integrate with Kernel/Safe/Nexus, learn their module APIs │ Write exactly what we need │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ Future modularity │ Add modules later without redeployment │ Custom upgrades only │
├──────────────────────────────┼───────────────────────────────────────────────────────────────────┼──────────────────────────────────┤
│ x402 facilitator integration │ Facilitator must construct UserOps or go through bundler │ Facilitator calls vault directly │
└──────────────────────────────┴───────────────────────────────────────────────────────────────────┴──────────────────────────────────┘
The core issue
In the x402 flow, the agent isn't the one submitting the on-chain transaction — the facilitator is. The facilitator receives the signed
payment from the agent, verifies it, and settles on-chain. This means:
- The vault doesn't need to process UserOps
- There's no benefit to going through EntryPoint
- The bundler infrastructure is pure overhead
- The agent's signature is already captured in the x402 payment payload
ERC-4337 is designed for the case where the account owner initiates transactions. In our case, a third party (facilitator) initiates
settlement on behalf of agents. The vault just needs to validate that the settlement is authorized (BLS attestation + agent signature +
budget check).
My recommendation
Phase 0: Minimal vault contract. Purpose-built for exactly what we need:
contract NewtonVault {
// Per-agent policy slots
mapping(address agent => AgentPolicy) public agentPolicies;
// Per-agent spending tracking
mapping(address agent => mapping(bytes32 sessionId => uint256)) public sessionSpent;
// Called by x402 facilitator
function settle(
address agent,
address recipient,
address token,
uint256 amount,
bytes calldata blsAttestation, // Newton operator attestation
bytes calldata agentSignature // Agent's EIP-712 signature
) external;
// Operator admin
function setAgentPolicy(address agent, AgentPolicy calldata policy) external onlyOwner;
function revokeAgent(address agent) external onlyOwner;
}
Phase 1+: Migrate to ERC-7579 module IF the ecosystem benefits justify it (operator demand for additional modules, Rhinestone integration
for PRD B convergence, etc.).
★ Insight ─────────────────────────────────────
Standards adoption timing: Using ERC-7579 in a PRD signals standards awareness to investors and partners. But implementing it in Phase 0
when the payment flow doesn't need UserOps adds complexity without user-facing value. The vault's validation logic (BLS + agent sig +
budget) is the same regardless of whether it's a standalone contract or an ERC-7579 module — the difference is just the entry point.
Starting minimal and wrapping it as a module later is straightforward; unwinding unnecessary ERC-4337 infrastructure is painful.
The facilitator pattern is the key insight: x402 fundamentally changes who submits transactions. In a normal smart account wallet, the
user submits their own ops (hence ERC-4337). In x402, a facilitator settles on behalf of agents. This makes the account abstraction
infrastructure redundant for this specific flow.
─────────────────────────────────────────────────
Want me to update the PRD and Linear tasks to reflect a minimal vault approach for Phase 0, with ERC-7579 migration as a Phase 1 option?
Or do you see a reason to keep the smart account path?
Rhinestone Orchestrator Integration: Deep Technical Analysis
There are actually three distinct integration models, not two. The PRD v0.3 collapsed the space into "SDK mediates" vs "Orchestrator calls Newton," but
the real design space is richer.
Model A: SDK Mediates (Client-Side Orchestration)
sequenceDiagram
participant Agent as Agent SDK
participant RH as Rhinestone Orchestrator
participant NW as Newton Gateway
participant SC as Smart Account (on-chain)
The SDK is the integration glue. It makes two independent API calls (Rhinestone for routing, Newton for policy), then stitches them together into a
signed UserOperation.
Pros
┌────────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Dimension │ Detail │
├────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Ship speed │ Zero partner dependency. Newton builds its SDK, Rhinestone exists as-is. Phase 0 can ship in weeks. │
├────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Fault isolation │ Newton downtime doesn't break Rhinestone quotes; Rhinestone downtime doesn't break Newton policy eval. Each failure mode is │
│ │ independent. │
├────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Flexibility │ SDK can call Newton before or after quoting Rhinestone. Can skip Newton entirely for bypass-mode accounts. Can retry Newton │
│ │ independently of Rhinestone. │
├────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Testing │ Each integration can be tested and mocked independently. No shared test environment needed. │
├────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Multi-orchestrator │ Newton is not locked to Rhinestone. The SDK can swap Rhinestone for any ERC-7683 orchestrator (Across, Socket, LI.FI) with │
│ │ zero Newton-side changes. │
├────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Transparency │ Agent operator sees exactly what calls happen — full observability into both the routing decision and the policy decision │
│ │ separately. │
└────────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Cons
┌───────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Dimension │ Detail │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Latency │ Two sequential round-trips: Rhinestone quote (~200-500ms) + Newton attestation (~2-3s) + Rhinestone submit (~200ms). Total: │
│ │ ~3-4s. For x402, the 402 response window may be 5-10s — this is tight. │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ DX complexity │ Developer must understand both Newton and Rhinestone APIs. The SDK abstracts this, but debugging requires knowledge of both │
│ │ systems. Error messages span two domains. │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Signature │ The agent SDK must map Rhinestone's PermitBatchWitnessTransferFrom + Mandate EIP-712 types to Newton's Intent struct. Any │
│ coordination │ mismatch = silent validation failure on-chain. │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Race conditions │ Between Newton policy eval (step 2) and Rhinestone submission (step 4), market conditions can change. A solver quote may │
│ │ expire, or token prices shift, making the attested intent stale. │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Redundant data │ Both Rhinestone and Newton need the intent details. The SDK sends similar data twice (recipient, amount, chain) to different │
│ │ endpoints. │
└───────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
★ Insight ─────────────────────────────────────
The latency concern is real but manageable for Phase 0. Newton's newt_createTask already returns in 2-3s (operator broadcast + BLS aggregation). The
Rhinestone quote is a simple HTTP call (~200ms). The total 3-4s is within x402's typical payment window. The optimization path is attestation caching
(Open Question #1 in the PRD), not integration model changes.
─────────────────────────────────────────────────
Model B: Orchestrator Calls Newton (Server-Side Integration)
sequenceDiagram
participant Agent as Agent SDK
participant RH as Rhinestone Orchestrator
participant NW as Newton Gateway
participant SC as Smart Account (on-chain)
Rhinestone's Orchestrator becomes the integration point. The agent makes one API call; Rhinestone internally calls Newton before returning the quote.
Pros
┌──────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Dimension │ Detail │
├──────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ DX │ One API call, one response. Agent developer doesn't need to know Newton exists. "Policy enforcement" is just a flag on the │
│ simplicity │ Rhinestone intent. │
├──────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Latency │ Rhinestone can parallelize the quote calculation and Newton policy eval. Instead of sequential (500ms + 2500ms = 3000ms), it's │
│ │ parallel: max(500ms, 2500ms) = ~2500ms. Saves ~500ms. │
├──────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Atomic quote │ The Rhinestone quote and Newton attestation are computed against the same intent snapshot — no race condition between quote and │
│ │ attestation. │
├──────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Error │ Agent gets one error response. Either the quote works (with policy approval) or it doesn't. No partial success states. │
│ surface │ │
└──────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Cons
┌─────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Dimension │ Detail │
├─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Partner dependency │ Requires Rhinestone to implement Newton as a plugin in their orchestrator pipeline. This is engineering work on their side │
│ │ with their timeline. │
├─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Shared uptime │ If Newton Gateway is down, Rhinestone quotes fail for Newton-enabled accounts. Rhinestone may not want this coupling for │
│ │ their 10+ chain, multi-protocol system. │
├─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Auth complexity │ Rhinestone must hold Newton API keys and manage per-policy-client auth. This is a trust boundary — Rhinestone is now an │
│ │ intermediary for Newton's access control. │
├─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Versioning │ Newton API changes require Rhinestone to update their integration. Two release cycles must be coordinated. Breaking changes │
│ │ in newt_createTask schema break Rhinestone's pipeline. │
├─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Newton visibility │ Agent operators lose direct observability into Newton. The attestation is embedded in Rhinestone's response — debugging │
│ │ policy failures requires Rhinestone support. │
├─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Vendor lock-in │ Newton's policy layer becomes tightly coupled to Rhinestone's intent format. Switching orchestrators means re-implementing │
│ │ the server-side integration with each new partner. │
├─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Fee attribution │ Who charges for what? Rhinestone's 3bps + Newton's attestation fee must be reconciled. Revenue sharing adds business │
│ │ complexity. │
├─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Newton Gateway │ Newton Gateway's JSON-RPC endpoint must be accessible to Rhinestone servers. This expands the attack surface — Rhinestone's │
│ exposure │ infrastructure becomes a trust boundary for Newton. │
└─────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
★ Insight ─────────────────────────────────────
The real cost of Model B isn't technical — it's organizational. Rhinestone is a small team building a complex cross-chain system. Adding "call Newton for
every intent that has a policy_client" is non-trivial pipeline work. And Rhinestone has no economic incentive to do this until Newton demonstrates
demand. The ~500ms latency savings doesn't justify the partnership overhead for Phase 0.
─────────────────────────────────────────────────
Model C: Newton Gateway Wraps Rhinestone (Newton-Side Orchestration)
This is the model the PRD didn't consider, and it may be the best long-term architecture:
sequenceDiagram
participant Agent as Agent SDK
participant NW as Newton Gateway
participant RH as Rhinestone Orchestrator
participant SC as Smart Account (on-chain)
Newton Gateway becomes the orchestration point. The agent talks only to Newton. Newton internally calls Rhinestone for cross-chain routing when needed.
Pros
┌────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Dimension │ Detail │
├────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Single API for agents │ Agent developers learn one API: Newton's. Cross-chain routing is an implementation detail. This is the "Agent Neobank" DX │
│ │ — one account, one API. │
├────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Newton controls the │ Policy eval happens before routing. If the policy rejects the intent, Rhinestone is never called — saving the quote │
│ pipeline │ roundtrip. No wasted Rhinestone API calls for blocked payments. │
├────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ Newton can parallelize BLS aggregation and Rhinestone quote. And for same-chain payments (majority of x402 on Base), │
│ Latency optimization │ Rhinestone is skipped entirely — direct ERC-20 transfer with attestation only. Same-chain: ~2-3s. Cross-chain: ~3s │
│ │ (parallel). │
├────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Fallback paths │ Newton can implement fallback: if Rhinestone is down, fall back to direct transfer on the source chain. If the agent has │
│ │ USDC on Base and the payment is on Base, skip Rhinestone entirely. │
├────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Multi-orchestrator │ Newton can swap Rhinestone for any solver backend without changing the agent-facing API. Today Rhinestone, tomorrow │
│ │ Across or a custom solver. │
├────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Business model clarity │ Newton charges for the whole service. The agent pays Newton; Newton pays Rhinestone's 3bps internally. Clean revenue │
│ │ model. │
├────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Audit trail │ Every step is logged in Newton's system — policy eval result, routing decision, execution status. Single source of truth │
│ │ for the operator dashboard. │
└────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Cons
┌────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Dimension │ Detail │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Engineering scope │ Newton must build the Rhinestone integration internally. This is the same work as Model A's SDK but in Rust (Gateway) instead │
│ │ of TypeScript (SDK). │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Gateway complexity │ The Newton Gateway adds a new responsibility: cross-chain route planning. This increases the Gateway's surface area and │
│ │ failure modes. │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Rhinestone API key │ Newton Gateway holds Rhinestone API keys for all agent accounts. Must manage per-account or per-operator keys if Rhinestone │
│ management │ requires them. │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ │ Rhinestone's PermitBatchWitnessTransferFrom requires EIP-712 signatures from the agent's session key. Newton Gateway can't │
│ Signing flow │ sign on behalf of the agent — the signing must still happen client-side. This means step 5 returns a bundle to sign, not a │
│ │ completed transaction. │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Two submissions │ The agent still submits to Rhinestone (step 6) because only the agent holds the session key for signing. Newton prepares │
│ │ everything, but the final submission is client-side. │
└────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
★ Insight ─────────────────────────────────────
The signing constraint (Rhinestone needs an EIP-712 signature from the agent's session key) means no integration model can be truly single-call
end-to-end. The agent always needs to sign and submit. What changes across models is who prepares the data to sign. Model C optimizes this: Newton does
all the server-side work (policy + routing), returns a ready-to-sign bundle, and the agent just signs and submits. This is the "prepare → sign → submit"
pattern that Rhinestone itself uses internally.
─────────────────────────────────────────────────
Comparison Matrix
┌─────────────────────────┬──────────────────────────┬──────────────────────────────────────────────┬──────────────────────────────────┐
│ Dimension │ Model A: SDK Mediates │ Model B: Orchestrator Calls Newton │ Model C: Newton Wraps Rhinestone │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Who builds the glue │ Newton SDK (TypeScript) │ Rhinestone (their backend) │ Newton Gateway (Rust) │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Partner dependency │ None │ Heavy (Rhinestone eng time) │ Light (API consumer only) │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Agent-facing APIs │ 2 (Newton + Rhinestone) │ 1 (Rhinestone) │ 1 (Newton) │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Latency (cross-chain) │ ~3-4s (sequential) │ ~2.5s (parallel) │ ~3s (parallel) │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Latency (same-chain) │ ~3-4s (still calls both) │ ~2.5s (still calls both) │ ~2-3s (skips Rhinestone) │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Fault isolation │ Independent │ Coupled │ Semi-independent │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Newton brand visibility │ High (explicit API) │ Low (hidden behind Rhinestone) │ Highest (single touchpoint) │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Multi-orchestrator │ Easy (SDK swaps) │ Hard (per-partner integration) │ Easy (Gateway swaps) │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Phase 0 feasibility │ Ship immediately │ 3-6 months (partner work) │ 2-4 weeks extra vs Model A │
├─────────────────────────┼──────────────────────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
│ Best for │ Phase 0 MVP │ Phase 2+ (if Rhinestone partnership deepens) │ Phase 1 production │
└─────────────────────────┴──────────────────────────┴──────────────────────────────────────────────┴──────────────────────────────────┘
Recommendation: Phased Approach
Phase 0 → Model A (SDK Mediates)
Ship fast, no dependencies. The TypeScript SDK makes two calls. The 3-4s latency is acceptable for Phase 0 testnet. This proves the product concept.
Phase 1 → Model C (Newton Wraps Rhinestone)
Once the product is validated, move the Rhinestone integration into the Gateway. Benefits:
— all of this applies directly to wrapping Rhinestone's API
Phase 2+ → Model B (Optional, if partnership deepens)
If Rhinestone wants to offer "Newton-secured intents" as a first-class feature, Model B becomes an additional channel alongside Model C. Newton supports
both: direct agents via Model C, Rhinestone-native users via Model B. But Model B is never the only path — Newton must always have its own agent-facing
API.
★ Insight ─────────────────────────────────────
The key architectural insight is that the Newton Gateway's existing ChainService pattern already solves the routing problem Model C needs.
resolve_chain_for_intent() (in crates/gateway/src/rpc/api/sync.rs:96) already dispatches based on intent.chainId. Adding Rhinestone as a cross-chain
routing backend is a natural extension: if source_chain != dest_chain, call Rhinestone for routing; if same-chain, skip Rhinestone and construct a direct
transfer UserOp. The create_task method already returns the BLS attestation — wrapping it with a Rhinestone quote is additive, not restructuring.
─────────────────────────────────────────────────
Critical Design Decision: The Signing Boundary
Regardless of model, one constraint is unavoidable:
The agent's session key must sign the Rhinestone Mandate struct. This is an EIP-712 typed data signature over the specific solver, amount, and chain
routing. Newton Gateway cannot sign this — it doesn't hold the agent's session key.
This means the real flow is always three phases:
The integration model determines who does step 1. Model A: the SDK orchestrates two servers. Model B: Rhinestone does it. Model C: Newton does it. Steps
2-3 are always client-side.
This is why the SDK always exists regardless of model — the signing step can't be eliminated. The question is how much intelligence lives in the SDK vs the server.