ERC-8427 integrations: what has been tested so far

When I first wrote about ERC-8427, the question was whether a capped, revocable spend grant is a useful object. A standard like this only matters if other things can use it. Since then I have tested the draft with Safe, ERC-4337, ERC-8004, and ERC-7710, and written a proposed mapping for x402. One outside contributor, ted0x on the Ethereum Magicians thread, has built a sixth integration on it.

This post says what each one does, what it is worth to an owner or an agent, and how much has actually been tested. All of it is a draft, none of it is audited, and nothing here is deployed outside a testnet. The status of each is stated plainly so you can judge it.

The repo is tankcdr/erc-spend-grants. The descriptions below match the repo as of commit b1ae6a7 on October 14, 2026.

The short version

Integration	What it connects	Status
Safe	A Safe multisig as the owner, the delegate, or both	Fork test against Safe v1.4.1 and the Arc testnet deployment
ERC-4337	A 4337 smart account as the delegate, with a paymaster paying gas	Fork test against EntryPoint v0.7 on Arc testnet
ERC-8004	A grant to the wallet of a registered agent identity	Fork test against the ERC-8004 Identity Registry on Arc testnet
ERC-7710	Redeeming a delegation through MetaMask's delegation framework	Fork test against DelegationManager v1.3.0 on Arc testnet; contracts not deployed
x402	An agent paying for web resources from the owner's funds	Proposal; Solidity model and TypeScript package tested against a local node; not registered with x402
Order amendments (ted0x)	Funding changes to an agent service order	Outside experiment on a local node, on a branch not yet merged

A fork test runs against contracts that are already deployed on Arc testnet, using the repo's pnpm test:fork command. None of the integration tests is part of the ERC bundle submitted to the ERC editors. They live under test/integrations/ and test/fork/.

What they build on

Every integration uses the same few pieces from the draft:

• The owner registers a grant on the registry and gets back a grantId. The delegate holds only that id.
• The executor checks who authorized each spend, so knowing the id is not enough to spend.
• check tells a caller why a spend would fail, and grantState shows what can be spent now.
• A delegate can authorize a spend by calling the executor, or by signing an authorization that anyone may submit.

The tests use the registry 0xe8987A22a1e3fd4a63cB517A9476B9d214388287 and executor 0xB99785329AbEc9936b6EF6350015be39D3392646 on Arc testnet. The tokens in the tests are mocks deployed inside the fork.

Safe as principal and as delegate

Safe is the multisig most teams already keep their treasury in. The Safe test deploys a 2-of-3 treasury Safe and a 2-of-2 agent Safe through the live Safe v1.4.1 factory and drives them with real Safe transactions.

How it uses ERC-8427. The treasury Safe is the owner. It registers, updates, and revokes grants through its normal execTransaction flow, so the signing threshold decides who can create or change a grant. Only the Safe can register its grants. A Safe owner who calls register from their own key gets NotPrincipal. The agent Safe is the delegate. Its owners sign an authorization that the executor validates with ERC-1271 and that a relayer submits.

What it is worth. A team can give an agent a budget from the treasury without moving the money, and the multisig threshold governs who can raise or cut it. The agent can itself be a multisig, so a spend needs the agent's own signers and not one key. In the test the Safe pays the vendor directly, with no Safe transaction per payment.

What the tests found.

• The agent Safe needs Safe's compatibility fallback handler set. Without it the authorization is rejected.
• Safe owners sign a wrapped message, not the raw authorization digest. Tooling that signs the digest as it would for a normal key produces a signature the Safe rejects.
• Safe reports any failed inner call as GS013, so a wallet that wants the real reason, such as a stale update, should simulate the inner call first.
• A Safe module or guard that lets something other than the owners call the registry can register grants. The treasury's module set is part of its grant policy.

Status. Fork test in the repo. Safe v1.4.1 only.

ERC-4337 smart account as delegate

ERC-4337 is the account abstraction standard behind most smart accounts. The 4337 test runs an eth-infinitism SimpleAccount v0.7 as the delegate and submits real UserOperations to EntryPoint v0.7 on Arc testnet.

How it uses ERC-8427. The account is the delegate. Its UserOperation calls the executor, and the executor sees the account as the caller. The funds move from the owner to the recipient and never touch the account.

What it is worth. An agent can be a smart account that holds no gas and no tokens. A paymaster sponsors its operations, and the money it spends comes from the owner's account under the grant's caps. The account can even be created by the same operation that makes the first payment.

What the tests found. The grant is checked when the operation executes, not when it is validated. If the owner revokes the grant or lowers a cap after the operation was signed, the operation still passes validation, fails in execution with the registry's reason, and the paymaster still pays for the gas. So a sponsor should call check before it agrees to pay. check is a read at one block, and four queued operations that each pass it can together exceed the window cap, so a sponsor also has to count what it has already accepted under the same grant.

Status. Fork test in the repo. The SimpleAccount in the test has no ERC-1271, so it cannot use the relayed authorization path. It spends through its own UserOperation.

ERC-8004 agent identity as delegate

ERC-8004 defines a registry where an agent has an identity and a wallet address. The ERC-8004 test registers a fresh agent in the Identity Registry on Arc testnet, grants to the agent's wallet, then changes the wallet, clears it, and transfers the agent.

How it uses ERC-8427. The owner reads getAgentWallet(agentId) and registers a grant with that address as the delegate. The grant can carry a label in its salt, derived from the identity registry, the chain, and the agent id, so a third party can see which agent a grant was meant for.

What it is worth. An owner can name an agent by its registered identity and still get all of the grant's limits. A third party reading the grant can compare its delegate with the agent's current wallet and see whether the grant is stale.

What the tests found. A grant binds an address, not an identity. If the agent's wallet changes or the agent is transferred, the old wallet keeps spending until the owner revokes, and the new wallet cannot spend under the old grant. update cannot move a grant to a new delegate. Rebinding is a revocation and a new registration, which starts with no usage. An owner who grants to an agent identity has to watch the Identity Registry for wallet changes and transfers and revoke the grants that name the previous wallet. The salt is a label and authorizes nothing.

Status. Fork test in the repo, against Identity Registry version 2.0.0 as deployed on Arc testnet.

ERC-7710 delegation redemption

ERC-7710 standardizes how a delegation is redeemed. MetaMask's delegation framework is a deployed implementation of that idea. The reference includes SpendGrantRedemptionExecutor and SpendGrantRedemptionEnforcer, and the fork tests run them through DelegationManager v1.3.0 on Arc testnet.

How it uses ERC-8427. A delegation framework tells a contract that a delegation was redeemed, but not always who redeemed it. The enforcer records the redeemer for the executor, scoped to the exact spend and held in transient storage for one transaction. The executor reads it once, passes it to the registry as the authorizer, and the registry rejects anyone but the grant's delegate.

What it is worth. A team that already hands out permissions as delegations can carry a spend grant inside one and still get per-spend caps, a trailing window, and revocation by the owner.

What the review found. The enforcer is strict. It accepts only the owner's own root delegation to the grant's delegate, redeemed by that delegate, and reverts on every other shape, including delegations open to any delegate and redemptions by a sub-delegate. That came out of review on the Magicians thread, including zexoverz's walkthrough of the manager, and my own review of the money path. Along the way I found cases where one redemption could pay twice and fixed them. A scenario matrix of 8,130 cases, with a thief at every hook, finds no redemption that pays twice, and a Halmos proof covers the rule for writing the record. Requiring the redeemer to pass the delegation in the caveat's args costs about 21,000 more gas for a root delegation with one caveat on the live manager.

Status. Tested in the repo and on the fork. The redemption executor and enforcer are not deployed. Deploying them means fixing the enforcer to the chain's delegation manager and the registry to that executor.

x402 payments from an agent

x402 is a payment protocol for the web that is built on HTTP. A server answers a request with the price, the client pays, and a facilitator settles the payment. The standard x402 payer signs for its own funds. The x402 integration is a proposed mapping where an agent signs and the money comes from its owner under a grant.

How it uses ERC-8427. The agent signs a SpendAuthorization naming the grant id, the asset, the amount, and the payee. The facilitator submits it to the authorization executor, and the executor pays from the owner's balance. The grant uses recipient mode "any" because the payee changes from one server to the next. The signature binds the payee and the amount, so the facilitator can neither redirect a payment nor raise it. The mapping uses the scheme name spend-grant, and the repo also has a TypeScript package with a client signer and a facilitator.

What it is worth. An agent can pay for web resources one request at a time while holding no funds. The owner sets the per-payment and rolling caps, can lower them with update, and can revoke. A stolen agent key can spend only within those caps.

Limits stated in the repo.

• verify is a simulation, not a reservation. The owner can change the grant, or another payment can use the remaining cap, between verify and settle. A server should serve the resource only after settle succeeds.
• A signed payment is a bearer authorization until it settles or its deadline passes. The facilitator caps the deadline, and the agent can cancel the nonce.
• ERC-20 only, and only agents that are ordinary key accounts are tested.

Status. This is a proposal. The scheme is not registered with x402, and the package is private. The Solidity model and the TypeScript package are tested against a local node.

Order amendments: ted0x's experiment

This one is not mine. ted0x, who posts on the ERC-8427 thread, is working on an experimental profile of ERC-8001 for amending agent service orders. A buyer and a provider agree on an order. Later they both agree to change its scope, price, or deadline, and a price increase needs extra funding. ted0x's discussion thread explains the problem. The profile is local test software and has no ERC number.

How it uses ERC-8427. In ted0x's test, funding for an amendment comes through the ERC-8427 registry and executor. The buyer, as the principal, registers a grant whose delegate and fixed recipient are the order contract. The buyer approves only the executor, and the order contract holds no allowance of its own. To apply an amendment, the order contract calls the executor to move the extra amount into escrow, and in the same transaction it checks the balance change, updates the escrow, and moves the order to its next revision. If any step fails, the debit, the token movement, and the order change all roll back together.

What it is worth. The buyer can tighten the budget after both sides have agreed to a change, and the order contract cannot be pushed past the new cap. ted0x's post on the thread puts the result this way: "a cap cut after consent blocks the top-up without changing grant usage, funds or the order revision." In ted0x's results, a cap lowered to 800 lets an 80 supplement through, and a cap lowered to 750 after consent makes the same supplement fail with OVER_CUMULATIVE_CAP, leaving usage, escrow, and the order revision unchanged. A revoked grant fails with REVOKED.

Where it came from. ted0x's earlier question about how to size a replacement grant found a mistake in my draft. I corrected it, and the later update function replaced that approach. The experiment now tests cap changes made with update.

Limits stated in the repo. The test covers only the direct contract-delegate path. It does not exercise ERC-7710, native currency, relayed signatures, the Arc deployment, or the full upstream test suite. A grant's usage counts gross transfers into escrow, so a refund does not give usage back. ted0x also says plainly that this is "our own integration fixture, not an independent implementation, upstream endorsement, or a new ERC", and that the underlying order profile still lacks review timeouts and dispute handling.

Status. Experiment. The code is on a branch of ted0x's repository that was one commit ahead of main and not merged when I checked, and the README pins the ERC-8427 reference at commit d70b04c. It runs on a local node with disposable tokens. I ran the ten ERC-8427 tests from that branch myself, on Node 20 although the README asks for Node 22 or newer, and all ten passed.

What none of this shows

• No audit. The reference and every test here are unaudited. My own review pass with Slither, fuzzing, and Halmos is not an outside audit.
• Testnet only. The deployed contracts are on Arc testnet. The repo says to deploy to testnets only.
• One implementation. Every integration here uses the reference registry or a copy of it. None of them is an independent implementation of the spec.
• No native currency. The reference executors only move ERC-20 tokens. Spending native currency from an owner's account needs an account adapter that the draft does not specify.
• The x402 scheme is a proposal. Nobody at x402 has adopted it.

If you want to build on it

If you build wallets, agent frameworks, account modules, or payment flows, the useful thing is to try the draft against your system and tell me where it breaks. The integration tests above are the pattern: a fork test or a local test, with the failure cases written down. The README lists integrations that other people have built against the reference.

Discussion is on the Ethereum Magicians thread. The spec is ERCS/erc-8427.md, under review in ethereum/ERCs#2037. To propose a change, fork the repository and open a pull request.

Related service: Web3 Advisory