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

Summary: In this post, we'll dive into how to create and launch a Rhinestone-style intent engine that works well with any chain for today’s wallets. We'll break down the nitty-gritty of the architecture--think orchestrators, relayer markets, resource locks, and adapters. Plus, we'll touch on the current standards like ERC‑7683, ERC‑7579, EIP‑7702, and EIP‑5792, along with some proven settlement layers. Our goal? Achieving a smooth, sub-second user experience on Layer 2s while ensuring deterministic results and robust security. Check it out here: (docs.rhinestone.dev)

Why intents now: the post‑Pectra wallet moment

Ethereum's Pectra upgrade, which went live on May 7, 2025, brought along EIP‑7702. This change allows Externally Owned Accounts (EOAs) to temporarily hand off execution to smart contracts. This simple tweak opens up a world of possibilities, letting existing wallet addresses batch calls, enable gas sponsorship, and function like programmable smart accounts--all without needing users to switch over. For wallet developers and B2B applications, this means they can offer a "smart EOA" experience with almost no onboarding hassle. Check it out at pectra.org!

Meanwhile, the ecosystem started to come together around standards that make cross-chain execution clear and easy to work with:

ERC‑7683 sets up a common order structure and settlement interfaces for cross‑chain intents, making it easier for different filler networks to work together. Check it out at erc7683.org.
ERC‑7579 is all about standardizing minimal modular smart accounts and modules. This approach helps prevent vendor lock‑in, all while staying compatible with ERC‑4337. You can read more on eips.ethereum.org.
EIP‑5792 rolls out wallet_sendCalls and related RPCs, enabling capability‑aware batching from dapps. You can dive into the details at eips.ethereum.org.

This all comes together to make “Rhinestone-style” chain abstraction totally practical right now: picture a wallet UX where users just need to sign one clear EIP-712 message. From there, solvers can go head-to-head off-chain, and when it’s time to settle up, we get them paid back in a trust-minimal way across different chains. Check it out here: docs.rhinestone.dev.

What “Rhinestone‑style intents” actually means

A Rhinestone-inspired engine is built around four key components:

Orchestrator (off-chain): Think of this as the smart middleman that routes your intents, puts together transactions, makes sure resources are locked down, and then sends everything off to the relayer market. Check it out here: docs.rhinestone.dev.
Relayer market: This isn't just any old market; it’s packed with competitive solvers offering inventory and access to DEX/OTC. It's not just one bundler doing everything, which is pretty cool. Dive into the details here: docs.rhinestone.dev.
Intent Router (on-chain): Picture this as an adapter-based dispatcher that can connect to various settlement layers and account modules. It’s like the glue holding everything together. More info can be found here: docs.rhinestone.dev.
Resource locks (on-chain via The Compact): These are ownerless ERC-6909 escrows that make the whole process smoother. They allow for an optimistic “fill first, claim later” approach while providing solid anti-double-spend protections. Want to learn more? Check it out here: rhinestone.dev.

Rhinestone is key here since it lays out a clear multi-chain EIP-712 envelope. This setup allows a single signature to kick off multi-leg, multi-chain processes, all while ensuring that the validation for each chain remains scoped and easy to read. Check it out for more details: (docs.rhinestone.dev)

Intents are kind of like ERC‑4337 user operations, but they've got some cool differences. They’re built for cross-chain execution, utilize a solver market, and can be funded or sponsored with any tokens you choose. Because of this, intents offer quicker response times and guaranteed outcomes (you know exactly what token you’ll get, and there’s no slippage when filling) when you pair them with the right settlement layer. Check it out: (docs.rhinestone.dev)

The execution backbone: settlement layers you can rely on

A modern engine should connect various settlement layers using adapters. Here are two that you should definitely focus on:

Across Settlement (Risk Labs): This is a modular settlement solution designed for cross-chain intents. It's got an optimistic approach that aggregates verification and replayments, plus it provides relayer repayment on the chain you choose. Public metrics are pretty impressive: we're looking at less than $1 in ETH for bridging, an average fill time of under a minute, and a whopping 22B+ in volume. Check it out here: across.to.
Eco/EcoCross Settlement: This one features an intents architecture that incorporates RFQ, encourages relayer competition, and uses optimistic off-chain verification (thanks to UMA). Plus, it offers repayment bundling and cross-chain repayment options. It's handy as an additional rail and adds some redundancy to the mix. More details can be found here: docs.ecocross.tech.

Your engine's Intent Router should send each “chain-token” leg to the most budget-friendly settlement adapter while it's running. Good thing Rhinestone’s Warp handles this out of the box! Check it out here: (docs.rhinestone.dev).

Standards Note

Make sure to adopt ERC‑7683 order structs so your orders stay portable across UniswapX and Across-compatible filler networks. This approach not only future-proofs your relayer liquidity but also helps cut down on integration costs. Check it out here: (erc7683.org)

Resource locks done right (and why they matter)

To get those sub-second fills on destination chains without hanging around for origin finality, it's best to use on-chain resource locks right by the user account instead of placing them in a bridge. With The Compact:

Users can deposit any token and receive ERC‑6909 receipt tokens, which represent the resources they've locked up. (rhinestone.dev)
The allocator takes the user’s locked balance and sequences intents, adding a co-sign when everything’s fully funded to keep double-spending at bay. (rhinestone.dev)
After a fill, the arbiter processes the claim transactions. Plus, the emissary ensures everything remains final, even when smart accounts switch up their keys (a significant risk if you're using non-EOA signatures). (rhinestone.dev)
There's also an escape hatch that lets users pull out all their funds after a brief time delay if the off-chain components start acting up. (rhinestone.dev)

This model is all about the “fill now, claim later” approach, allowing solvers to optimize for price and gas at the same time--this is one of the biggest ways to save in the real world when you're scaling up. Circle Gateway has a similar vibe, showing a “unified balance” pattern for USDC, with instant destination mints coming from a locked balance. Check it out here: (rhinestone.dev)

Account layer: modular by default, smart EOAs optional

Take advantage of ERC‑7579 modular smart accounts, which let you easily plug in validators like passkeys and multisig setups, alongside executors, hooks, and fallback handlers. Plus, you can reuse modules across different vendors. To keep things secure, use the Module Registry pattern from ERC‑7484 to restrict unknown modules with security attestations. Check it out here.
If you’re already using EOAs, EIP‑7702 is your ticket to seamless upgrades: you can stick with the same address while adding programmable logic, as well as enabling sessions and permissions. Rhinestone’s SDK backs up “smart EOAs,” but be aware of its limitations--like the fact that there's no true multisig and the root key is still your EOA. Dive deeper here.
For managing session keys, check out Smart Sessions offered by Rhinestone and Biconomy. They allow you to set spending limits, targets, and expirations across different chains with just a single signature. This is perfect for boosting user experience with one-click functionality and secure automation. Learn more about it here.

Reference architecture (wallet + intents)

The client kicks things off by signing a single EIP‑712 intent, which is clear and works across multiple chains.
Then, the orchestrator gets to work by simulating the process, breaking it down into chain-token legs, locking resources (if that’s enabled), and putting it out there on the relayer market.
Next up, solvers step in and take action on the destination chain(s); the Intent Router runs the necessary hooks with the user’s account as msg.sender.
Once everything is filled, solvers go back to the origin(s) to claim through settlement adapters, and the user’s lock is adjusted down in Compact. (docs.rhinestone.dev)

Under the hood, here’s how it works: If the user is an EOA, we use EIP‑7702 delegation for those batched atomic actions. On the flip side, if it’s a smart account, we stick with ERC‑4337 compatibility and provide wallet_sendCalls to dapps for that first-class batching experience. Check out more details here.

Goal:

You're holding USDC on Base and want to supply it to Aave on Arbitrum. The aim is to cover all the costs using USDC--no ETH needed and no manual bridge required.

The user kicks things off by signing an EIP‑712 intent with the following details:
- Inputs: {chainId: Base, token: USDC, amount: 500}
- Destination: {chainId: Arbitrum, actions: [swap USDC→WETH at price X, supply to Aave]}
- They also set a max fee, a deadline, a replay nonce, and some per‑chain subhashes to keep things clear. (docs.rhinestone.dev)
The orchestrator decides to go with Across Settlement for the Base to Arbitrum transfer.
The solver jumps in on Arbitrum: it front-runs the liquidity, executes the swap, and then calls Aave with the user’s account as the msg.sender--no worries about losing approvals to those pesky “router” addresses.
When it’s time to claim, the bundles repay the solver on Base (or whichever chain it prefers), tapping into the user’s resource‑locked USDC and batching it all up with other intents to save on gas. The result? A smooth, deterministic output with zero slippage and a lightning-fast experience on Arbitrum. (across.to)

Implementation details:

Go with Rhinestone’s Intent Router adapter for Across and stick to ERC‑7683 order encoding. This way, it’ll be easier for other fillers to play nice together down the line.
Cover gas costs across the board: let’s pre-fund a dev account on Base and take care of gas/bridge/swap expenses across chains using the intent system. Check out the details here: (docs.rhinestone.dev).

Goal: Keep Users on Their EOA, While Empowering a Trading Assistant to Operate Within Safe Boundaries

EIP‑7702 authorization (type‑4 tx) lets you delegate your externally owned account (EOA) to a super lightweight smart-account setup. This makes it easy to handle batched calls and validation hooks. You can read more about it here.
Next up, there’s the Smart Sessions policy you can install. It sets a daily spending cap of 200 USDC, limits usage to two contracts, and has a 7-day expiry. Plus, it supports multichain with just a single signature. Check out the details here.
When it comes to submitting intents, agents do this gaslessly. Then, solvers take care of filling them and get paid back through settlement. If you decide to revoke or rotate keys, The Compact’s Emissary has your back with an irrevocable fallback signature so that fillers won’t get left hanging during key-rotation. You can find more info here.

Rhinestone’s Warp lets you handle multiple input intents all in one go (like using USDC on Base and WETH on Optimism) with just a single EIP-712 authorization. Each part of the transaction can take different paths to secure the best price and then seamlessly trigger destination actions in one smooth step. It streamlines the whole process from “bridge → swap → action” into a single flow, while still keeping it clear for the signer. Check it out here: (docs.rhinestone.dev)

UniswapX is a great addition to your filler set for same-chain swaps. It utilizes RFQ/Dutch auctions and offers MEV-protected fills. You can also pair it with Across/Eco for any cross-chain legs you need. Check out the details here: (docs.uniswap.org)

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

Architecture and Standards

Make sure to use ERC‑7683 order structs in all your adapters; it’s really the quickest way to access universal filler liquidity. Check it out here: (erc7683.org).
Leverage ERC‑7579 accounts along with the Module Registry (ERC‑7484) to tackle third-party plugin risks and maintain portability across different wallet vendors. You can find more info here: (ercs.ethereum.org).
Don't forget to expose EIP‑5792 wallet_sendCalls for dapps! This way, you'll enable atomicity negotiation and capability discovery. More details can be found at: (eips.ethereum.org).

Latency and UX

Aim for those sweet spots: under 2 seconds for median fills on L2 and under 12 seconds on L1 for most order sizes. Optimistic verification helps us handle repayments later on. The Across/Eco architectures are specifically designed to nail this. Check it out over at across.to.
Keep it clear with readable EIP‑712 envelopes; let's steer clear of those opaque calldata blobs for signatures. Rhinestone's multi-chain EIP‑712 envelope sets a solid example of this approach. Learn more at docs.rhinestone.dev.

Security and Correctness

Opt for on-chain resource locks (The Compact) instead of always-on co-signers; relying on co-signers can lead to liveness/censorship issues. Make sure to use Allocator/Arbiter/Emissary splits and keep those escape hatches handy. (rhinestone.dev)
When it comes to concurrency, go for plugin-specific nonces/lanes (RIP-7712) to dodge replay attacks and provide a smoother parallel user experience--think scheduled payments versus manual trades. (docs.erc4337.io)
Stay on top of ERC-4337 compatibility and make sure to stick to ERC-7562 validation rules. If you’re running a bundler or paymaster, keep an eye on ERC-7769 RPCs so you can optimize your operations. (docs.erc4337.io)
For a clean MEV (Miner Extractable Value) approach, use RFQ/private order flow and implement fade penalties (like in UniswapX V2) to minimize race conditions and avoid failed fills. (docs.uniswap.org)

Operations and Monitoring

Metrics to Track: Keep an eye on intent acceptance latency, fill latency, deterministic output rate, settlement repayment delay, solver fade/penalty rates, allocator queue depth, and how often the escape hatch is used.
SLO Guidance: Aim for 99% of intents to be confirmed in under 15 seconds on L1 and 3 seconds on L2. Also, strive for 95% of repayments to be processed within an optimistic 90 to 120 minutes. Check out more details here.

Compliance and Resiliency

Multi-rail settlement: Make sure you’ve got at least two independent adapters (like Across + Eco/EcoCross) along with some solid failover heuristics. Check it out here: (across.to)
Vendor-agnostic signers: Your setup should support passkeys, MPC, and ECDSA. Don’t just rely on one wallet provider! The Rhinestone ecosystem offers a great example of how to keep things flexible and modular. Dive deeper here: (docs.rhinestone.dev)

Brief implementation guide (concrete steps)

Structure your intent schema based on ERC‑7683 and Rhinestone’s EIP‑712 envelope.

You’ll need to include these essential fields: origin(s), destination(s), assets, min‑out(s), deadlines, replay nonce, per‑leg hooks, and per‑chain subhashes for clarity. Check it out here: (erc7683.org).

2) Set Up an Orchestrator Service

This service is all about keeping things balanced between the indexer, router, simulator, adapter manager, and resource-lock enforcer. It's crucial to maintain a read-only trust boundary: the Orchestrator should only operate via the on-chain Intent Router and Compact flows. Plus, users always have the option to opt-out of on-chain. You can dive deeper into the details here.

Integrate two settlement adapters

Start with Across for its maturity and breadth; then add Eco/EcoCross, Relay, or Wormhole Settlement to enhance coverage and redundancy. Make sure to maintain those per-token, per-chain cost and latency models. Check it out at (across.to).

Introduce account abstraction and sessions

We’re looking at adding ERC‑7579 modules for things like passkeys, multisig setups, and recovery options; plus, Smart Sessions for scoped delegation and automation. There's also an optional EIP‑7702 path that supports existing EOAs. Check it out at (eips.ethereum.org).

Ship wallet_sendCalls and sponsor fees

Let’s roll out EIP‑5792 to our partners; we'll set up a universal gas sponsor (think holding USDC on Base to cover gas/bridge/swap costs wherever needed through intents). Check it out here: (eips.ethereum.org)

Security Hardening

We're talking about registry attestations for modules (ERC‑7484), continuous simulation for each chain, monitors for the settlement challenge window, and an Emissary fallback to ensure smart account signature irrevocability. Check out more details on this over at (erc7579.com).

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

Enjoy 1-click cross-chain actions with a median time-to-effect of less than 2 seconds on L2s, plus you get a guaranteed output token and amount. Check it out here.
We’re rocking 99.9% signature legibility thanks to EIP-712, which works seamlessly across various flows, including multi-chain envelopes. Learn more here.
More than 95% of solver fills are repaid all in one go during a single bundled repayment cycle, with a mean repayment time of under 120 minutes. Find all the details here.
Session-key adoption is seen in 30-50% of active wallets, leading to a noticeable drop in confirmation prompts and failure rates. Dive into the specifics here.

Risks and how to mitigate them

Key Rotation and Revoking Signed Intents: To handle this, you can use Emissary within The Compact. Just remember to check both ERC‑1271 and the ECDSA fallbacks to stay safe. (rhinestone.dev)
Single‑Provider Fragility: To avoid issues here, try dual-homing on Across and Eco/EcoCross. Also, make sure your adapters can be switched out easily using the Intent Router. (docs.rhinestone.dev)
Mempool Censorship and Latency: You’ll want to leverage RFQ or private order flow for this. When dealing with ERC‑4337 paths, keep an eye on ERC‑7562 and track how ERC‑7769 is being adopted by bundlers. (docs.uniswap.org)
Concurrency Bugs: To tackle these, introduce RIP‑7712 nonce lanes for each plugin or session, and don’t forget to explain lane semantics right in the wallet UI. (docs.erc4337.io)

Six‑week blueprint (from POC to pilot)

Weeks 1-2: Kick things off by setting up the Orchestrator, implementing the ERC‑7683 order and EIP‑712 envelope, adding the Across adapter, and deploying Compact on the testnet. Check out the details at (erc7683.org).
Weeks 3-4: Dive into integrating Smart Sessions and the ERC‑7579 modules. Don’t forget to expose the EIP‑5792 and wire up those deterministic destination hooks, like supply and borrow. You can find more info over at (docs.rhinestone.dev).
Weeks 5-6: Time to add the Eco/EcoCross adapter, run some failover drills, and roll out dashboards to monitor fill latency, repayment lag, and solver fade penalties. Check it out at (docs.ecocross.tech).

The strategic angle for startups and enterprises

Faster path to revenue: With intents, you can streamline those complicated multi-step processes into a simple click. This not only boosts your conversion rates but also lightens the load on your L2 support team.
Interop hedge: By using ERC‑7683 and connecting through adapters, you’re not putting all your eggs in one basket when it comes to bridges and settlements. Check it out here: (erc7683.org).
Talent leverage: Your team can build once using ERC‑7579 modules and then reuse that work everywhere -- even in smart EOAs, thanks to EIP‑7702. Get the details at (eips.ethereum.org).

At 7Block Labs, we're all about making this happen from start to finish: we’ve got ERC‑7579 account stacks, session policies, ERC‑7683 intent encoding, and multi‑rail settlement with that smooth Rhinestone-style orchestration. If you're looking for a pilot that your CFO will give the thumbs up to--and something your users will truly enjoy--this is the stack you want to roll out in 2026.