ERC-7964 is a draft Ethereum standard that defines how a single EIP-712 signature can validate operations across multiple chains. By omitting chainId from the EIP-712 domain and encoding chain-specific operations as an array of typed messages, a smart account or contract can verify one signature on every chain it touches. The proposal was opened by Ernesto García on June 5, 2025, and is currently Draft status on eips.ethereum.org, with active discussion in Ethereum Magicians through Q1 2026.
​

For account abstraction stacks, ERC-7964 closes a long-standing UX gap: pre-7964, every smart-account operation on a new chain required a fresh signature, even when the user had already authorized the same logical action elsewhere. With 7964, a wallet signs one structured payload, and each chain extracts only the hashes relevant to itself. This article walks through the spec as written, contrasts it with adjacent standards (ERC-7715, ERC-7579, ERC-1271), and shows where it fits inside the broader intent-based architecture replacing legacy bridges.
​

ERC-7964 is titled Crosschain EIP-712 Signatures and registered as a Standards Track ERC. The specification borrows the existing typed-data signing flow from EIP-712, then strips chainId from the domain so the resulting hash is chain-agnostic. Each chain-specific action is bundled into an array element. Onchain validators reconstruct the array hash, locate the element for the current chain, and verify the signer.
​

The proposal explicitly targets two use cases the authors call out in the abstract: cross-chain intents, where a user wants assets to move atomically across networks, and multi-chain governance, where a single vote must be recognized by deployments of the same protocol on different chains. A third use case in the reference text is unified account management: recovering or reconfiguring a smart account on every chain with one signature instead of N.
​

The spec is not yet finalized. Status as of April 2026 is Draft. The most recent rework, posted in late December 2025, dropped a previous dependency on draft ERC-7803 and switched from Merkle-tree hashing to standard EIP-712 array encoding. That switch is what makes 7964 implementable today on any wallet that supports EIP-712.
​

Smart accounts under ERC-4337 sign UserOperation structs. Each UserOperation binds to one chain via the EIP-712 domain. A user moving funds across three chains signs three operations. With EIP-7702 EOA upgrades and modular accounts under ERC-7579 proliferating in 2026, the multi-chain signature problem multiplies. Every solver-routed swap, every cross-chain DAO vote, every recovery flow currently requires N popups in the wallet UI.
​

ERC-7964 solves the user-facing half of that problem. It does not handle transport. That still belongs to CCTP, Hyperlane, LayerZero, or other messaging layers. What 7964 contributes is signature deduplication at the authorization layer. The intent stack splits cleanly: 7964 handles "the user said yes once", ERC-7683 handles "here is the cross-chain order", and a solver network handles fulfillment.
​

The economic case is straightforward. According to DeFiLlama, the stablecoin market sits at roughly $319.6B as of Q1 2026, with USDT at $189.6B and USDC at $77.6B. Most of that supply lives on Ethereum, Tron, BSC, Solana, Base, and Arbitrum. A treasury moving USDC from Arbitrum to Base to Solana under intent-based execution shouldn't require three separate wallet prompts. ERC-7964 makes that single-prompt flow standard rather than bespoke.
​

The mechanism has three moving parts: a modified EIP-712 domain, an array-encoded payload, and a magic-prefixed signature wrapper. Each part is described below using the language from the draft text.
​

Standard EIP-712 includes chainId in the EIP712Domain struct. ERC-7964 omits it. The signing domain becomes chain-agnostic, but each operation struct inside the array carries its own chainId field. This pattern is sometimes called the EIP712ChainDomain form, and it lets the validator on chain N find the array element tagged with chain N's ID and verify only that element's hash. Replay across unintended chains is prevented at the per-struct level rather than at the domain level.
​

A user signing a cross-chain swap might author a single payload like: "send 1,000 USDC from Arbitrum, receive 999 USDC on Base, settle by 1700 UTC." That payload becomes a two-element array. Each element is a fully typed EIP-712 struct with its own chainId, verifyingContract, deadline, and operation data. The hash submitted for signing is the EIP-712 hash of the array, computed via keccak256(encodeData(element[0]) ‖ ... ‖ encodeData(element[n])), which is the standard array encoding from EIP-712.
​

When the signature lands on Base, the validator only needs the hash of element[0] (Arbitrum's outflow leg) and the full data of element[1] (Base's inflow leg). The validator reconstructs the array hash, confirms the signature matches, and executes element[1]. Chain-specific data stays minimal: each chain receives only what it needs to verify and execute.
​

To distinguish a cross-chain signature from a normal EIP-712 signature, the encoded blob starts with a 9-byte magic prefix: 0x796479647964796479. The next bytes carry metadata: a 1-byte fields flag, a 2-byte struct index pointing to the current chain's element, and a 20-byte application address that implements ERC-5267 for domain separator lookup. After the metadata comes the array of struct hashes and finally the cryptographic signature. Collision probability with a normal EIP-712 signature is approximately 2^-72, low enough to be considered safe in practice.
​

The reference implementation publishes a library called CrossChainSignatureChecker. Its main entry points are parseCrossChainSignature, which extracts the magic prefix, metadata, and array, and isValidCrossChainSignatureNow, which verifies the signer. Validation queries the application contract via ERC-5267's eip712Domain() to pull the local domain separator, reconstructs the typed hash for the current chain's element, and verifies the signature against the signer using either ECDSA recovery or ERC-1271 for contract wallets. The flow keeps all logic in standard EIP-712 territory, which is why any EIP-712 wallet can produce these signatures without special wallet support.
​

ERC-7964 sits at a specific layer of the account abstraction stack. It does not replace ERC-4337, ERC-7579, or ERC-7715. It composes with them. The boundaries matter for builders choosing which standards to support.
​

ERC-1271 defines how a smart contract validates a signature on its own behalf via isValidSignature(bytes32 hash, bytes signature). ERC-7964 layers on top: the cross-chain signature reduces to a per-chain hash, and that per-chain hash can be validated by either ECDSA recovery (for EOAs) or ERC-1271's isValidSignature (for smart contract wallets). 7964 is the wrapper; 1271 is the per-chain verifier. A smart account that supports 1271 supports 7964 with no contract changes. Only the application that consumes the signature needs the cross-chain parsing logic.
​

ERC-7579 defines a modular smart account interface: validators, executors, hooks, and fallback handlers as pluggable modules. A 7579 validator could be implemented to natively understand ERC-7964 cross-chain signatures, but 7579 itself doesn't require it. The two standards are complementary. A 7579 account using a 7964-aware validator gains cross-chain signature support without altering the account's core logic. ERC-7579's SmartSessions library already includes related multichain signing patterns (HashLib.sol), which informed the 7964 design.
​

ERC-7715 standardizes how dApps request permissions from wallets via wallet_grantPermissions. ERC-7710 covers the redelegation flow. Both are about scope: what a session key or delegate is allowed to do. ERC-7964 is about chain reach: how a single signature spans multiple networks. A session key issued under 7715 with a cross-chain scope is the natural composition: the key authorizes spend up to a limit, and 7964 lets one signature exercise that authorization across chains. The two standards target different failure modes and don't conflict.
​

ERC-7683 defines a standard order format and settlement interface for cross-chain intents. The user describes what they want; a solver fulfills it. ERC-7683 doesn't specify how the user authorizes the order across chains. it leaves signature scheme up to implementations. ERC-7964 fits cleanly: a 7683 order signed with a 7964 cross-chain signature gives the solver a single piece of cryptographic authorization for every chain involved. UniswapX, the early reference 7683 implementation, today uses single-chain signatures plus relayer trust; a 7964-based extension would remove that gap.
​

Circle's Cross-Chain Transfer Protocol uses a different model: a burn on chain A produces an attestation from Circle's off-chain attesters that authorizes a mint on chain B. CCTP's authorization is centralized at the protocol operator and applies only to USDC. ERC-7964 is a generic signature scheme any application can adopt for any asset or operation. They live at different layers. CCTP handles USDC settlement transport, 7964 handles user authorization — and a stack can use both.
​

The draft cites four practical examples in its rationale section. Each maps to a real product surface in 2026 account abstraction.
​

A user wants to sell 10,000 USDC on Arbitrum and receive USDe on Solana. Under the current model, the user signs a 4337 UserOp on Arbitrum, waits for a bridge or solver to deliver, then signs a swap on Solana. With ERC-7964 plus ERC-7683, the user signs a single payload describing the full intent. Solvers compete to fulfill both legs. The user's wallet shows one prompt with the complete cross-chain operation, not two disconnected ones. This is the headline UX win and the primary motivation for the standard.
​

Protocols like Aave deploy on Ethereum, Arbitrum, Base, Polygon, Avalanche, and others. A single proposal often touches multiple deployments. Without 7964, governance contracts on each chain require separate signed votes, even when the underlying authorization is logically one decision. With 7964, a delegate signs once; every chain validates the same signature against its local element. The governance UX collapses from N popups to one.
​

A user with a counterfactual smart account at the same address on multiple chains needs to add a guardian, rotate a key, or upgrade a module. Without 7964, that's N transactions, each individually signed. With 7964 and a 7579-based account where each chain's account contract recognizes 7964 signatures, one signature applies the change everywhere. Recovery flows benefit the most: a user recovering a wallet after a key loss can re-establish control on every chain in one signing event.
​

An ERC-7715 session key on Ethereum can already authorize a dApp to spend up to a limit. Pair the session with 7964, and that same key spans every chain where the user's account exists. A trading bot delegated 1,000 USDC of weekly spend can execute on Base today and Arbitrum tomorrow without the user re-signing. The combination is what enables true cross-chain agentic flows under stablecoin AA stacks.
​

ERC-7964 is in Draft as of late April 2026. The proposal has gone through at least two material revisions: the original chainId: 0 approach published in June 2025, and the current array-encoded form rewritten in December 2025. The most recent community update on Ethereum Magicians is dated January 28, 2026.
​

Reference implementations exist. The author's CrossChainSignatureChecker library is published alongside the draft. ERC-7579's SmartSessions module includes related HashLib patterns that pre-date 7964 and informed its design. As of this writing the standard has not been finalized and adoption by major wallet vendors is not yet documented in primary sources. Builders considering integration should treat 7964 as an early-stage spec, useful for proof-of-concept work, but subject to revision before final.
​

For applications already using EIP-712 typed data signing (most modern DeFi flows), the upgrade path is mostly server- and contract-side. The wallet need not change. Applications add the array-encoding logic on the order construction side and the magic-prefix parsing on the validation side. The user sees structured typed data in their wallet exactly as they do for any EIP-712 message. The cross-chain semantics are visible in the message structure itself, not hidden behind an opaque blob.
​

The draft's security section flags four risks worth understanding before integrating.
​

Cross-chain replay is intentional. The whole point of 7964 is that a signature is valid on multiple chains. The verifyingContract field binds operations to a specific contract address per chain, but applications must implement nonces and deadlines to prevent the same operation from being replayed within the same chain. The standard does not provide nonce management. That's application-level.
​

Partial execution is possible. A signed cross-chain operation might validate and execute on chain A but fail on chain B (insufficient liquidity, contract revert, gas exhaustion). Applications need refund or rollback mechanisms. Intent-based protocols already handle this via solver bonds and timeouts; pure 7964 implementations need to add those primitives.
​

State divergence across chains. A smart account at the same address may have different bytecode or different state on different chains. A signature valid against the Ethereum deployment might be unsafe against an out-of-date Polygon deployment. The community discussion raised this in early 2026; the response from the author is that 7964 treats it as out-of-scope, leaving safety mechanisms (deployment verification, version checks) to the application layer.
​

No native expiration. Signatures don't expire on their own. Applications should embed deadline fields in the operation struct so stale signatures can be rejected. This is standard practice in EIP-712 designs but worth restating because a cross-chain signature has more chances to leak between signing and execution.
​

Eco operates as the stablecoin orchestration network across 15 chains. Its Routes product takes user intents (for example, "move N USDC from chain A to chain B with these constraints") and selects between transport rails (CCTP, Hyperlane, LayerZero) for execution. ERC-7964 lives at the authorization layer above Routes: a user signs once with a 7964-encoded payload, and Routes uses that single signature to authorize each leg of the cross-chain transfer. As the standard moves from Draft toward final, Eco can drop in 7964 validation alongside its existing intent validation logic without changing the routing layer below. Builders integrating against Eco's API today can prepare by structuring their authorization data in a 7964-compatible array form even before final ratification.
​

No. As of April 2026 the proposal is in Draft status on the EIPs repository. It has been through two major revisions since the original June 2025 publication, with the most recent community discussion dated January 2026. Builders should treat it as an early-stage specification subject to change before final ratification.
​

No. The signature is standard EIP-712 typed data. Any wallet that already signs EIP-712 messages (MetaMask, Safe, Coinbase Wallet, Rabby, and most modern wallets) can produce a 7964 signature with no firmware or extension changes. The cross-chain logic lives in the encoding of the message and the validator contract, not in the wallet.
​

Each operation in the signed array carries its own chainId and verifyingContract, so a chain-A element won't validate on chain B. Within a single chain, applications must add their own nonces and deadlines — the standard doesn't supply nonce management. Cross-chain replay across unintended chains is blocked by the per-element binding.
​

Yes. ERC-4337 and EIP-7702 define how smart accounts are deployed and how EOAs gain smart-contract behavior. ERC-7964 defines how those accounts authorize operations across chains. The two standards compose: a 4337 UserOp can carry a 7964 signature, and a 7702-upgraded EOA can sign 7964 payloads natively.
​

Transport. The standard only handles authorization. Moving the actual assets across chains still requires CCTP, Hyperlane, LayerZero, or another messaging layer. Settlement guarantees, solver economics, and partial-execution rollbacks all live above 7964 in the application or intent-protocol layer.
​