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

Short Summary:
We're getting ready for 2025 with a solid, production-ready stack! This includes EIP-7702 smart EOAs, ERC-7683 intents/OIF, HTTP-402 payments (x402), and a focus on private proving. We've got everything laid out--architectures, code patterns, and rollout playbooks--perfect for both startups and enterprises.

Why this stack, why now

In 2025, everything finally came together with four major advancements. First up, Ethereum's Pectra hard fork rolled out EIP‑7702 on May 7, 2025, making smart-wallet features a built-in part of EXOs. Then we saw intent standards (ERC‑7683) make the leap from just being discussed in papers and talks to actually being put into action with the Open Intents Framework. Plus, HTTP‑402 payments (x402) really hit their stride, turning into a handy way to monetize APIs. And let’s not forget about private proving, which reached a tipping point in usability, thanks to client-side and TEE-backed options. When you put all these pieces together, you end up with a tech stack that's not just safer but also quicker to roll out, and it definitely improves user experience and profit margins. (theblock.co)

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

Pectra just rolled out EIP‑7702 on the mainnet, and it’s a game changer! They've introduced a new type of transaction--type 4--which comes with an authorization list of tuples. This nifty feature allows an Externally Owned Account (EOA) to set what's called a “delegation indicator” in its code. Basically, the Ethereum Virtual Machine (EVM) treats that EOA as if it's executing the code of a target contract.

What does this mean for you? Well, you can now enjoy single-transaction batching, sponsorship, and even fine-tuned sub-permissions right from any EOA. Plus, you don’t need to worry about migrating to ERC‑4337. It's a pretty smooth upgrade! Check out more details over at theblock.co.

Key Details You Should Build Around

Transaction Type: You're dealing with a 0x04 (“set code”) transaction. Just so you know, the authorization list entries are RLP-encoded and include: [chain_id, address, nonce, y_parity, r, s]. For more details, check out this link: EIP 7702.
Delegation Indicator: Look for the code 0xef0100; this is what indicates delegation. The address gets written to the EOA, and when you do a CALL/DELEGATECALL/STATICCALL to that EOA, it resolves and executes the code at the specified address. Learn more about it here: EIP 7702.
Gas Schedule: The costs you’ll want to remember are PER_AUTH_BASE_COST at 12,500 and PER_EMPTY_ACCOUNT_COST at 25,000. Just a heads up: if you’re touching a delegated cold account for the first time, it’ll incur the EIP‑2929 cold read cost as well. Get the full breakdown here: EIP 7702.
Subtle Behavior: There's some interesting behavior around CODESIZE/CODECOPY compared to EXTCODESIZE/EXTCODECOPY during delegation. Also, keep in mind that chains or loops of delegations won’t be recursively followed, and precompile targets act like they’re empty code. More info can be found at: EIP 7702.
Security Gotcha: Here’s a crucial point to note: EIP 7702 messes with the old rule that said “msg.sender != tx.origin implies contract.” In delegated execution, it’s possible for msg.sender to equal tx.origin even deeper in the call stack. Make sure you audit any code paths that depend on that assumption! Read more here: EIP 7702 Security.

Recommended Delegate Contract Pattern (Production‑Grade Guardrails)

Minimum spec: Make sure you’ve got nonces, a per-selector allowlist, per-token caps, and maybe throw in some app-scoped spending keys for good measure (we’re talking EIP‑712 domain separation here). Check it out here.
Revocation path: It’s important to have a way to revoke access. Include a revokeAll() function and allow for per-scope revocations. Plus, give users the option to “clear” the delegation indicator to go back to a plain old EOA. The magic of EIP‑7702 means you won’t be stuck paying for a cold read forever! More details are available here.
Sponsor-safe: Keep things secure by having a separate sponsor role for gas, and make sure to ban CALLs to ETH-transferring functions unless they pass an allowlist. You can dive deeper into this here.

Example: A Simple Delegate with Per-App Allowance and Selector Filter

Here’s a straightforward example of how to set up a minimal delegate that uses per-app allowances and a selector filter.

import Foundation

class AppDelegate: UIResponder, UIApplicationDelegate {
    
    var window: UIWindow?
    
    // This function is called when the app launches.
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Initialize your app here
        return true
    }
    
    // This function receives events from the delegate.
    func application(_ application: UIApplication, handleEvent event: SomeEvent) {
        // Handle the event based on the app
        let appIdentifier = event.appIdentifier
        if isAllowedApp(appIdentifier) {
            // Process the event
        }
    }
    
    // Check if the app is allowed to perform certain actions
    func isAllowedApp(_ appIdentifier: String) -> Bool {
        let allowedApps = ["com.example.app1", "com.example.app2"]
        return allowedApps.contains(appIdentifier)
    }
}

This code snippet shows a basic structure where you can handle app-specific events, ensuring only the allowed apps can trigger certain actions. Just adapt the allowedApps array to fit your needs!

// 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 provides your product team with everything they require--like batching approvals and swaps, sponsored gas, and session keys--without the hassle of implementing an entirely new account system. Plus, it works seamlessly with ERC‑7683 solvers (see below) that only need a dependable, auditable call surface. Check it out here: (eips.ethereum.org)

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

Intents really shake up the user experience by shifting the focus from “how do I do this?” to “what do I actually want to achieve?” Back in February 2025, some amazing folks in the ecosystem came together to launch the Open Intents Framework (OIF). This was all about getting L2s and infrastructure teams on the same page with a unified approach. They introduced ERC‑7683, which lays out the standard order and settlement interfaces for handling cross-chain intents. By the way, Across and Uniswap teamed up to co-author 7683, and you can even find production contracts and reference solvers ready for deployment right now. Check it out here: (coindesk.com).

What EIP-7683 Standardizes (and Why It Matters)

It creates order structures and settlement interfaces that help fillers and solvers work together across different protocols and chains. This means less relayer fragmentation and gives a boost to competition for fills. You can check out the details here.
EIP-7683 introduces a resolve view and a ResolvedCrossChainOrder type, which allows fillers to verify orders without needing to decode all those tricky orderData blobs individually. Learn more about it here.
It also brings in Permit2 “witness” signing, which is the go-to method for linking token approvals with an order signature. This means just one user signature, which helps eliminate some common pitfalls. Dive deeper here.

Proof it’s real:

The AcrossOriginSettler (which is the IOriginSettler for 7683) is live on both Base and Arbitrum! You can easily bridge 10 USDC from Base to Arbitrum using the standard today. Check it out here: erc7683.org.
OIF has released an open solver implementation (in TypeScript) along with some reference infrastructure that anyone can fork. This allows folks to monitor events, submit transactions, and manage rebalances. Dive deeper by visiting: openintents.xyz.

Where 7702 fits

So, your Externally Owned Account (EOA) kicks things off by signing a 7683 order (with a Permit2 witness) and then sends over a 7702 transaction. This transaction delegates to a hardened wallet contract that handles a few things: it batches the on-origin approval, fires off the open event, and can even sponsor gas if you want.

This setup means you get that smooth one-click user experience without needing to switch to a whole new account model. Check it out here: (eips.ethereum.org)

Privacy-Aware Routing

If you want to keep your order discovery and execution under wraps, take the time to map out a SUAVE path. This is especially important for encrypted mempool and as MEV-aware routing continues to evolve in real-world applications. Check it out here: (flashbots.net).

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

For the first time ever, HTTP 402 (“Payment Required”) is actually something we can use: x402 lays out a clear way for servers to show prices, how clients can include payment proofs in the X-PAYMENT header, and how a facilitator can handle verification and settlements with on-chain transactions--without needing accounts, OAuth, or custom signatures. It’s designed to be chain-agnostic, making sure your API stays separate from the nitty-gritty of on-chain processes. Check it out here: (github.com)

What to Know Before You Integrate

Protocol roles and headers: When you call a resource server, expect it to respond with a 402 status code along with a PaymentRequirements JSON. Then, your client needs to reply with an X-PAYMENT header that contains a scheme-specific payload. The server will either verify this locally or through a facilitator using /verify, and it can send back transaction details in the X-PAYMENT-RESPONSE. For more info, check out the GitHub page.
Schemes and flows: The spec lays out various payload schemas, like exact, upto, and prepaid. Plus, it suggests a workflow for verifying and settling transactions, so you can balance response times against the guarantees of finality for each endpoint. You can dive deeper into the details on the GitHub page.
Current stack reality: Right now, the early x402 examples are leaning towards EVM "permit" flows (think EIP‑2612/Permit2), which means using Base/USDC is likely going to be your easiest route. Just a heads-up if you need support for Bitcoin or anything non-EVM. Also, there are community alternatives like L402 (which combines Lightning and Macaroons) and h402 that push 402-style authentication and payments beyond just EVM. For more context, take a look at this Lightning Engineering documentation.

Avoiding Single-Operator Trust

If relying on a centralized facilitator feels risky, consider checking out decentralized facilitator prototypes that use BFT consensus along with standardized x402 APIs. This approach helps ensure that settlement correctness isn't tied to any single operator. You can dive deeper into this on GitHub.

Example: Monetizing a Model-Inference API with x402 (Express)

So, you're looking to cash in on your model-inference API? Let's dive into how you can make that happen using x402 with Express.

What’s x402?

x402 is an awesome framework that lets you build and manage your APIs easily. It’s flexible and super handy for monetizing your services. If you're already familiar with Express, you'll feel right at home with x402.

Setting Up Your API

First, let's get everything set up. You'll want to make sure you have Node.js and npm installed, then you can start by installing x402. Open up your terminal and run:

npm install x402

Now, let’s create a basic server.

Basic Server Setup

Here’s a quick snippet to get your server up and running:

const express = require('express');
const x402 = require('x402');

const app = express();
const PORT = process.env.PORT || 3000;

app.use(express.json());

app.post('/api/inference', (req, res) => {
    // Your model inference logic here
    res.send('Inference result');
});

app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});

With this setup, you've got a basic Express server that'll respond to POST requests at the /api/inference endpoint.

Adding Monetization Features

Now, to monetize your API, you might want to consider a few different strategies:

Subscription Plans: Offer users different levels of access based on their subscription.
API Keys: Require users to authenticate with API keys.
Rate Limiting: Control how many requests users can make in a given time frame to manage server load.

Implementing API Keys

Let’s add a simple mechanism for API keys. You can generate keys for your users and store them in a database. For this example, we'll just hardcode a key for simplicity:

const VALID_API_KEY = 'your_secret_api_key';

app.use((req, res, next) => {
    const apiKey = req.headers['x-api-key'];
    if (apiKey && apiKey === VALID_API_KEY) {
        next();
    } else {
        res.status(403).send('Forbidden: Invalid API Key');
    }
});

Rate Limiting

To prevent abuse, adding rate limiting can be a game-changer. You can use a library like express-rate-limit:

npm install express-rate-limit

Then, set it up like this:

const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
    windowMs: 15 * 60 * 1000, // 15 minutes
    max: 100 // Limit each IP to 100 requests per windowMs
});

// Apply to all requests
app.use(limiter);

Conclusion

And there you have it! You’ve got a solid start on monetizing your model-inference API using x402 with Express. By incorporating API keys, rate limiting, and maybe even a subscription model down the road, you can effectively manage your API’s usage and start generating revenue.

Feel free to tweak and add your personal touch to the code to make it your own! Happy coding!

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: Go for “upto” + immediate 200 for low-value calls, and stick with “exact” + synchronous settle for higher-stakes actions. Keep an eye on fraud ratios and tweak as needed. (github.com)
Token policy: Kick things off with USDC on Base since it offers fast finality and low gas fees. As your customers start requesting different chains or tokens, add those adapters. Don’t forget to document the supported schemes in a .well-known/x402.json. (github.com)
For BTC natives: Provide L402 as an alternative “auth+payment” setup that fits right into the same 402 handshake (think Macaroons + Lightning invoice). (docs.lightning.engineering)
Non-EVM chains: If you’ve got needs for non-EVM chains right now, take a look at h402 or other compatible 402 versions that keep schema compatibility while expanding your settlement options. (h402.xyz)

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

A strategy that’s ready for 2025 breaks down into three key areas:

Local/Device Proving for Private Inputs

RISC Zero has got you covered with full local proving options (think CPU/GPU using Metal/CUDA). They suggest going local when your inputs are private and using the remote “Bonsai” mode when they’re not. Check it out here.
StarkWare has rolled out their new S‑two prover, which is all about client-side and mobile proving. This means you can generate proofs right from your browser or phone--currently in public alpha. It minimizes server-side exposure and gives you a privacy-friendly user experience. More details can be found here.

2) TEE-Backed Prover Networks for Privacy with Elasticity

Succinct has rolled out an exciting feature called “Private Proving,” which merges their prover network with TEEs. After January 27, 2025, they’ll upgrade all SP1 users to “SP1 Turbo” following some important security advisories. To keep things running smoothly, make sure to incorporate version-pinning and auto-rotation into your CI/CD setup. Check out the details here.

Distributed/Community Proving for Cost and Resilience

Research and proof of concepts (PoCs) indicate that orchestration layers are capable of bringing together different types of commodity GPUs to handle Zero-Knowledge (ZK) workloads, achieving performance levels that are pretty close to centralized fleets. This can be super handy for those times when you need to settle bursty intents or run periodic compliance proofs. You can check out more about this here.

Performance is no longer just a concept: WebGPU-accelerated stacks, like Plonky2 WASM builds, and mobile benchmarks are now showing off multi-second proofs on everyday devices. Make sure to perform a browser capability check with a smooth fallback to remote provers. Check it out here: (github.com)

Privacy meets payments

You can blend x402 with ZK assertions right in the request body. For instance, you might say, “client holds a KYC credential signed by X, age ≥ 18” or “model inference followed policy Y.” This setup allows the resource server to check X‑PAYMENT and verify the proof without actually seeing any raw PII or the ins and outs of the model.

As we see SUAVE‑like private order flow getting better, routing intent can happen without any leaks about the strategy. Check it out here: (github.com)

Reference architecture (what we ship for clients)

User Wallet (EOA)
- Signs a 7683 order (with Permit2 witness) and sends a 7702 transaction that delegates to WalletDelegate for this session (or if you prefer, a persistent install with periodic rotations). Check out more here: (erc7683.org).
WalletDelegate (on L1 or origin L2)
- Handles batching: approvals, open() calls, and an optional sponsor. It emits events that the solver network picks up on. You can dive deeper into this at (eips.ethereum.org).
Intents Layer
- Uses an OIF reference solver alongside AcrossOriginSettler on the origin; there’s also a settlement contract on the destination, with an optional SUAVE for private routing. Find out more at (openintents.xyz).
Payments/API Layer
- Managed by x402 middleware on resource servers; includes a facilitator cluster (or a decentralized facilitator) to verify and settle transactions; and of course, there are header contracts for auditing purposes. Check the details on (github.com).
Proving Layer
- Local environments (like WebGPU or mobile) are used when the inputs are sensitive; otherwise, it’s TEE or a remote cluster. There are standardized verifier contracts and proof receipts that get logged alongside business events. More info can be found at (dev.risczero.com).

Rollout plan: 30/60/90

Days 0-30 (pilot)
- First off, we’re going to upgrade the toolchain for Pectra (that’s the compiler target “prague”), and get a basic WalletDelegate set up. We'll also roll out an internal 7683 solver that connects to AcrossOriginSettler on the Base and Arbitrum testnets. Don’t forget to add x402 in front of those noncritical endpoints, using “upto” pricing. Plus, we’ll kick off a local proving proof of concept in the browser with WebGPU and a simple credential-check circuit. Check out more details on this blockeden.xyz.
Days 31-60 (limited GA)
- Moving on, we’ll launch the 7702 delegates on the mainnet with some per-selector allowlists. Time to ship that first cross-L2 user journey behind the 7683 as well! We’ll also set up an LLM endpoint gated by x402 alongside an exact flow for those high-value calls, and don't forget to add a fallback to the facilitator /verify when things get busy. Now’s a great time to start integrating SP1 Turbo or Bonsai for those heavier proofs. More info can be found on github.com.
Days 61-90 (scale and harden)
- Finally, we’re adding a decentralized facilitator or a BFT-replicated verifier to beef things up. Let’s introduce SUAVE routing for those sensitive intents and run a red team check on the msg.sender/tx.origin assumptions. Oh, and we should publish our 402 schemas and on-chain addresses in a .well-known catalog too. For more insights, check out github.com.

Emerging best practices (what’s working across teams)

Think of your 7702 delegation like software you’re shipping, not just a one-off script. Make sure to version, audit, and rotate your delegates regularly. And how cool would it be to have an in-app “reset to pure EOA” button? That would save a lot of hassle! (eips.ethereum.org)
Go with ERC‑7683 as your go-to cross‑chain API. You should only create custom paths if the standard can’t handle your needs. Keep your orderData clean and simple; let resolve() do the heavy lifting for fillers. (eips.ethereum.org)
Clearly define your pricing endpoints using x402, and for each resource, test three different SKUs: prepaid (credits), exact (strict), and upto (elastic). Track how long it takes to get the first byte compared to fraud, and choose accordingly for each endpoint. (github.com)
Stick to a “privacy budget” framework: use local proving for PII, TEE proving for sensitive enterprise logic, and a public prover network for general workloads. It’s also a good idea to lock your prover versions and keep up with advisories, like SP1 Turbo. (blog.succinct.xyz)
If you’ve got BTC-native users or agents, make sure to showcase L402 right alongside x402 in the same 402 negotiation. This way, you won't end up forking your gateway. (docs.lightning.engineering)

Risks to acknowledge (and how to mitigate)

7702 persistence and subtle EVM semantics: There’s a chance you might accidentally give too many privileges to delegates. Also, keep in mind that reading code and executing opcodes can act differently under delegation. To stay safe, make sure to enforce per-selector guards, test out your CODESIZE/EXTCODESIZE logic with fuzzing, and consider rolling out a one-tap revocation feature. (eips.ethereum.org)
Solver trust and settlement: With ERC-7683, it’s all about how the app and filler handle the security checks for settler contracts. It's a good idea to standardize your internal due diligence processes and limit orders until you gain some confidence in the system. (eips.ethereum.org)
Payments verification: Don’t put all your eggs in one basket when it comes to facilitators. Using two independent verifiers or going for a BFT facilitator is a smarter move. Plus, make sure to log X-PAYMENT-RESPONSE metadata for easy audits down the road. (github.com)
Prover supply chain: Make sure to pin your versions and set up some canary verification. Keep your upgrade policies in check for SP1/Turbo or RISC Zero releases, and always have fallbacks that go from local to TEE and then to remote. (blog.succinct.xyz)

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

If you're looking to "Swap 10 USDC on Base and receive WETH on Arbitrum," you can go ahead and call your paid /infer endpoint with the result:

So, first off, your wallet goes ahead and signs a 7683 order (that's the Permit2 witness) and then sends a 7702 transaction to install your WalletDelegate. What this delegate does is batch the approval and open() on the origin settler. You can check out more details on this at (erc7683.org).
Next up, a solver takes care of the cross‑chain action using AcrossOriginSettler → SpokePool and then makes the swap to WETH at the destination. For more info, visit (docs.across.to).
Your app then makes a call to /infer with X‑PAYMENT sending an x402 “exact” payment payload for just $0.002. The facilitator checks everything out and sends back the transaction details in an X‑PAYMENT‑RESPONSE. If you want to dive deeper, check out the details here: (github.com).
Finally, the browser generates a ZK proof using WebGPU to show that the prompt followed policy Y without revealing any details about the prompt itself. The server gives the proof a thumbs up and sends back the inference. For the technical nitty-gritty, take a look at this link: (github.com).

You can totally ship this flow right now on Base/Arbitrum using popular tools. Plus, it easily adapts to private routing (SUAVE) and non-EVM payments (L402) whenever your roadmap calls for it. Check it out at flashbots.net!

Final take

For decision-makers, the 2025 reference stack is more than just a theory: EIP-7702 is already up and running, ERC-7683/OIF are ready to deploy, x402 is turning fees into headers, and private proving is fitting nicely within real product needs. Teams that are jumping on this stack can keep their options flexible--think multi-chain, multi-prover, multi-payment--while scoring some solid wins. We're talking about one-click user experiences, noticeable drops in latency, and fresh revenue streams from API endpoints, all without putting all their eggs in one basket when it comes to any single vendor or standard. (theblock.co)