Created
March 10, 2026 09:43
-
-
Save denniswon/e997c1073ad7af8c5521ed10b0ab787b to your computer and use it in GitHub Desktop.
Rhinestone Chain Abstraction (Warp) — Technical Summary
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| --- | |
| 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 │ | |
| └─────────────────────────────────────┴───────────────────────────┴──────────────────────────────────────────────────────┘ |
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
(Content IDentifier).
set attestation info with all 13 registered attesters.
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.