This ERC provides a standard for signing multiple typed-data messages with a single signature by encoding them into a Merkle tree. This allows components to independently verify messages, without requiring full knowledge of the others. It provides a significant UX improvement by reducing the number of signature prompts to one, while preserving the security and flexibility of the EIP-712 standard.
This ERC also gives applications the flexibility to verify messages in isolation, or in aggregate. This opens up new verification modalities: for e.g, an application can require that message (x) is only valid when signed in combination message (y).
As the ecosystem moves towards ETH-less transactions, users are often required to sign multiple off-chain messages in quick succession. Typically, a first signature is needed for a precise spend allowance (via Permit2, ERC-2612, etc.), followed by subsequent messages to direct the use of funds. This creates a frictional user experience as each signature requires a separate wallet interaction and creates confusion about what, in aggregate, is being approved.
Current solutions have significant drawbacks:
This ERC has the following objectives:
A single signature should cover multiple messages
Messages should be independently verifiable without knowledge of others
Readability benefits of EIP-712 should be preserved. Giving wallets and users insight into what is being signed.
The composite signature scheme uses a Merkle tree to hash multiple typed-data data messages together under a single root. The user signs only the Merkle root. The process is described below.
For a set of messages [m₁, m₂, ..., mₙ], encode each using EIP-712's encode and compute its hash:
Use these message hashes as leaf nodes in a Merkle tree and compute a merkleRoot
Sign the merkle root.
To verify that an individual message mₓ was included in a composite signature:
Verify the signature on the merkleRoot:
Compute the leaf node for message mₓ and verify its path to the Merkle root, using the proof:
Where _verifyMerkleProof() is defined as:
The message is verified if and only if (1) and (2) succeed.
eth_signTypedData_v5 JSON RPC method.This ERC adds a new method eth_signTypedData_v5 to Ethereum JSON-RPC. This method allows signing multiple typed data messages with a single signature using the specification described above. The signing account must be prior unlocked.
This method returns: the signature, merkle root, and an array of proofs (each corresponding to an input message).
Address - Signing accountTypedData | TypedDataArray - A single TypedData object or Array of TypedData objects from EIP-712.Request:
Result:
The choice of using a Merkle tree to bundle messages provides the following additional benefits:
_verifyMerkleProof has a runtime of O(log2(N)) where N is the number of messages that were signed.
Applications can require combination of messages be signed together to enhance security.
N=1 backwards compatibilityMerkle signature for single message bundles are equal to eth_signTypedData_v4. Requiring no onchain changes.
When the number of message is one, eth_signTypedData_v5 produces the same signature as eth_signTypedData_v4 since merkleRoot == keccak256(encode(message)). This allows eth_signTypedData_v5 to be a drop-in replacement for eth_signTypedData_v4 with no changes to on-chain verification.
eth_signTypedData_v5Reference implementation of eth_signTypedData_v5 can be found the assets directory.
Solidity implementation of a onchain verifier can be found the assets directory.
Reference Merkle tree can be found in the assets directory.
This ERC focuses on generating composite messages and verifying their signatures. It does not contain mechanisms to prevent replays. Developers must ensure their applications can handle receiving the same message twice.
During verification, care must be taken to ensure that both of these checks pass:
Wallets must communicate to users that they are signing multiple messages at once. Wallets must display of all message types before signing.
To ensure batch signature requests are digestible, it is recommended to limit the maximum number of messages to 10.
Merkle tree should be constructed in a consistent manner.
keccak256n be the number of messages. Before constructing the tree, compute the smallest k such that 2^(k-1) < n ≤ 2^k. Insert zero hashes into the list of messages until list of messages is equal to 2^k.Copyright and related rights waived via CC0.