Rhinestone Chain Abstraction (Warp) — Technical Summary

gistfile1.txt

 ---
  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 ─────────────────────────────────────
Effective BD outreach on Telegram needs to be:

1. Short — Telegram is a chat medium, not email. Wall of text = ignored.
2. Tailored hook — Show you understand their product before pitching yours.
3. 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.

---

1. 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?

---

2. 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?

---

3. 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:

1. Modularity narrative — "install NewtonVaultModule like any other module"
2. Ecosystem composability — operator could add recovery, multisig, timelock modules later
3. Standards alignment — ERC-7579 is the modular account standard, looks good in a PRD
4. 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?

▐▛███▜▌ Claude Code v2.1.76
▝▜█████▛▘ Opus 4.6 (1M context) with medium effort · Claude API
▘▘ ▝▝ ~/projects/newton-agent-neobank

⏺ Update(CLAUDE.md)
⎿  Added 1 line, removed 1 line
225 | M0.7 | MCP Server (fleet management tools) | Done |
226 | M0.8 | REST API (Hono + JWT auth + Swagger UI) | Done |
227 | M0.9 | ERC-8004 identity registration | Done |
228 -| M0.10 | Demo + docs for agent platform partners | TODO |
228 +| M0.10 | Demo + docs for agent platform partners | Done |
229
230 ## Product Context
231

⏺ Now add the demo package to the project structure tree in CLAUDE.md.

⏺ Update(CLAUDE.md)
⎿  Added 3 lines
106 │ │ ├── config.ts # Env-based config loader
107 │ │ ├── middleware.ts # JWT auth + rate limiting
108 │ │ └── routes.ts # 15 REST endpoints
109 +│ ├── demo/ # Live demo script (4-act narrative)
110 +│ │ └── src/
111 +│ │ └── demo.ts # Deploy vault, settle, enforce, shutdown
112 │ └── agent-account/ # TypeScript SDK
113 │ ├── src/
114 │ │ ├── vault.ts # NewtonVault class (create, connect, registerAgent, admin)

⏺ Now update the architecture docs to move Demo from "Remaining" to "Implemented".

⏺ Searched for 1 pattern, read 1 file (ctrl+o to expand)
⎿  Loaded ../../.claude/CLAUDE.md

⏺ Update(.claude/rules/architecture.md)
⎿  Added 1 line, removed 6 lines
132 | x402 Handler | HTTP 402 handler with exact scheme via createX402Fetch() and createX402Client() |
133 | E2E Test Suite | SDK ↔ anvil integration tests (15 scenarios) |
134 | ERC-8004 Identity | AgentRegistry (ERC-721 Agent Cards) + ValidationRegistry (Newton as crypto-economic validator)
|
135 +| Demo | 4-act narrative script: deploy vault, settle payments, enforce policies, emergency controls |
136
136 -### Remaining Phase 0
137 -
138 -| Component | Description |
139 -|-----------|-------------|
140 -| Demo + Docs | Live agent fleet demo for platform partners |
141 -
137 ### Phase 1
138
139 | Component | Description |

⏺ Now add the demo entry point to the agent guide.

⏺ Read 1 file (ctrl+o to expand)

⏺ Update(.claude/rules/agent-guide.md)
⎿  Added 1 line
27 | Identity Registry | src/identity/AgentRegistry.sol | ERC-8004 ERC-721 Agent Card NFTs |
28 | Validation Registry | src/identity/ValidationRegistry.sol | ERC-8004 validator attestation registry |
29 | SDK Identity | packages/agent-account/src/identity.ts | NewtonIdentity class (register, bind wallet, validate) |
30 +| Demo | packages/demo/src/demo.ts | 4-act live demo against local anvil |
31 | Rego Policies | policies/templates/agent_payment.rego | Composite policy entry point |
32 | Config | foundry.toml | Solc version, remappings, fmt config |
33 | PRD | docs/PRD_AGENT_NEOBANK.md | Product requirements and architecture |

⏺ Now commit and push.

⏺ Skill(/commit-git)
⎿  Successfully loaded skill

⏺ Bash(cd /Users/denniswon/projects/newton-agent-neobank && git status -u)
⎿  On branch main
Your branch is up to date with 'origin/main'.
… +12 lines (ctrl+o to expand)

⏺ Bash(git diff --stat)
⎿   pnpm-lock.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

⏺ Bash(git log --oneline -5)
⎿  1f317a6 fix: remove unused error, fix event typo, add unbindWallet to SDK
b226116 docs: add ERC-8004 identity to SDK reference and testing docs
31f6dd5 feat: add ERC-8004 agent identity and validation registries
… +2 lines (ctrl+o to expand)

⏺ The CLAUDE.md and architecture rule changes aren't showing in the diff — they're likely gitignored. Let me check.

⏺ Bash(git check-ignore CLAUDE.md .claude/rules/architecture.md .claude/rules/agent-guide.md 2>&1)
⎿  CLAUDE.md
.claude/rules/architecture.md
.claude/rules/agent-guide.md

⏺ As expected — CLAUDE.md and .claude/ are gitignored per the project's git hygiene rules. The commit will contain the demo package files
and lockfile update.

⏺ Bash(git add packages/demo/package.json packages/demo/tsconfig.json packages/demo/src/demo.ts pnpm-lock.yaml && git commit -m "feat: add
live demo script for agent f…)
⎿  [main 87f4d6f] feat: add live demo script for agent fleet lifecycle
4 files changed, 716 insertions(+)
create mode 100644 packages/demo/package.json
… +8 lines (ctrl+o to expand)

⏺ Pushed. Now let me mark NEWT-735 as done in Linear.

⏺ plugin:linear:linear - save_issue (MCP)(id: "NEWT-735", state: "Done")
⎿  {
"id": "NEWT-735",
"title": "[P0-M0.16] Demo — live agent fleet paying for API calls with policy enforcement",
… +20 lines (ctrl+o to expand)

⏺ NEWT-735 marked Done in Linear.

★ Insight ─────────────────────────────────────
Phase 0 is now complete. All 10 milestones (M0.1-M0.10) are done:

• M0.1: NewtonVault + Factory + Forge tests
• M0.2: Rego policy templates
• M0.3: TypeScript SDK core
• M0.4: x402 handler
• M0.5: E2E test suite (15 scenarios)
• M0.6: CLI tool (newton-agent)
• M0.7: MCP Server (fleet management)
• M0.8: REST API (Hono + JWT + Swagger)
• M0.9: ERC-8004 identity registration
• M0.10: Demo script

The demo (packages/demo/src/demo.ts) exercises the full stack in a 4-act narrative against local anvil: vault deployment, dual-sig
settlements with budget enforcement, recipient allowlist blocking, ERC-8004 Agent Card NFT minting, and emergency shutdown/recovery. It
confirms $885 USDC vault balance after all settlements ($1000 - $10 - $35 - $50 - $15 - $5 = $885).
─────────────────────────────────────────────────

Summary of what shipped:

┌─────────────────────────────┬─────────────────────────────────┐
│ File │ Description │
├─────────────────────────────┼─────────────────────────────────┤
│ packages/demo/package.json │ Demo package config (tsx, viem) │
├─────────────────────────────┼─────────────────────────────────┤
│ packages/demo/tsconfig.json │ TypeScript config │
├─────────────────────────────┼─────────────────────────────────┤
│ packages/demo/src/demo.ts │ 4-act demo script (~400 lines) │
└─────────────────────────────┴─────────────────────────────────┘

How to run:
forge build # compile contracts
anvil --port 8546 --chain-id 84532 --silent # start local chain
cd packages/demo && pnpm install && pnpm demo # run demo

All 84 tests pass (71 Forge + 13 SDK). Phase 0 of Agent NeoBank is complete. Phase 1 items (Policy Sessions, upto scheme, self-hosted
facilitator, multi-layer caching) are the next horizon.

All 4 verification agents complete. Here's the comprehensive Phase 0 verification report.

★ Insight ─────────────────────────────────────
This is a full-stack verification across 4 domains: Solidity contracts, TypeScript SDK, ancillary packages (CLI/MCP/API/Demo), and
documentation accuracy. Each domain was verified independently by a parallel agent, checking file existence, type consistency, test
passage, and doc-to-code accuracy. Zero false statements found.
─────────────────────────────────────────────────

---

Phase 0 Comprehensive Verification Report

Agent 1: Solidity Contracts — ALL PASSED

┌──────────────────────────────────────────────────────┬────────┐
│ Check │ Result │
├──────────────────────────────────────────────────────┼────────┤
│ 7 contracts exist (1,212 lines) │ PASS │
├──────────────────────────────────────────────────────┼────────┤
│ 3 test suites exist (1,248 lines) │ PASS │
├──────────────────────────────────────────────────────┼────────┤
│ SETTLEMENT_TYPEHASH matches struct (7 fields) │ PASS │
├──────────────────────────────────────────────────────┼────────┤
│ WALLET_BINDING_TYPEHASH matches usage (3 fields) │ PASS │
├──────────────────────────────────────────────────────┼────────┤
│ 71/71 forge tests pass │ PASS │
├──────────────────────────────────────────────────────┼────────┤
│ All contracts under EIP-170 (max 15,086 bytes / 62%) │ PASS │
├──────────────────────────────────────────────────────┼────────┤
│ All OZ v5 import paths correct │ PASS │
└──────────────────────────────────────────────────────┴────────┘

Agent 2: TypeScript SDK — ALL PASSED

┌───────────────────────────────────────────────────────┬────────┐
│ Check │ Result │
├───────────────────────────────────────────────────────┼────────┤
│ 8 source files exist and non-empty │ PASS │
├───────────────────────────────────────────────────────┼────────┤
│ 5 test files exist (unit + E2E) │ PASS │
├───────────────────────────────────────────────────────┼────────┤
│ 4 ABI JSON files valid │ PASS │
├───────────────────────────────────────────────────────┼────────┤
│ 7 package.json scripts functional │ PASS │
├───────────────────────────────────────────────────────┼────────┤
│ EIP-712 SETTLEMENT_TYPES matches Solidity field order │ PASS │
├───────────────────────────────────────────────────────┼────────┤
│ 40+ exports (classes, types, helpers, ABIs) │ PASS │
├───────────────────────────────────────────────────────┼────────┤
│ 13/13 unit tests pass │ PASS │
├───────────────────────────────────────────────────────┼────────┤
│ vitest configs properly separate unit/E2E │ PASS │
├───────────────────────────────────────────────────────┼────────┤
│ TypeScript build succeeds, lint clean │ PASS │
└───────────────────────────────────────────────────────┴────────┘

Agent 3: CLI/MCP/API/Demo/Policies/Docs — ALL PASSED

┌───────────────────────────────────────────────┬────────┐
│ Package │ Status │
├───────────────────────────────────────────────┼────────┤
│ CLI (4 command modules) │ PASS │
├───────────────────────────────────────────────┼────────┤
│ MCP Server (11 tools) │ PASS │
├───────────────────────────────────────────────┼────────┤
│ REST API (15 endpoints, JWT, Swagger) │ PASS │
├───────────────────────────────────────────────┼────────┤
│ Demo (664-line 4-act script) │ PASS │
├───────────────────────────────────────────────┼────────┤
│ Rego Policies (4 templates + 3 test fixtures) │ PASS │
├───────────────────────────────────────────────┼────────┤
│ Docs (9 files, 4,263 lines) │ PASS │
└───────────────────────────────────────────────┴────────┘

Agent 4: Documentation Accuracy — ALL PASSED

┌────────────────────────────────────────────────┬────────┐
│ Check │ Result │
├────────────────────────────────────────────────┼────────┤
│ 11 type definitions match code field-for-field │ PASS │
├────────────────────────────────────────────────┼────────┤
│ 18 NewtonVault methods documented = source │ PASS │
├────────────────────────────────────────────────┼────────┤
│ 8 NewtonAgent methods documented = source │ PASS │
├────────────────────────────────────────────────┼────────┤
│ 14 NewtonIdentity methods documented = source │ PASS │
├────────────────────────────────────────────────┼────────┤
│ 5 NewtonAdmin methods documented = source │ PASS │
├────────────────────────────────────────────────┼────────┤
│ Constants (USDC, chain ID, period) match │ PASS │
├────────────────────────────────────────────────┼────────┤
│ foundry.toml config matches docs │ PASS │
├────────────────────────────────────────────────┼────────┤
│ ARCHITECTURE.md has all 4 Developer Interfaces │ PASS │
└────────────────────────────────────────────────┴────────┘

---

Final Tally

┌─────────────────────────┬─────────────────────────────┐
│ Metric │ Count │
├─────────────────────────┼─────────────────────────────┤
│ Verification checks run │ 48 │
├─────────────────────────┼─────────────────────────────┤
│ Checks passed │ 48 │
├─────────────────────────┼─────────────────────────────┤
│ Checks failed │ 0 │
├─────────────────────────┼─────────────────────────────┤
│ False statements found │ 0 │
├─────────────────────────┼─────────────────────────────┤
│ Tests passing │ 84 (71 Forge + 13 SDK unit) │
├─────────────────────────┼─────────────────────────────┤
│ Solidity lines │ 1,212 │
├─────────────────────────┼─────────────────────────────┤
│ Test lines │ 1,248 │
├─────────────────────────┼─────────────────────────────┤
│ SDK source lines │ ~1,850 │
├─────────────────────────┼─────────────────────────────┤
│ Documentation lines │ ~4,263 │
└─────────────────────────┴─────────────────────────────┘

Phase 0 is fully complete with zero issues, zero mismatches, and zero false documentation claims.

⏺ All context saved across all memory systems. Here's a summary:

Local auto-memory (.claude/projects/.../memory/):

• project_newton_policy_migration_complete.md — Full migration details, before/after tables, 13 commits, test status, deferred work
• reference_newton_protocol_addresses.md — Newton Base Sepolia addresses, dual-anvil setup
• feedback_newton_migration_patterns.md — Context-scoped remappings, mock patterns, setPolicy gotcha
• project_newton_policy_client_refactor.md — Updated with decision context
• MEMORY.md — Index updated with all new entries + key project links

Supermemory (cloud):

• Saved as newton-agent-neobank project knowledge (ID: 9bBVK8CdzdLx4iBiteWgnt)

Recall-local (self-hosted):

• 8 memories stored covering: architecture decision, contract addresses, build patterns, gotchas, requirements, testing setup, roadmap,
  project links

lessons.md (.claude/rules/lessons.md):

• 10 new entries under "Newton PolicyClient Integration":
  a. via_ir required for newton-contracts
  b. OZ v4/v5 context-scoped remappings
  c. _setPolicyAddress() vs setPolicy() distinction
  d. E2E tests need dual-anvil
  e. pure vs view in test helpers
  f. Recursive submodule init required
  g. forge install --no-commit doesn't exist
  h. ERC-165 interfaceId registration behavior
  i. Incremental refactor compilation errors expected
  j. SDK ABIs must be regenerated after contract changes

Linear Updates Completed

All Phase 0.5 work is marked done:

• 12 issues (NEWT-737 through NEWT-748) → Done
• Project description updated with Phase 0.5 COMPLETE status
• 7 new Phase 1 issues created (NEWT-749 through NEWT-755)

Next Steps — Critical Path

These two items unblock everything else:

┌──────────┬──────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────┐
│ Issue │ What │ Why Critical │
├──────────┼──────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────┤
│ NEWT-749 │ Deploy NewtonVault to Base Sepolia with real │ Can't test real attestations without live contracts │
│ │ Newton AVS │ │
├──────────┼──────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────┤
│ NEWT-750 │ E2E intent execution tests with dual-anvil │ Proves the full pipeline works: SDK → Newton Gateway → BLS attestation → │
│ │ │ vault executeIntent │
└──────────┴──────────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────┘

Both require the newton-prover-avs dual-anvil infrastructure (make dual-anvil-deploy) to be running.

High Priority (after critical path)

┌──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Issue │ What │
├──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ NEWT-751 │ WASM data oracle backend — provides real-time spending state to Rego engine (replaces the old on-chain accumulator) │
├──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ NEWT-752 │ Rewrite demo script for Newton intent execution flow (current demo references old settle pattern) │
├──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ NEWT-753 │ On-chain Newton Policy registration via newton-cli — needed for operators to register policies without manual cast │
│ │ commands │
└──────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Medium Priority (Phase 1 features)

┌──────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Issue │ What │
├──────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ NEWT-754 │ Policy Sessions — sub-100ms cached attestations for repeat payments (L0 SDK → L1 Moka → L2 Redis → L3 on-chain) │
├──────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ NEWT-755 │ Self-hosted Newton x402 facilitator replacing Coinbase hosted │
└──────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

★ Insight ─────────────────────────────────────
The critical path items (NEWT-749, NEWT-750) are tightly coupled to the newton-prover-avs repo. The dual-anvil setup runs two chains —
source (port 8545, chainId 31337) and destination (port 8546, chainId 84532) — with Newton's TaskManager, Policy, and PolicyData
contracts deployed on the destination chain. Until those are live on Base Sepolia, all "real" attestation testing happens locally via
dual-anvil.
─────────────────────────────────────────────────

Want to start on any of these, or tackle something else first?

★ Insight ─────────────────────────────────────
Key discovery during deployment: The setPolicy() function inherited from NewtonPolicyClient takes a PolicyConfig struct (bytes
policyParams, uint32 expireAfter), not just an address. The address is set separately during initialize() via _setPolicyAddress(). This
two-step setup is by design — the vault proxy needs to be fully initialized before it can interact with the Newton Policy contract to
register and obtain a policyId.

The onlyPolicyClient guard on Newton's Policy contract checks ERC-165 supportsInterface(INewtonPolicyClient) — it doesn't need a separate
registration step. Any contract inheriting NewtonPolicyClient automatically passes this check.
─────────────────────────────────────────────────

Deployment Summary

Contracts deployed to Base Sepolia (chainId 84532):

┌──────────────────────┬────────────────────────────────────────────┐
│ Contract │ Address │
├──────────────────────┼────────────────────────────────────────────┤
│ Factory Proxy │ 0x7D86c84570D38cb2027E46852f408B8992045981 │
├──────────────────────┼────────────────────────────────────────────┤
│ Vault Implementation │ 0xf12322c9E545c71FFE05a3671b6169AeF0E47357 │
├──────────────────────┼────────────────────────────────────────────┤
│ Test Vault │ 0xa22c9f8dcfd0bc1067c512455b017a86cce2cb3f │
└──────────────────────┴────────────────────────────────────────────┘

Verified on-chain:

• Vault owner matches deployer
• getPolicyId() returns 0xd5489d6b...
• getPolicyAddress() returns Newton Policy
• getNewtonPolicyTaskManager() returns Newton TaskManager

What was done:

1. Created .env with deployer key and Newton addresses from newton-contracts/deployments/
2. Ran forge script Deploy.s.sol --broadcast — 5 contracts deployed (~0.00012 ETH gas)
3. Deployed an operator vault via factory.deployVault()
4. Registered policy via vault.setPolicy((bytes,uint32))
5. Fixed stale setPolicy(address) references in LOCAL_DEVELOPMENT.md
6. Committed deployments/84532.json and pushed
7. Updated NEWT-749 to Done in Linear

The Newton Policy contract (0x17a742...) was deployed by the Newton team. When we look at the PolicySet event, it includes references
to:
- policyCid — IPFS hash pointing to the Rego policy source code
- schemaCid — IPFS hash pointing to the policy input schema
- entrypoint — mockerc20.allow (the Rego rule entrypoint)
- policyData — 0x8bc499... (the PolicyData contract that provides WASM oracle data) --> That policy is a sample policy that is only
used for newton-prover-avs core protocol testing purposes. For agent neobank, our mock policy/policy client/policy data should be a
simple example policy/policy client/policy data but NOT a mock. Same for Task Manager, we should not use MockTaskManager or MockPolicy,
etc., we should actually use a real TaskManager, Policy, Policy Data. For us Policy Client is the Vault, right? correct me if im
incorrect. For Policy, we should have the vault's settle() to be policy guarded requiring a Newton Attestation, and Newton Policy for
the Agent Neobank is checking for the following rule: 1. agent can only settle USDC
(https://developers.circle.com/stablecoins/usdc-contract-addresses) 2. max daily spend 100 USDC 3. whitelist of addresses for the
receiver of the USDC that agent can send to. Note that for the max daily spend 100 USDC, we would need a stateful NewtonPolicyData
Wasmt that tracks that is stateful tracking the daily spending amounts of each agent. In terms of "where the agent spending state" is
being stored/kept track, we can use redis for now: (for local - redis://:redis@127.0.0.1:6379, for testnet,
rediss://master.newton-prover-avs-redis.ms2j0z.usw2.cache.amazonaws.com:6379) You can use newton-cli or
@~/projects/newton-prover-avs/Makefile to deploy policy, deploy policy data, upload wasm to ipfs, or other policy/policy metadata to
ipfs, etc. (Note: there might be some missing capabilities in newton-cli compared to the Makefile in newton-prover-avs in regards to
"Policy/PolicyData, etc. operations". If you find any missing features needed for newton-cli (which is external developers facing dev
tools to build NewtonPolicy/PolicyData, etc.), identify them and create a Linear task for that missing feature support in newton-cli.
/clarify-plan. (One note: for task manager, etc. contract addresses from "newton-contracts" deployments, you should use stagef contract
address i.e. <chain_id>_stagef.json to use the protocol's staging environment)

1. it should live in this repo. If you follow https://docs.newton.xyz/developers/advanced/policy-data-oracles, we support
   typescript/python/rust. For this project, we already use typescript, so let's also use typescript for the policy data wasm as well. 2.
   let's do it as a single composite rule. 3. An off-chain indexer/service watches vault events and writes to Redis. Place the indexer
   code in this repo as well. 4. Whitelist is set as Policy Params that the NewtonPolicyClient owner (for us the vault owner) sets. Also,
   one update: in addition to Whitelist, let's ALSO have the vault owner set the max daily spending limit amount instead of strictly
   setting the max daily amount to 100 USDC at the policy level. The Max daily spend input should also be a part of policy params set by
   the owner, along with the whitelist param. Let's store this in postgres. local -
   postgres://newton:newton@localhost:5432/newton_gateway, testnet remote - postgresql://postgres:SC2vHz6B8kPuFY2.TTX-H4%5Ee20cOvS@newtoni
   ndexercommonusw2-newtonindexerdb496793b7-g3hoz4zowzv1.cluster-cnwi4m0gkxcv.us-west-2.rds.amazonaws.com:5432/newton_agent. We might need
   something like make local-dbs command like in @~/projects/newton-prover-avs/Makefile local-dbs target that launches postgres and
   redis services locally, and we would also need to create a new database named "newton_agent" for both local and remote because the
   postgres DB does not exist yet. 5. Yes, lets "REDPLOY" our contracts against stagef addresses (stagef is the default for now)
   ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

★ Insight ─────────────────────────────────────
Key discovery: Newton's WASM data provider docs claim TypeScript support, but ALL existing examples are Rust compiled to wasm32-wasip2.
The WIT interface (newton:provider@0.1.0) defines run(input) -> result<string, string> with http.fetch() and secrets.get() imports. We'll
need to verify the TypeScript WASM compilation toolchain works with this WIT — if not, that's a newton-cli gap to track.

Stagef infrastructure is ready: PolicyFactory (0xcd2b28...), PolicyDataFactory (0x502d5d...), and PolicyClientRegistry (0x3cfef33...) are
all deployed on Base Sepolia stagef. We deploy our OWN policy + policy data through these factories — we don't reuse the sample ones.
─────────────────────────────────────────────────

---

Implementation Plan: Real Newton Policy for Agent NeoBank

Based on your answers and the research, here's the full plan broken into 6 workstreams:

Workstream 1: Infrastructure — Database + Docker

What: Add local Postgres + Redis via docker-compose, create newton_agent database.

┌─────────────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Task │ Detail │
├─────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Create │ Postgres 16 + Redis 7 (matches newton-prover-avs pattern) │
│ docker-compose.dev.yml │ │
├─────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Add Justfile targets │ local-dbs, local-dbs-stop, local-dbs-status, local-dbs-reset │
├─────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Update .env.example │ Add DATABASE_URL, REDIS_URL with local defaults │
├─────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Create DB migration │ newton_agent database with agent_spending table (agent_address, vault_address, daily_spent, │
│ │ period_start, last_tx_hash) │
└─────────────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────┘

Connection strings (from your answers):

• Local Redis: redis://:redis@127.0.0.1:6379
• Local Postgres: postgres://newton:newton@localhost:5432/newton_agent
• Remote Postgres: postgresql://postgres:SC2vHz6B8kPuFY2.TTX-H4%5Ee20cOvS@newtonindexercommonusw2-newtonindexerdb496793b7-g3hoz4zowzv1.cl
  uster-cnwi4m0gkxcv.us-west-2.rds.amazonaws.com:5432/newton_agent
• Remote Redis: rediss://master.newton-prover-avs-redis.ms2j0z.usw2.cache.amazonaws.com:6379

---

Workstream 2: Redeploy Contracts Against Stagef

What: Redeploy vault factory + vault using stagef TaskManager instead of prod.

┌───────────────────────────────┬─────────────────────────────────────────────────────────────────────────────────────┐
│ Task │ Detail │
├───────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ Update .env │ NEWTON_TASK_MANAGER=0xda128a87412be6f2161bb87200f0f40e89744bd9 │
├───────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ Update .env │ NEWTON_POLICY — initially use stagef sample, then swap after our policy is deployed │
├───────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ Run just deploy-sepolia │ Redeploys factory proxy + vault impl against stagef TaskManager │
├───────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ Deploy operator vault │ cast send $FACTORY "deployVault(...)" │
├───────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ Register as PolicyClient │ newton-cli policy-client register --registry 0x3cfef33b... --client $VAULT │
├───────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ Update deployments/84532.json │ New addresses │
└───────────────────────────────┴─────────────────────────────────────────────────────────────────────────────────────┘

Stagef addresses to use:
TaskManager: 0xda128a87412be6f2161bb87200f0f40e89744bd9
PolicyClientRegistry: 0x3cfef33b37ee120bb0522dff77ed09fd97d4b40e
PolicyFactory: 0xcd2b28eed56b51f9aee4174a9301863a9dbde60e
PolicyDataFactory: 0x502d5d784548ce8b8c2ebb1542908d8a64fd64c4

---

Workstream 3: Agent NeoBank Rego Policy

What: Single composite Rego rule with 3 checks, all parameterized.

policies/
agent_neobank/
agent_neobank.rego # Composite entry point
policy_params_schema.json # JSON schema for params
policy_metadata.json # Name, version, description

Policy checks (all from policy params, NOT hardcoded):

1. Token restriction — only USDC (0x036CbD53842c5426634e7929541eC2318f3dCF7e on Base Sepolia)
2. Daily spend limit — intent.value <= (max_daily_spend - daily_spent), where max_daily_spend comes from policy params and daily_spent
   from WASM data provider (Redis)
3. Receiver whitelist — intent.to must be in allowed_recipients from policy params

Policy params format (set by vault owner via newton-cli policy-client set-policy-params):
{
"84532": {
"<vault_address>": {
"agent_neobank": [
{ "name": "max_daily_spend", "type": "number", "value": 100000000, "description": "Max daily USDC spend (6 decimals)" },
{ "name": "allowed_recipients", "type": "string", "value": "0xabc...,0xdef...", "description": "Comma-separated allowed recipient
addresses" },
{ "name": "allowed_token", "type": "string", "value": "0x036CbD53842c5426634e7929541eC2318f3dCF7e", "description": "Allowed token
address (USDC)" }
]
}
}
}

Deployment via newton-cli:

1. Generate CIDs for policy files

newton-cli policy-files generate-cids --config policies/agent_neobank/policy_cids_config.json

2. Deploy PolicyData (WASM provider)

newton-cli policy-data deploy --chain-id 84532 --policy-cids policies/agent_neobank/policy_cids.json

3. Deploy Policy (Rego)

newton-cli policy deploy --chain-id 84532 --policy-data-address $POLICY_DATA --policy-cids policies/agent_neobank/policy_cids.json

4. Set policy on vault

newton-cli policy-client set-policy --chain-id 84532 --client $VAULT --policy $POLICY

5. Set policy params

newton-cli policy-client set-policy-params --chain-id 84532 --policy-client $VAULT --policy-params
policies/agent_neobank/policy_params.json --expire-after 300

---

Workstream 4: TypeScript WASM PolicyData Provider

What: WASM binary that reads agent spending state from Redis and returns it for Rego evaluation.

packages/policy-data/
src/
index.ts # Entry point implementing run(input) -> result<string, string>
wit/
newton-provider.wit # WIT interface (copied from newton-prover-avs)
package.json
tsconfig.json

run(input) function:

• Input: JSON string with { "policy_client": "0x...", "intent": { "from": "0x...", ... } }
• Calls secrets.get() to get Redis connection string
• Calls http.fetch() to query the indexer API for agent daily spending
• Returns: JSON string { "daily_spent": "50000000", "period_start": "2026-03-16T00:00:00Z" }

Open question: Does the Newton runtime actually support TypeScript-compiled WASM? The docs say yes, but all examples are Rust. If the
wasm32-wasip2 target from TypeScript toolchains (e.g., ComponentizeJS, jco) doesn't work with Newton's WasmExecutor, this becomes a gap.

---

Workstream 5: Off-Chain Indexer Service

What: Watches IntentExecuted events on-chain, writes spending data to Redis.

packages/indexer/
src/
index.ts # Service entry point
watcher.ts # Event watcher (viem watchContractEvent)
redis.ts # Redis client + spending accumulator
db.ts # PostgreSQL client for policy params storage
types.ts # Shared types
package.json
tsconfig.json

Event watched: IntentExecuted(address indexed from, address indexed to, uint256 value, bytes data)

Redis key structure:
spending:{vault}:{agent}:{YYYY-MM-DD} → cumulative USDC spent (string, 6 decimals)

PostgreSQL schema (newton_agent database):
CREATE TABLE policy_params (
vault_address TEXT NOT NULL,
chain_id INTEGER NOT NULL,
max_daily_spend BIGINT NOT NULL, -- USDC with 6 decimals
allowed_recipients TEXT[] NOT NULL, -- array of addresses
allowed_token TEXT NOT NULL DEFAULT '0x036CbD53842c5426634e7929541eC2318f3dCF7e',
updated_at TIMESTAMPTZ DEFAULT NOW(),
PRIMARY KEY (vault_address, chain_id)
);

---

Workstream 6: Newton CLI Gap Analysis + Linear Tasks

Identified capabilities needed:

┌─────────────────────────────────────┬────────────────────┬───────────────────────────┐
│ Capability │ newton-cli Status │ Gap? │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ policy deploy │ Exists │ No │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ policy-data deploy │ Exists │ No │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ policy-client register │ Exists │ No │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ policy-client set-policy │ Exists │ No │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ policy-client set-policy-params │ Exists │ No │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ policy-files generate-cids │ Exists │ No │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ TypeScript WASM compilation │ Docs say supported │ Needs verification │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ policy-data simulate (TS) │ Rust only? │ Needs verification │
├─────────────────────────────────────┼────────────────────┼───────────────────────────┤
│ Create PostgreSQL database remotely │ Not in CLI │ Manual / migration script │
└─────────────────────────────────────┴────────────────────┴───────────────────────────┘

---

Execution Order

1. Infrastructure (Workstream 1) ← can start immediately
2. Redeploy contracts (Workstream 2) ← can start immediately (parallel)
3. Rego policy (Workstream 3) ← after understanding params format
4. Indexer service (Workstream 5) ← after infrastructure
5. WASM provider (Workstream 4) ← after indexer (needs API to query)
6. CLI gaps (Workstream 6) ← ongoing, Linear tasks as discovered

Deployment succeeded! All 5 steps completed (step 6 status check just needs --registry flag, non-critical).

★ Insight ─────────────────────────────────────
What just happened — the full Newton policy deployment pipeline:

1. IPFS Upload — All policy files (WASM binary, Rego policy, params schema, metadata) uploaded to IPFS via Pinata. Each got a unique CID
   (Content IDentifier).
2. PolicyData Deploy — The WASM data provider was registered on-chain at 0x6f46D7eb... via the PolicyDataFactory. Newton automatically
   set attestation info with all 13 registered attesters.
3. Policy Deploy — The Rego policy was registered on-chain at 0xEC8E048D... via the PolicyFactory, linked to the PolicyData contract.
4. Set Policy on Vault — The vault at 0x97d4DC3e... now points to this policy via setPolicyAddress().
5. Set Policy Params — Daily spend limit, allowed recipients, and allowed token configured. Got policyId: 0x972a5a03...

The vault is now fully wired to a real Newton policy. Any executeIntent() call will be evaluated against the Agent NeoBank Rego policy
with real BLS attestation.
─────────────────────────────────────────────────

Let me update the deployments file and mark NEWT-761 as Done.