Rhinestone-Style Intents: Building a Chain-Agnostic Intent Engine for Wallets

Summary: This post breaks down how to design and ship a Rhinestone-style, chain-agnostic intent engine for modern wallets. It covers the concrete architecture (orchestrator, relayer market, resource locks, adapters), current standards (ERC‑7683, ERC‑7579, EIP‑7702, EIP‑5792), and battle-tested settlement layers to hit sub‑second UX on L2s with deterministic outcomes and strong security guarantees. (docs.rhinestone.dev)

Why intents now: the post‑Pectra wallet moment

Ethereum’s Pectra upgrade (activated May 7, 2025) introduced EIP‑7702, allowing EOAs to temporarily delegate execution to smart contracts. That single shift lets existing wallet addresses batch calls, enable gas sponsorship, and act like programmable smart accounts—without forcing user migrations. For wallet teams and B2B apps, this unlocks “smart EOA” UX with near‑zero onboarding friction. (pectra.org)

In parallel, the ecosystem converged on standards that make cross‑chain execution legible and interoperable:

ERC‑7683 defines a common order struct and settlement interfaces for cross‑chain intents so filler networks can interoperate. (erc7683.org)
ERC‑7579 standardizes minimal modular smart accounts and modules, avoiding vendor lock‑in while remaining ERC‑4337‑compatible. (eips.ethereum.org)
EIP‑5792 introduces wallet_sendCalls and related RPCs for capability‑aware batching from dapps. (eips.ethereum.org)

Together, this makes “Rhinestone‑style” chain abstraction practical today: a wallet UX where users sign one legible EIP‑712 message, solvers compete off‑chain, and settlement layers repay them trust‑minimally across chains. (docs.rhinestone.dev)

What “Rhinestone‑style intents” actually means

A Rhinestone‑inspired engine centers on four components:

Orchestrator (off‑chain): routes intents, builds transactions, enforces resource locks, broadcasts to a relayer market. (docs.rhinestone.dev)
Relayer market: competitive solvers with inventory and DEX/OTC access; not a single bundler. (docs.rhinestone.dev)
Intent Router (on‑chain): adapter‑based dispatcher into multiple settlement layers and account modules. (docs.rhinestone.dev)
Resource locks (on‑chain via The Compact): ownerless ERC‑6909 escrow that enables optimistic “fill first, claim later” with strong anti‑double‑spend guarantees. (rhinestone.dev)

Crucially, Rhinestone defines a legible multi‑chain EIP‑712 envelope so one signature can authorize multi‑leg, multi‑chain flows while keeping each chain’s validation scoped and human‑readable. (docs.rhinestone.dev)

Intents resemble ERC‑4337 userops—but are native to cross‑chain execution, use a solver market, and can be funded/sponsored in arbitrary tokens. That’s why intents deliver lower latency and deterministic outcomes (known output token, zero slippage at fill) when paired with the right settlement layer. (docs.rhinestone.dev)

The execution backbone: settlement layers you can rely on

A modern engine should integrate multiple settlement layers through adapters. Two to prioritize:

Across Settlement (Risk Labs): production modular settlement for cross‑chain intents. Optimistic, aggregates verification/replayments, offers relayer repayment on their chain of choice. Public metrics show <$1 ETH bridge, <1 min average fill, 22B+ volume. (across.to)
Eco/EcoCross Settlement: intents architecture with RFQ, relayer competition, optimistic off‑chain verification (UMA), repayment bundling and cross‑chain repayment mechanics. Useful as an additional rail and for redundancy. (docs.ecocross.tech)

Your engine’s Intent Router should dispatch each “chain‑token” leg to the most cost‑effective settlement adapter at runtime; Rhinestone’s Warp does this natively. (docs.rhinestone.dev)

Standards note: adopt ERC‑7683 order structs so your orders remain portable across UniswapX/Across‑compatible filler networks. It future‑proofs relayer liquidity and reduces integration costs. (erc7683.org)

Resource locks done right (and why they matter)

To achieve sub‑second fills on destination chains without waiting for origin finality, use on‑chain resource locks close to the user account—not in a bridge. With The Compact:

Users deposit any token; receive ERC‑6909 receipt tokens representing locked resources. (rhinestone.dev)
Allocator sequences intents against the user’s locked balance and co‑signs when fully funded, preventing double‑spend. (rhinestone.dev)
Arbiter processes claim transactions post‑fill. Emissary guarantees irrevocability when smart accounts rotate keys (a key risk with non‑EOA signatures). (rhinestone.dev)
Escape hatch lets users withdraw all funds with a time delay if off‑chain components misbehave. (rhinestone.dev)

This model drives “fill now, claim later” and lets solvers optimize for price and gas asynchronously—one of the biggest real‑world savings levers at scale. Circle Gateway shows a similar “unified balance” pattern for USDC with instant destination mints off a locked balance. (rhinestone.dev)

Account layer: modular by default, smart EOAs optional

Build on ERC‑7579 modular smart accounts so you can plug validators (passkeys, multisig), executors, hooks, and fallback handlers—and reuse modules across vendors. Use the Module Registry (ERC‑7484) pattern to gate unknown modules by security attestations. (ercs.ethereum.org)
For existing EOA users, upgrade flows with EIP‑7702: keep the same address, attach programmable logic, and enable sessions/permissions. Rhinestone’s SDK supports “smart EOAs,” but understand limitations (no true multisig; root key remains the EOA). (docs.rhinestone.dev)
Session keys: adopt Smart Sessions (Rhinestone+Biconomy) to scope spending limits, targets, expiries across chains with a single signature—great for one‑click UX and safe automation. (rhinestone.dev)

Reference architecture (wallet + intents)

Client signs a single EIP‑712 intent (legible, multi‑chain).
Orchestrator simulates, splits into chain‑token legs, enforces resource lock (if enabled), and publishes to the relayer market.
Solvers fill on destination chain(s); Intent Router executes destination hooks with user’s account as msg.sender.
After fill, solvers claim on origin(s) via settlement adapters; user’s lock is decremented in Compact. (docs.rhinestone.dev)

Under the hood: if the user is an EOA, use EIP‑7702 delegation for batched atomic actions; if a smart account, keep ERC‑4337 compatibility and offer wallet_sendCalls to dapps for first‑class batching. (docs.rhinestone.dev)

Practical example A: “One‑signature, cross‑chain pay + swap + action”

Goal: user has USDC on Base; wants an Aave supply on Arbitrum, paying all costs from USDC—no ETH, no manual bridge.

User signs an EIP‑712 intent with:
- Inputs: {chainId: Base, token: USDC, amount: 500}
- Destination: {chainId: Arbitrum, actions: [swap USDC→WETH at price X, supply to Aave]}
- Max fee and deadline; replay nonce; per‑chain subhashes for legibility. (docs.rhinestone.dev)
Orchestrator selects Across Settlement for Base→Arbitrum.
Solver fills on Arbitrum: front‑runs liquidity, executes swap, calls Aave with user’s account as msg.sender (no approvals lost to “router” addresses).
Claim bundles repay the solver on Base (or solver’s chain of choice), pulling from the user’s resource‑locked USDC and batched with other intents for gas efficiency. Result: deterministic output, no slippage, near‑instant UX on Arbitrum. (across.to)

Implementation details:

Use Rhinestone’s Intent Router adapter for Across; use ERC‑7683 order encoding so other fillers can interop later.
Sponsor gas universally: pre‑fund a dev account on Base and sponsor gas/bridge/swap across chains via the intent system. (docs.rhinestone.dev)

Practical example B: “Smart EOAs + session keys for recurring AI‑agent payments”

Goal: keep users on their EOA, but enable a trading assistant to operate within tight guardrails.

EIP‑7702 authorization (type‑4 tx) delegates the EOA to a minimal smart‑account implementation for batched calls and validation hooks. (blockeden.xyz)
Install Smart Sessions policy: limit daily spend to 200 USDC, restrict to two contracts, 7‑day expiry; enable multichain scope with one signature. (docs.rhinestone.dev)
Agent submits intents gaslessly; solvers fill and get repaid via settlement. If user revokes or rotates keys, The Compact’s Emissary ensures a fallback irrevocable signature so fillers aren’t rugged by key‑rotation. (rhinestone.dev)

Practical example C: “Omnichain swap with deterministic output”

Rhinestone’s Warp supports multi‑input intents (e.g., USDC on Base + WETH on Optimism) authorized by a single EIP‑712. Each leg can route to distinct settlement rails for best price, then execute destination hooks atomically. This collapses “bridge → swap → action” into one flow, still fully legible to the signer. (docs.rhinestone.dev)

UniswapX can complement your filler set for same‑chain swaps using RFQ/Dutch auctions with MEV‑protected fills; pair it with Across/Eco for cross‑chain legs. (docs.uniswap.org)

Emerging best practices (what to implement in 2025–2026)

Architecture and standards

Adopt ERC‑7683 order structs across your adapters; don’t invent a proprietary intent format. It’s the fastest way to tap universal filler liquidity. (erc7683.org)
Use ERC‑7579 accounts and Module Registry (ERC‑7484) to manage third‑party plugin risk and keep portability across wallet vendors. (ercs.ethereum.org)
Expose EIP‑5792 wallet_sendCalls for dapps; support atomicity negotiation and capability discovery. (eips.ethereum.org)

Latency and UX

Target <2s median fills on L2 and <12s on L1 for most order sizes; optimistic verification handles repayment later. Across/Eco architectures are purpose‑built for that. (across.to)
Use legible EIP‑712 envelopes; prohibit opaque calldata blobs for signatures. Rhinestone’s multi‑chain EIP‑712 envelope is a strong pattern. (docs.rhinestone.dev)

Security and correctness

Prefer on‑chain resource locks (The Compact) over always‑on co‑signers; co‑signers introduce liveness/censorship risk. Use Allocator/Arbiter/Emissary splits and keep escape hatches. (rhinestone.dev)
For concurrency, adopt plugin‑specific nonces/lanes (RIP‑7712) to avoid replay and enable parallel UX (e.g., scheduled payments vs. manual trades). (docs.erc4337.io)
Keep ERC‑4337 compatibility and follow ERC‑7562 validation rules; if you run a bundler/paymaster, track ERC‑7769 RPCs for better ops. (docs.erc4337.io)
MEV hygiene: use RFQ/private orderflow and fade penalties (as in UniswapX V2) to reduce race conditions and failed fills. (docs.uniswap.org)

Operations and monitoring

Measure: intent acceptance latency, fill latency, deterministic output rate, settlement repayment delay, solver fade/penalty rates, allocator queue depth, and escape‑hatch use.
SLO guidance: 99% intents confirmed under 15s on L1, 3s on L2; 95% repayments within 90–120 minutes (optimistic window). (docs.ecocross.tech)

Compliance and resiliency

Multi‑rail settlement: have at least two independent adapters (e.g., Across + Eco/EcoCross) and failover heuristics. (across.to)
Vendor‑agnostic signers: support passkeys, MPC, and ECDSA; don’t assume a single wallet provider. Rhinestone’s ecosystem shows how to keep this modular. (docs.rhinestone.dev)

Brief implementation guide (concrete steps)

Model your intent schema on ERC‑7683 and Rhinestone’s EIP‑712 envelope

Required fields: origin(s), destination(s), assets, min‑out(s), deadlines, replay nonce, per‑leg hooks, and per‑chain subhashes for legibility. (erc7683.org)

Stand up an Orchestrator service

Balances indexer, router, simulator, adapter manager, and resource‑lock enforcer. Keep a read‑only trust boundary: the Orchestrator must only act through on‑chain Intent Router and Compact flows; users can always escape on‑chain. (docs.rhinestone.dev)

Integrate two settlement adapters

Across first for maturity and breadth; add Eco/EcoCross, Relay, or Wormhole Settlement for coverage and redundancy. Keep per‑token, per‑chain cost/latency models. (across.to)

Add account abstraction and sessions

ERC‑7579 modules for passkeys/multisig/recovery; Smart Sessions for scoped delegation and automation; optional EIP‑7702 path for existing EOAs. (eips.ethereum.org)

Ship wallet_sendCalls and sponsor fees

Expose EIP‑5792 to partners; implement a universal gas sponsor (e.g., holding USDC on Base to fund gas/bridge/swap anywhere via intents). (eips.ethereum.org)

Security hardening

Registry attestations for modules (ERC‑7484), continuous simulation (per‑chain), settlement challenge window monitors, and Emissary fallback for smart‑account signature irrevocability. (erc7579.com)

What “great” looks like (KPIs you can show executives)

1‑click cross‑chain actions with <2s median time‑to‑effect on L2s; deterministic output token and amount. (docs.rhinestone.dev)
99.9% signature legibility (EIP‑712) across flows, including multi‑chain envelopes. (docs.rhinestone.dev)
≥95% of solver fills repaid in a single bundled repayment cycle; <120‑minute mean repayment. (docs.ecocross.tech)
Session‑key adoption on 30–50% of active wallets; measurable drop in confirmation prompts and fail rates. (docs.rhinestone.dev)

Risks and how to mitigate them

Key rotation revoking a signed intent: mitigate with Emissary in The Compact; check both ERC‑1271 and ECDSA fallbacks. (rhinestone.dev)
Single‑provider fragility: dual‑home on Across + Eco/EcoCross; adapters should be hot‑swappable via Intent Router. (docs.rhinestone.dev)
Mempool censorship/latency: use RFQ/private orderflow; for ERC‑4337 paths, follow ERC‑7562 and track ERC‑7769 adoption by bundlers. (docs.uniswap.org)
Concurrency bugs: implement RIP‑7712 nonce lanes per plugin/session and document lane semantics in the wallet UI. (docs.erc4337.io)

Six‑week blueprint (from POC to pilot)

Weeks 1–2: Stand up Orchestrator, implement ERC‑7683 order + EIP‑712 envelope, add Across adapter, deploy Compact on testnet. (erc7683.org)
Weeks 3–4: Integrate Smart Sessions + ERC‑7579 modules; expose EIP‑5792; wire deterministic destination hooks (e.g., supply/borrow). (docs.rhinestone.dev)
Weeks 5–6: Add Eco/EcoCross adapter; run failover drills; shipping dashboards for fill latency, repayment lag, and solver fade penalties. (docs.ecocross.tech)

The strategic angle for startups and enterprises

Faster path to revenue: intents collapse multi‑step flows into one click, boosting conversion and reducing L2 support overhead.
Interop hedge: by speaking ERC‑7683 and routing via adapters, you’re not betting the farm on one bridge/settlement. (erc7683.org)
Talent leverage: teams build once on ERC‑7579 modules and reuse everywhere, including smart EOAs via EIP‑7702. (eips.ethereum.org)

At 7Block Labs, we implement this pattern end‑to‑end: ERC‑7579 account stacks, session policies, ERC‑7683 intent encoding, and multi‑rail settlement with Rhinestone‑style orchestration. If you want a pilot that your CFO will green‑light—and your users will actually love—this is the stack to ship in 2026.