This ERC defines a standard approach for creating and verifying crosschain signatures using EIP-712. By omitting the chainId field from the EIP-712 domain, a signature can be valid across multiple chains. Chain-specific operations are encoded as an array of structured messages, where each chain receives the array of message hashes and only the full message data relevant to that chain. This enables efficient crosschain signature validation using standard EIP-712 encoding without requiring special wallet support.
Current account abstraction solutions require separate signatures for each blockchain network. This creates poor user experience for crosschain operations such as:
Existing proposals either require complex Merkle tree constructions (which need wallet-specific UI to verify all leaves) or non-standard encoding schemes that lack wallet adoption. This ERC provides a simpler approach using only standard EIP-712 encoding with array types, enabling crosschain signatures with minimal on-chain overhead while maintaining full transparency in standard wallet signing interfaces.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
A crosschain EIP-712 signature MUST omit the chainId field from the EIP712Domain type and domain object. Since chainId is optional per EIP-712, omitting it signals that the signature is intended for crosschain validity.
Contract addresses and chainIds MUST be validated per-chain, so typically, only name and version are included in the main domain. The verifyingContract field MAY be used to bind the signature to a specific application deployed deterministically on the same address across all chains the signature is intended to be valid on, allowing to omit the contract address from the chain-specific structs.
Crosschain operations MUST be encoded as an array of message structs with chain-specific fields. Each struct in the array SHOULD include the target chainId field. When contracts are deployed at different addresses across chains, the struct SHOULD also include the verifyingContract (or equivalent) field to bind each operation to its specific contract address unless the main domain includes the verifyingContract field.
Implementers MAY use the canonical EIP712Domain struct but named to avoid collisions with EIP712Domain (e.g., EIP712ChainDomain) so it can be nested inside the chain-specific structs, allowing to include the chainId and verifyingContract fields.
Per EIP-712, arrays are encoded as keccak256(encodeData(element[0]) ‖ encodeData(element[1]) ‖ ... ‖ encodeData(element[n])), where each element is a struct that is recursively encoded as hashStruct(element[i]), and nested structs are also recursively hashed.
In practice, this means the array of chain-specific operations is represented as an array of pre-computed bytes32 struct hashes (one for each chain). The hash of this array is computed as keccak256(abi.encodePacked(structsArray)), which concatenates all 32-byte hashes and produces the array hash that matches the standard EIP-712 array encoding for reference types.
Per EIP-712, the signature is computed over a complete message struct (e.g., CrossChainIntent, MultiChainVote), not just the array of operations. Applications implementing verification MUST define a type hash for the complete message struct that includes the array of operations.
Wrapping the array of operations in a main struct also allows to include other message fields (e.g., nonce, deadline) in the struct hash. For example, for a CrossChainIntent struct would be encoded as:
Applications implementing verification MUST use the same typehash across all chains where the application is deployed.
To enable applications to detect and verify crosschain signatures through standard ECDSA validation or ERC-1271 isValidSignature calls, crosschain signatures SHOULD be encoded with metadata in the signature parameter. The signature validation flow requires the contract application to detect the encoding of this ERC, parse the signature components, and then verify the signature agains the reconstructed crosschain message hash.
The signature encoding format uses ABI encoding for dynamic types (arrays and bytes) with the following structure:
Equivalent to the following ABI encoding:
Where:
magic: A fixed 9-byte value 0x796479647964796479 used to detect encoded crosschain signaturesfields: A single byte encoding which EIP-712 domain fields are present (per ERC-5267)structIndex: The index in the structsArray corresponding to the current chain's operationapplication: The address of a contract implementing ERC-5267 that provides the EIP-712 domain informationstructsArrayOffset: The offset (in bytes) from the start of the signature to where the structsArray begins.structsArrayLength: The number of elements in the structs arraystructsArray: Array of bytes32 hashes, one per chain operationcrossChainSignatureOffset: The offset (in bytes) from the start of the signature to where the crossChainSignature begins.crossChainSignatureLength: The length of the crosschain signature in bytescrossChainSignature: The actual signature bytes that sign the crosschain messageThis encoding allows applications to identify when a signature is a crosschain signature, rebuild the EIP-712 domain information needed to reconstruct the expected typed hash, and verify the signature against the reconstructed crosschain message hash.
Applications can detect crosschain signatures by checking if the first 9 bytes of the signature equal the magic value 0x796479647964796479. If detected, applications MUST:
structsArray[structIndex] matches the struct hash of the current chain's messageapplication to obtain the EIP-712 domaincrossChainSignature against the reconstructed typed hashStandard EIP-712 wallets will automatically display the array of chain-specific messages in a readable format. Wallets MAY enhance the display by grouping operations by chain and showing chain names instead of chain IDs for better user experience.
This ERC uses only standard EIP-712 encoding without any extensions or special constructs. All fields in the EIP712Domain are optional per the standard, so omitting chainId is perfectly valid. This means any wallet that supports EIP-712 can sign these messages and any application that supports EIP-712 can verify them.
The main benefit of this approach is that users can achieve a full transparent view of the crosschain message in any wallet provider that supports EIP-712.
For wallet providers to show the crosschain message properly, they need a primaryType to display the message. This specification does not mandate a specific primaryType to allow for flexibility in the implementation, but defines the requirements for the array of operations and the main struct to ensure a secure EIP-712 message.
The specification requires that each of the operations include the chainId field to avoid replaying the same operation on other chains. The verifyingContract field (or equivalent) is used to bind the operation to its specific contract address and is optional if the main EIP712Domain includes the verifyingContract field since the domain hash would include the application's address.
Alternative approaches use Merkle trees to commit to crosschain operations. While Merkle trees can reduce on-chain overhead for many chains, they have a critical drawback:
Wallet Verification Complexity: Standard EIP-712 wallets cannot display Merkle tree leaves. Users signing a Merkle root have no way to verify all operations in their wallet UI. Wallets would need to implement custom logic to:
This breaks the principle of trustless signing, users must trust the application to correctly provide all leaves, and wallet developers must implement and maintain custom verification logic.
The array-based approach provides full transparency using standard EIP-712. Users see all chain-specific operations in any compliant wallet without custom support. No hidden operations are possible since all array elements are displayed as part of the standard EIP-712 message structure.
On-chain overhead comparison: For reasonable crosschain operations, the overhead difference is minimal.
With the array approach, each chain receives all N operation hashes (N × 32 bytes). With Merkle trees (assuming a binary tree), each chain receives a Merkle proof of size ceil(log₂(N)) × 32 bytes. Both approaches reconstruct the root/array hash on-chain from the provided data and verify it against the signature, no additional calldata for the root is needed. While Merkle proofs grow logarithmically vs. the array's linear growth, the practical savings are small for reasonable use cases:
| Chains | Array (N × 32) | Merkle (⌈log₂(N)⌉ × 32) | Savings |
|---|---|---|---|
| 2 | 64 bytes (2 × 32) | 32 bytes (1 × 32) | 32 bytes (1 hash) |
| 3 | 96 bytes (3 × 32) | 64 bytes (2 × 32) | 32 bytes (1 hash) |
| 4 | 128 bytes (4 × 32) | 64 bytes (2 × 32) | 64 bytes (2 hashes) |
| 5 | 160 bytes (5 × 32) | 96 bytes (3 × 32) | 64 bytes (2 hashes) |
| 8 | 256 bytes (8 × 32) | 96 bytes (3 × 32) | 160 bytes (5 hashes) |
For 2-5 chains (the reasonable case for crosschain operations), Merkle trees save only 32-64 bytes (1-2 hashes) per transaction. This minimal savings doesn't justify the complexity and loss of transparency. Merkle trees only become significantly more efficient at 8+ chains, which is an uncommon use case and may indicate the operation should be split into multiple signatures for better user comprehension and failure isolation.
0Omitting chainId entirely is cleaner than using a special value like 0 because it explicitly signals that the signature is intended for crosschain validity.
The custom binary encoding format for crosschain signatures was selected to minimize calldata and memory overhead. The format packs metadata values that can be read to the stack and uses ABI encoding for structsArray and crossChainSignature for easy calldata and memory casting.
The magic value is used to detect crosschain signatures and is designed to be easy to parse and verify. It's a fixed 9-byte value that is easy to identify and verify. The length was selected to pack it along with bytes1(fields), uint16(structIndex) and address(application) into a single 32-byte word. While 9 bytes is shorter than a full 32-byte hash, the collision probability remains negligible in practice—an attacker would need to produce a valid ECDSA or ERC-1271 signature that randomly begins with these exact 9 bytes, which has probability 2^-72 (approximately 1 in 4.7 × 10^21) assuming a uniform distribution.
The fields byte encodes which EIP-712 domain fields are present in the main domain (per ERC-5267), enabling dynamic field selection. Only name and version are normally set in the main domain, since chainId is omitted for crosschain validity since each chain-specific struct includes its own chainId and optionally verifyingContract (or equivalent), allowing each chain to validate its own contract address as part of the struct hash verification.
The application address refers to any contract that implements ERC-5267's eip712Domain() function. This contract provides the domain separator information needed to reconstruct the crosschain message hash. The application contract does not need to be the contract that executes the operation: it serves solely as a source of EIP-712 domain metadata. Applications could either deploy dedicated immutable domain separator contracts to ensure consistent domain information across all chains, or use the executing contract itself if it implements ERC-5267.
This ERC uses standard EIP-712 without modifications. Existing wallets and applications that support EIP-712 can immediately work with crosschain signatures without any changes, though they may not recognize the crosschain semantics.
Applications that verify signatures with a domain that includes a specific chainId will reject crosschain signatures (where chainId is omitted), providing safe failure by default. Applications that wish to support crosschain signatures must explicitly implement the verification pattern described in this ERC.
To validate a crosschain signature, the application can use the following library:
A collection of examples of how to use this ERC to fulfill the Motivation use cases.
A user wants to execute a crosschain trade: sell USDC on Ethereum, receive ETH on Arbitrum:
On-chain verification on Ethereum:
Applications can verify crosschain signatures using the encoded format. The signature contains all necessary metadata to reconstruct and verify the crosschain message:
The Arbitrum settler would use the same signature with currentIndex: 1 and the full data for op[1]. Each chain only receives the full calldata for its own operation, while other operations are represented as 32-byte hashes.
A DAO member votes on a proposal affecting all chain deployments:
On-chain verification on each DAO:
This vote signature can be submitted to DAO contracts on both Ethereum and Polygon, enabling coordinated multi-chain governance decisions.
A user wants to add a new signer to their multisig account deployed across multiple chains:
On-chain execution:
This signature enables the multisig owners to add a new signer and update the threshold across all chain deployments simultaneously. The same account address exists on Ethereum, Polygon, and Arbitrum, and this single signature authorizes the updates on all three networks.
A user has lost access to their account and guardians need to initiate recovery across multiple networks:
On-chain execution with guardian multisig:
This signature enables guardians to schedule a recovery operation across all chains. The process includes:
This ERC intentionally enables replay across chains, the same signature is designed to be used on multiple chains. The verifyingContract field (set to the user's account address) binds the signature to a specific account, preventing unauthorized use. However, applications must implement their own replay protection mechanisms such as including nonces and deadlines in the message.
Applications verifying signatures should check that the signing account exists on the current chain. An account that exists on Ethereum but not Polygon should not have signatures accepted on Polygon. For counterfactual accounts that have not been deployed yet, applications should follow ERC-6492 to validate signatures.
Contract code and state may differ across chains at the same address. Signatures that pass isValidSignature() on one chain may fail on another due to state divergence or chain-specific logic. For example, a crosschain message that has uses a nonce field may find that the nonce is already used on one of the chains. Applications should handle signature validation failures gracefully and should not assume uniform behavior across chains.
Crosschain signatures do not guarantee atomic execution. A signature may be successfully validated on some chains but not others. This can result in partial fulfillment of the intent. Applications should implement refund mechanisms to allow users to recover from failed partial executions.
Additionally, operations may execute in different orders across chains due to varying network conditions, block times, and congestion levels. An operation intended to execute first may complete last on a congested chain, leading to unexpected state changes. For example, in a crosschain trade, a user might sell an asset on one chain before successfully acquiring its replacement on another chain, creating temporary exposure. Applications should design operations to be order-independent where possible, or implement coordination mechanisms to ensure proper sequencing.
Signatures without explicit expiration remain valid indefinitely. If an operation is not executed on some chains, it can be executed later, potentially with unexpected consequences. Applications may include deadline or validUntil fields in messages to prevent stale signature execution.
Since this ERC relies on standard EIP-712 wallet display, users depend on their wallet to correctly show all crosschain operations. Users should:
Wallet developers should enhance displays to highlight crosschain nature and show warnings about partial execution risks.
Copyright and related rights waived via CC0.