Putting It Together: A 2025 Reference Stack (EIP-7702 + Intents + x402 + Private Proving)

Short summary: A concrete, production‑ready stack for 2025 that pairs EIP‑7702 smart EOAs, ERC‑7683 intents/OIF, HTTP‑402 payments (x402), and private proving—complete with architectures, code patterns, and rollout playbooks for startups and enterprises.

Why this stack, why now

In 2025, four threads finally snapped together: Ethereum’s Pectra hard fork activated EIP‑7702 on May 7, 2025, making smart‑wallet features native to EOAs; intent standards (ERC‑7683) moved from “papers and talks” to production via the Open Intents Framework; HTTP‑402 payments (x402) matured into practical API monetization; and private proving hit a usability inflection with client‑side and TEE‑backed options. Combine them and you get a stack that is safer, faster to ship, and measurably better for UX and margins. (theblock.co)

Layer 1 accounts: what EIP‑7702 actually gives you (and how to use it safely)

Pectra made EIP‑7702 live on mainnet, introducing a new type‑4 transaction with an authorization_list of tuples that let an EOA set a “delegation indicator” as its code: the EVM treats that EOA as executing the code of a target contract. This unlocks single‑tx batching, sponsorship, and fine‑grained sub‑permissions from any EOA—no ERC‑4337 migration required. (theblock.co)

Key details you should build around:

Transaction type: 0x04 (“set code”), with RLP‑encoded authorization_list entries: [chain_id, address, nonce, y_parity, r, s]. (eips.ethereum.org)
Delegation indicator: code 0xef0100 || address is written to the EOA; CALL/DELEGATECALL/STATICCALL on that EOA resolve and execute the code at address. (eips.ethereum.org)
Gas schedule: PER_AUTH_BASE_COST=12,500; PER_EMPTY_ACCOUNT_COST=25,000. First touch of a delegated cold account adds the EIP‑2929 cold read cost. (eips.ethereum.org)
Subtle behavior: CODESIZE/CODECOPY vs EXTCODESIZE/EXTCODECOPY differ during delegation; chains/loops of delegations are not recursively followed; precompile targets behave as empty code. (eips.ethereum.org)
Security gotcha: 7702 breaks the old “msg.sender != tx.origin implies contract” heuristic—in delegated execution you can have msg.sender == tx.origin deeper in the stack. Audit code paths relying on that assumption. (eips-wg.github.io)

Recommended delegate contract pattern (production‑grade guardrails):

Minimum spec: nonces, per‑selector allowlist, per‑token caps, and optional app‑scoped spending keys (EIP‑712 domain separation). (eips.ethereum.org)
Revocation path: expose revokeAll() and per‑scope revocations; users should also be able to “clear” the delegation indicator to restore a pure EOA (7702 includes a special case so you don’t pay a cold read forever). (eips.ethereum.org)
Sponsor‑safe: keep a distinct sponsor role for gas and ban CALLs to ETH‑transfering functions unless an allowlist passes. (eips.ethereum.org)

Example: a minimal delegate with per‑app allowance and selector filter

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

// 7702 delegate for one signer EOA.
// Hardened by: per-selector allowlist, per-token caps, sponsor separation.
// NOTE: Illustrative only; add full EIP-712 typed data, nonce mgmt, and events.

interface IERC20 { function transfer(address to, uint256 amount) external returns (bool); }

contract WalletDelegate {
    address public owner;              // the EOA whose code delegates here
    mapping(bytes4 => bool) public allowedSelector;
    mapping(address => uint256) public tokenDailyCap;
    mapping(address => uint256) public spentToday;
    uint256 public dayStart;

    modifier onlyOwner() { require(msg.sender == owner, "not owner"); _; }

    constructor(address _owner) { owner = _owner; dayStart = block.timestamp / 1 days; }

    function setAllowedSelector(bytes4 sel, bool ok) external onlyOwner {
        allowedSelector[sel] = ok;
    }

    function setTokenCap(address token, uint256 cap) external onlyOwner {
        tokenDailyCap[token] = cap;
    }

    function resetDay() internal {
        uint256 today = block.timestamp / 1 days;
        if (today > dayStart) { dayStart = today; spentToday[address(0)] = 0; } // zero marks ETH cap if used
    }

    // Example gated call: transfer ERC20 with 24h cap
    function safeTokenSpend(IERC20 token, address to, uint256 amt) external onlyOwner {
        require(allowedSelector[this.safeTokenSpend.selector], "selector blocked");
        resetDay();
        uint256 cap = tokenDailyCap[address(token)];
        if (cap > 0) { require(spentToday[address(token)] + amt <= cap, "cap exceeded"); }
        require(token.transfer(to, amt), "transfer fail");
        spentToday[address(token)] += amt;
    }

    function revokeAll() external onlyOwner {
        // offchain: send 7702 tx to set delegation indicator to "cleared"
        selfdestruct(payable(owner));
    }
}

This pattern gives your product team what they need (batching approvals + swaps, sponsored gas, session keys) without adopting a whole new account system. It’s also immediately compatible with ERC‑7683 solvers (below) that just need a reliable, auditable call surface. (eips.ethereum.org)

The “intent” layer: ERC‑7683 + OIF as the cross‑L2 lingua franca

Intents flip UX from “how to do something” to “what outcome the user wants.” In February 2025, ecosystem contributors launched the Open Intents Framework (OIF), rallying L2s and infra teams around a shared approach, with ERC‑7683 providing the standard order/settlement interfaces for cross‑chain intents. Across and Uniswap co‑authored 7683; there are production contracts and reference solvers you can deploy today. (coindesk.com)

What 7683 standardizes (and why it matters):

Order structs and settlement interfaces that let fillers/solvers interoperate across protocols and chains, reducing relayer fragmentation and improving competition for fills. (eips.ethereum.org)
A resolve view and ResolvedCrossChainOrder type so fillers can validate orders without bespoke decoding of arbitrary orderData blobs. (erc7683.org)
Permit2 “witness” signing as the canonical way to couple token approvals with an order signature—one user signature, fewer footguns. (erc7683.org)

Proof it’s real:

AcrossOriginSettler (IOriginSettler for 7683) is deployed on Base and Arbitrum; you can bridge 10 USDC Base→Arbitrum using the standard today. (erc7683.org)
OIF published an open solver implementation (TS) and reference infra anyone can fork to monitor events, submit txs, and rebalance. (openintents.xyz)

Where 7702 fits: your EOA signs a 7683 order (with Permit2 witness) and submits a 7702 tx that delegates to a hardened wallet contract which batches the on‑origin approval, emits the open event, and optionally sponsors gas. You get one‑click UX without migrating to a new account model. (eips.ethereum.org)

Privacy‑aware routing: If your order discovery/execution should be private, plan a SUAVE path for encrypted mempool and MEV‑aware routing as it matures in production. (flashbots.net)

Money in and out: x402 (HTTP‑402) for pay‑per‑API, agents, and services

For the first time, HTTP 402 (“Payment Required”) is practical: x402 defines how servers advertise prices, how clients carry payment proofs in the X‑PAYMENT header, and how a facilitator verifies/settles with on‑chain transactions—no accounts, OAuth, or custom signatures required. It’s chain‑agnostic by design and explicitly separates your API from on‑chain plumbing. (github.com)

What to know before you integrate:

Protocol roles and headers: resource server returns 402 + PaymentRequirements JSON; client replies with X‑PAYMENT carrying a scheme‑specific payload; server verifies locally or via facilitator /verify and can echo tx details in X‑PAYMENT‑RESPONSE. (github.com)
Schemes and flows: the spec defines payload schemas (e.g., exact, upto, prepaid) and a recommended verify/settle workflow so you can trade off response latency vs. finality guarantees per endpoint. (github.com)
Current stack reality: early x402 examples lean on EVM “permit” flows (EIP‑2612/Permit2), which makes Base/USDC the path of least resistance—be mindful if you need Bitcoin or non‑EVM support. Community variants like L402 (Lightning+Macaroons) and h402 expand 402‑style auth/payments beyond EVM. (docs.lightning.engineering)

Avoiding single‑operator trust: if a centralized facilitator is a risk, look at decentralized facilitator prototypes with BFT consensus and standardized x402 APIs. This keeps settlement correctness independent of any one operator. (github.com)

Example: monetizing a model‑inference API with x402 (Express)

import express from "express";
import { paymentMiddleware } from "x402-middleware"; // see coinbase/x402 examples

const app = express();

// 1) Declare pricing: $0.002 per POST /infer (Base USDC by default in your facilitator config)
app.use(paymentMiddleware("0xYourSettlementAddress", { "/infer": "$0.002" }));

app.post("/infer", async (req, res) => {
  // If we get here, X-PAYMENT verified. Do the work:
  const output = await runInference(req.body.prompt);

  // 2) Optionally attach X-PAYMENT-RESPONSE with on-chain tx info (hash / block / explorer)
  res.setHeader("X-PAYMENT-RESPONSE", JSON.stringify({ txHash: "...", chainId: 8453 }));
  res.json({ ok: true, output });
});

app.listen(3000);

Operational tips:

Decide per‑endpoint finality: “upto” + immediate 200 for low‑value calls; “exact” + synchronous settle for high‑value actions. Track fraud ratios and tune. (github.com)
Token policy: start with USDC on Base (fast finality, cheap gas), add adapters as your customers demand chains/tokens. Document supported schemes in a .well‑known/x402.json. (github.com)
For BTC natives: offer L402 as an alternate “auth+payment” scheme under the same 402 handshake (Macaroons + Lightning invoice). (docs.lightning.engineering)
If you need non‑EVM chains today, evaluate h402 or compatible 402 variants that maintain schema compatibility while widening settlement backends. (h402.xyz)

Private proving: keep secrets on the device while proving compliance and correctness

A 2025‑ready proving strategy splits into three lanes:

Local/device proving for private inputs

RISC Zero ships full local proving (CPU/GPU, Metal/CUDA) and recommends local mode when inputs are private; remote “Bonsai” when they aren’t. (dev.risczero.com)
StarkWare’s new S‑two prover targets client‑side/mobile proving—browser/phone proofs in public alpha reduce server‑side exposure and enable privacy‑preserving UX. (cointelegraph.com)

TEE‑backed prover networks for privacy with elasticity

Succinct introduced “Private Proving” combining its prover network with TEEs; upgrade all SP1 users to “SP1 Turbo” after January 27, 2025 security advisories. Bake version‑pinning and auto‑rotation into your CI/CD. (blog.succinct.xyz)

Distributed/community proving for cost and resilience

Research/PoCs show orchestration layers can marshal heterogeneous commodity GPUs for ZK workloads at performance near centralized fleets—useful for bursty intent settlement or periodic compliance proofs. (arxiv.org)

Performance isn’t theory anymore: WebGPU‑accelerated stacks (e.g., Plonky2 WASM builds) and mobile benchmarks demonstrate multi‑second proofs on commodity devices; keep a browser‑capability check with progressive fallback to remote provers. (github.com)

Privacy meets payments: combine x402 with ZK assertions in the request body—e.g., “client holds a KYC credential signed by X, age ≥ 18” or “model inference followed policy Y”—so the resource server checks X‑PAYMENT and verifies the proof without seeing raw PII or model internals. As SUAVE‑like private orderflow matures, route intent fills without leaking strategy. (github.com)

Reference architecture (what we ship for clients)

User wallet (EOA)
- Signs a 7683 order (with Permit2 witness), and a 7702 tx that delegates to WalletDelegate for this session (or persistent install + periodic rotation). (erc7683.org)
WalletDelegate (on L1 or origin L2)
- Batches: approvals + open() + optional sponsor. Emits event(s) consumed by solver network. (eips.ethereum.org)
Intents layer
- OIF reference solver + AcrossOriginSettler on origin; settlement contract on destination; optional SUAVE for private routing. (openintents.xyz)
Payments/API layer
- x402 middleware on resource servers; facilitator cluster (or decentralized facilitator) to verify/settle; header contracts for audit. (github.com)
Proving layer
- Local (WebGPU/Mobile) where inputs are sensitive; TEE or remote cluster otherwise; standardized verifier contracts and proof receipts logged alongside business events. (dev.risczero.com)

Rollout plan: 30/60/90

Days 0–30 (pilot)
- Upgrade toolchain for Pectra (compiler target “prague”), integrate a minimal WalletDelegate, and launch an internal 7683 solver connected to AcrossOriginSettler on Base/Arbitrum testnets. Add x402 in front of noncritical endpoints with “upto” pricing. Begin local proving PoC in the browser with WebGPU and a small credential‑check circuit. (blockeden.xyz)
Days 31–60 (limited GA)
- Push 7702 delegates to mainnet with per‑selector allowlists; ship your first cross‑L2 user journey behind 7683; gate an LLM endpoint with x402 + exact flow for high‑value calls; add fallback to facilitator /verify when load spikes. Start SP1 Turbo or Bonsai integration for heavier proofs. (github.com)
Days 61–90 (scale and harden)
- Add decentralized facilitator or BFT‑replicated verifier; introduce SUAVE routing for sensitive intents; run red‑team on msg.sender/tx.origin assumptions; publish your 402 schemas and on‑chain addresses in a .well‑known catalog. (github.com)

Emerging best practices (what’s working across teams)

Treat 7702 delegation as software you ship, not a one‑off script. Version, audit, and rotate your delegates. Provide an in‑app “reset to pure EOA” button. (eips.ethereum.org)
Use ERC‑7683 as your default cross‑chain API; only build custom paths when the standard can’t express your constraints. Keep orderData typed and minimal; rely on resolve() for fillers. (eips.ethereum.org)
Price endpoints explicitly with x402 and test three SKUs per resource: prepaid (credits), exact (strict), and upto (elastic). Measure time‑to‑first‑byte vs. fraud and pick per endpoint. (github.com)
Keep a “privacy budget” rubric: local proving for PII, TEE proving for enterprise‑sensitive logic, public prover network for generic workloads. Lock prover versions; subscribe to advisories (e.g., SP1 Turbo). (blog.succinct.xyz)
If you have BTC‑native users or agents, expose L402 side‑by‑side with x402 under the same 402 negotiation to avoid forking your gateway. (docs.lightning.engineering)

Risks to acknowledge (and how to mitigate)

7702 persistence and subtle EVM semantics: you can accidentally over‑privilege delegates, and code‑reading vs. executing opcodes diverge under delegation. Enforce per‑selector guards; fuzz CODESIZE/EXTCODESIZE logic; ship one‑tap revocation. (eips.ethereum.org)
Solver trust and settlement: ERC‑7683 delegates security evaluation of settler contracts to the app and filler—standardize internal due diligence and rate‑limit orders until you build confidence. (eips.ethereum.org)
Payments verification: don’t rely on a single facilitator; run two independent verifiers or adopt a BFT facilitator; record X‑PAYMENT‑RESPONSE metadata for audit. (github.com)
Prover supply chain: pin versions and implement canary verification; upgrade policies for SP1/Turbo or RISC Zero releases; keep fallbacks from local→TEE→remote. (blog.succinct.xyz)

A brief, end‑to‑end example (tying it all together)

A user wants “Swap 10 USDC on Base → receive WETH on Arbitrum,” then call your paid /infer endpoint with the result:

The wallet signs a 7683 order (Permit2 witness) and sends a 7702 tx installing your WalletDelegate. The delegate batches an approval and open() on the origin settler. (erc7683.org)
A solver fills cross‑chain using AcrossOriginSettler → SpokePool, then executes the destination action (swap to WETH). (docs.across.to)
Your app calls /infer with X‑PAYMENT carrying an x402 “exact” payment payload for $0.002; the facilitator verifies and returns tx details in X‑PAYMENT‑RESPONSE. (github.com)
The browser produces a ZK proof (WebGPU) that the prompt conformed to policy Y without leaking the prompt; server verifies the proof and returns the inference. (github.com)

This flow is shippable today on Base/Arbitrum with mainstream tooling, and extends cleanly to private routing (SUAVE) and non‑EVM payments (L402) as your roadmap demands. (flashbots.net)

Final take

For decision‑makers, the 2025 reference stack isn’t speculative: EIP‑7702 is live, ERC‑7683/OIF are deployable, x402 turns fees into headers, and private proving now fits real product constraints. Teams adopting this stack keep their options open (multi‑chain, multi‑prover, multi‑payment), while delivering concrete wins—1‑click UX, measurable latency drops, and new revenue lines from API endpoints—without betting the company on any single vendor or standard. (theblock.co)