Agentic Finance

Main Paper

Agentic Finance: Changes brought by ERC-7710 and ERC-7715 to x402 and MPP — by 0xSky (Cofounder, HiggsPay) — 18 April 2026

Agentic commerce is a wallet- and smart-account–native way for agents to act on your behalf with scoped, revocable permissions and trust-minimised on-chain jobs and reputation.

Today, agentic finance is fragmented across bespoke contracts, vendor-specific session key schemes, and opaque reputation systems, making cross-application automation and safe AI agents hard to scale. The introduction of x402 (Coinbase, May 2025) and MPP (Stripe/Tempo, March 2026) brought programmable machine payments to the mainstream but also introduced a new layer of fragmentation. x402 is permissionless and crypto-native; MPP is session-based and fiat-compatible. ERC-7710 and ERC-7715 are the missing connective tissue. They give x402 a programmable permission layer it currently lacks, enabling scoped, time-bounded, rate-limited delegations that make x402 structurally comparable to MPP's session model, while remaining open, chain-agnostic and vendor-neutral.

• ERC-7710 — Smart Contract Delegation: Standard interface for a Delegation Manager that executes on behalf of a smart account under a permission context, enabling batched and policy-checked calls.
• ERC-7715 — Wallet permissions: JSON-RPC methods like wallet_grantPermissions / wallet_requestExecutionPermissions so dApps can request granular, time-bounded execution rights instead of unlimited approvals.

Mismatch against reality: Currently, only MetaMask has ERC-7710 and ERC-7715 in their wallets, and Biconomy is exploring a "fusion" of both ERCs with EIP-7702 and ERC-4337. Delegation on the wallet always has problems — over 95% of EIP-7702 delegations recorded on-chain are for phishing or wallet draining (Dune, Wintermute Research). Permission schemas are not consistent: spending caps, rate limits, and call scopes are interpreted differently across implementations, so a permission from Wallet A may not be enforceable by Wallet B.

Missing Pieces:

• End-to-end UX patterns: Standard wallet screens and design patterns for explaining permissions, delegation scopes, and revocation to non-technical users across different wallets.
• Shared permission schemas: Convergence on common permission and rule types (rate limits, spending caps, protocol-specific scopes) so multiple wallets and dApps interpret ERC-7715 permissions the same way.
• Safety frameworks on top of ERC-7710: Higher-level policies, audits, and tooling so app devs do not misconfigure Delegation Managers and accidentally grant overpowered capabilities.

MPP's session primitive deposits funds into escrow, issues cumulative signed vouchers per request, and settles in one on-chain transaction at the end. The same flow with open standards:

1. Session open — the wallet grants a time-bounded ERC-7715 permission: rate-limit of 5 USDC/hour, total erc20-token-transfer cap of 50 USDC, scoped to one smart account.
2. Per-request micro-payment — for each API hit, the agent's ERC-7710 Delegation Manager executes a small USDC transfer within the delegated cap; x402 receives the proof and returns the resource. While ERC-7715 manages the permission, the actual execution of multiple calls (like approve followed by swap) is handled via standards like EIP-5792 (wallet_sendCalls) or by redeeming permissions through a MetaMask Smart Account.
3. Session close — permission expires or is revoked via wallet_revokePermissions; unused allowance stays in the user's account automatically. No escrow refund contract is needed.

"If I had stayed out of jail, I would have been building AI agent payment rails. The primitives are all there — programmable accounts, stablecoins, HTTP-native settlement. The only thing missing is who controls the permission." — Sam Bankman-Fried, in a 2024 prison interview (paraphrased)

"The biggest question for crypto is whether AI will actually use it." — Sam Bankman-Fried, from prison, February 2026

From prison, SBF published a thread that framed a core problem: AI agents have no passport, no bank account, and no legal identity to pass KYC. Traditional finance is structurally unequipped to onboard non-human entities at scale. His argument: the agents most likely to use crypto aren't speculating on tokens — they are paying fractions of a cent for API calls, compute, and data, continuously, 24/7. x402 and MPP show the payment plumbing can work, but without a standard for who authorised the agent and within what limits, every platform re-invents its own permission model and users have no way to audit or revoke it. ERC-7710 and ERC-7715 are the Ethereum community's answer: put permission control back in the user's wallet.

1. Where Value Accrues in the Stack (and Where It Doesn't)

The critical insight from synthesising Pantera, Petersen (Delphi), a16z, Multicoin, and LongHash: value accrues at constraint points, not plumbing.

2. The TradFi Parallel Stack & Why It Doesn't Invalidate Crypto

Lane 1: Human-supervised agent commerce (McKinsey Levels 2–4). Agents shop on your behalf, you approve, payment settles on card rails. Visa TAP handles identity, Mastercard's Agentic Tokens carry credentials, Stripe abstracts everything behind PaymentIntents. Cards work fine here — consumers keep chargebacks, purchase protection, and rewards. No blockchain needed.

Lane 2: Fully autonomous agent commerce (Level 5+). Agent-to-agent transactions with no human identity to inherit, micropayments at fractions of a cent, conditional and programmable settlement. Card rails cannot serve this — 2–3% fees make $0.001 transactions uneconomic. This is where x402 + ERC-7710 + ERC-7715 are architecturally necessary.

Sequential blocker framework for timing (ERC-8004 is solving this): Phase 1 (today): Discovery is the binding constraint. Phase 2: Identity becomes binding once discovery exists. Phase 3: Reputation once identity is solved. Phase 4: Agent coordination once agents are capable enough.

Stripe is the bridge: x402 inside PaymentIntents via MPP gives merchants both lanes in one integration — the strongest proof x402 matters so far, and a big threat to crypto-native facilitators because merchants will pick Stripe over Dexter for settlement. Possible hard truth: most near-term value in agentic commerce goes to Visa, Mastercard, and Stripe, not crypto-native players. Crypto wins later, when Lane 2 reaches real scale — and that depends more on AI progress than crypto. Invest in the layer about to break, not the one already built.

3. How Stripe Supports x402 & Fiat Payment through MPP

x402: Agents can request the product they intend to pay for using Stripe's native payment_intents API, which returns the deposit address the agents need to pay and transfer to.

Traditional payment is supported using a Shared Payment Token (Stripe Agentic Commerce concepts). A shared payment token defines how much an agent is allowed to spend and the expiry date. Using the Agentic Commerce Platform (ACP), agents can create an agentic checkout session and complete payment seamlessly using API calls.

4. MetaMask Delegation Toolkit (ERC-7715 in the Wild)

MetaMask's Delegation Toolkit is the first real proof that ERC-7710 and ERC-7715 are not just EIPs but something hackers can ship with today.

4.1 What MetaMask actually shipped

• A Gator SDK that lets a dApp act as a session account and request permissions from a user's MetaMask wallet using wallet_grantPermissions (ERC-7715).
• A Gator Smart Account that lives inside MetaMask Snaps and becomes the delegator in ERC-7710, issuing delegations to the dApp's session account.
• A permission kernel + Gator permission snaps that show a Permission Picker UI, store permissions, and let users edit or revoke them.
• A first production-grade permission type: native-token-stream, effectively "stream X native token to this dApp under these limits."

4.2 Use Cases

Visa's recent Intelligent Commerce Connect is building similar plumbing on the payments rail side. MetaMask is doing it at the wallet level. Both point to a future where automated agents need bounded spending authority, not binary access.

4.3 How the flow maps to ERC-7710 + ERC-7715

1. Permission request (ERC-7715): The dApp (session account) calls wallet_grantPermissions and asks for a native-token-stream permission to its own address, including parameters like max amount, duration, and chain. MetaMask Flask + Snaps display a clear UI describing what the dApp wants to do.
2. User authorization + Gator account creation: If the user approves, the Gator Permissions Snap creates a Gator Smart Account for that user and prompts them to fund it with the native token they are willing to risk for that permission.
3. Delegation creation (ERC-7710): A delegation is created from the Gator Smart Account (delegator) to the dApp's session account (delegate), encoding which actions are allowed (e.g., transfer native token) and caveats (per-transfer max, frequency, expiry timestamp).
4. Permission redemption (delegated actions): When the dApp wants to stream funds, it redeems the delegation — building a transaction or ERC-4337 UserOperation that stays within the encoded caveats and submitting it via a bundler. The Delegation Toolkit validates the delegation and executes the call, without another wallet pop-up for every micro-payment.

4.4 Why this matters for x402 and MPP

MetaMask's Delegation Toolkit effectively implements the "wallet side" of what MPP calls a Shared Payment Token — but as open ERC-7715 permissions plus ERC-7710 delegations instead of a Stripe-owned token. It shows that: ERC-7715 can front a permission picker UI that normal users understand; ERC-7710 can enforce per-agent, per-session limits in a reusable Delegation Manager; and agentic payments don't have to be raw-key-driven or platform-custodied — they can be wallet-delegated and revocable at the protocol level.

• Brian Armstrong, CEO Coinbase — Authored x402, moved it to the Linux Foundation. Revenue play is Base network volume and USDC adoption, not protocol fees.
• Patrick Collison, CEO Stripe — Built MPP, supports x402, acquired Bridge ($1.1B stablecoin infra) and Metronome ($1B usage-based billing), co-incubated Tempo. Stripe processed $1.9T in 2025. Bet: enterprise won't go crypto-first, so Stripe builds the bridge.
• Matt Huang, Co-Founder Paradigm / CEO Tempo — Led Tempo's $500M raise at $5B valuation. Co-designed MPP. "We came up with the most elegant, minimal, efficient protocol anyone can extend without our permission."

1. Advanced Permissions requires a smart account. Can traditional EOAs use Advanced Permissions?
2. Other than the three main use cases — (i) automated and recurring flows (subscriptions, DCA, auto-compounding); (ii) agent-based execution (AI agents trade, rebalance, or act within user-defined boundaries); (iii) time-bound access (vesting schedules, scheduled executions, in-session game actions) — what other use cases can you think of?
3. We just discussed how most EIP-7702 delegations are used for phishing. What about the security of Advanced Permissions?
4. Is the session account holding user funds? How does execution actually happen?

• ACP (Agent Commerce Protocol): Stripe's protocol layer that lets AI agents discover what a merchant sells, create a checkout session, and complete payment entirely via API calls.
• Account Abstraction: Making wallets programmable so that rules, limits, and automation can be enforced at the wallet level rather than relying purely on private key signatures. See ERC-4337.
• Biconomy: An Ethereum infrastructure provider exploring a combined implementation of ERC-7710, ERC-7715, EIP-7702, and ERC-4337.
• Bridge: A stablecoin infrastructure company acquired by Stripe for $1.1B; handles stablecoin issuance, cross-border settlement, and fiat-to-crypto conversion.
• Bundler: In ERC-4337, a third-party service that collects UserOperations and submits them to the blockchain.
• Caveats: The constraints encoded into a delegation: per-transfer maximums, rate limits, expiry timestamps, and which tokens/contracts are in scope. The Delegation Manager enforces these on every call.
• Delegate: The entity that receives delegated permissions — typically a dApp's session account or an AI agent.
• Delegation: Giving another account the authority to act on your behalf within strict limits. In ERC-7710, an on-chain record specifying who can act, on whose behalf, and under what constraints.
• Delegation Manager: The smart contract that enforces delegations at execution time, checking caveats before allowing the call.
• Delegator: The entity that grants permissions — typically the user's smart account (e.g., MetaMask's Gator Smart Account).
• EAS (Ethereum Attestation Service): A protocol for issuing verifiable on-chain claims about an identity.
• EIP-5792 (wallet_sendCalls): A standard that lets dApps request a wallet to execute multiple contract calls in a single batch.
• EIP-7702: Allows a standard EOA wallet to temporarily behave like a smart contract by pointing to contract code — a bridge that lets regular wallets participate in ERC-7710/7715 delegation flows.
• EOA (Externally Owned Account): A standard Ethereum wallet controlled directly by a private key; has no programmable logic and needs EIP-7702 to participate in delegation flows.
• ERC-4337: Enables smart accounts on Ethereum without changing the core protocol; introduces UserOperations and Bundlers. Required infrastructure for ERC-7710 delegation execution.
• ERC-7710: Defines a standard interface for a Delegation Manager that executes actions on behalf of a smart account under a permission context (the execution side of delegated authority).
• ERC-7715: Defines the wallet methods (like wallet_grantPermissions) that let dApps request scoped, time-bounded permissions from a user's wallet (the request/UI side).
• ERC-8004: A proposed standard for an on-chain agent discovery registry — a phone book for AI agents. Singleton design (one registry per chain) means first-mover advantage is effectively permanent.
• Escrow: Funds held by a neutral smart contract until conditions are met. MPP uses escrow; ERC-7710's model avoids it — funds stay in the user's account and only move when a delegation is redeemed.
• Facilitator: In the x402 stack, an intermediary that handles payment processing on behalf of an agent. The paper identifies facilitators as a value trap — pure facilitation races to zero margins.
• Gas: The fee to execute operations on Ethereum. If gas costs $0.01 per transaction, a $0.001 payment is economically unviable — MPP's voucher-batching sidesteps this.
• Gator SDK / Gator Smart Account: MetaMask's developer toolkit and the smart account it creates for a user when they approve a delegation request (the delegator).
• Infinite Approval: A common DeFi pattern of approving a token contract for unlimited spending — dangerous if the contract is exploited. ERC-7715 replaces it with scoped, revocable permissions.
• KYC (Know Your Customer): Regulatory identity verification; structurally impossible for fully autonomous agents that have no legal identity.
• McKinsey Levels (1–5): A framework for AI agent autonomy. Levels 2–4 involve human supervision (card rails work fine); Level 5+ is fully autonomous (crypto rails become necessary).
• MPP (Machine Payment Protocol): A session-based payment protocol co-designed by Stripe and Tempo (March 2026); deposits funds into escrow, issues signed vouchers per request, and settles in a single on-chain transaction.
• Native Token Stream: The first production permission type in MetaMask's Delegation Toolkit — stream a chain's native token to a dApp at a defined rate and cap without per-payment prompts.
• Reputation System: A mechanism for answering "should I trust this agent?" — potentially the most valuable layer in the agentic stack and currently the least mature.
• Session Account: The dApp's own account that receives delegated permissions; the agent's spending identity, constrained to the user's limits.
• Shared Payment Token (SPT): Stripe's MPP primitive — a scoped, expiring token defining how much an agent can spend and to which merchant. The MPP equivalent of ERC-7715 permissions, but Stripe-controlled.
• Tempo: A new Layer 1 co-founded by Matt Huang (Paradigm), purpose-built for agentic payments; co-designed MPP with Stripe.
• UserOperation: The ERC-4337 equivalent of a transaction for smart accounts, submitted via a Bundler.
• Voucher (Signed Voucher): MPP's per-request payment mechanism; cumulative and batch-settled at session end, enabling sub-100ms latency and true micropayments.
• x402: An HTTP payment protocol proposed by Coinbase (May 2025), now stewarded by the Linux Foundation. Permissionless, crypto-native, and vendor-neutral — but lacks a native session and permission layer, which ERC-7710/7715 provide.
• 402 Challenge: The HTTP response a server sends when payment is required — the triggering mechanism for x402.