ERC-7739: Readable Typed Signatures for Smart Accounts
A defensive rehashing scheme which prevents signature replays across smart accounts and preserves the readability of the signed contents
Abstract
This proposal defines a standard to prevent signature replays across multiple smart accounts when they are owned by a single Externally Owned Account (EOA). This is achieved through a defensive rehashing scheme for ERC-1271 verification using specific nested EIP-712 typed structures, which preserves the readability of the signed contents during wallet client signature requests.
Motivation
Smart accounts can verify signatures with via ERC-1271 using the isValidSignature
function.
A straightforward implementation as shown below, is vulnerable to signature replay attacks.
When multiple smart accounts are owned by a single EOA, the same signature can be replayed across the smart accounts if the hash
does not include the smart account address.
Unfortunately, this is the case for many popular applications (e.g. Permit2). As such, many smart account implementations perform some form of defensive rehashing. First, the smart account computes a final hash from minimally: (1) the hash, (2) its own address, (3) the chain ID. Then, the smart account verifies the final hash against the signature. Defensive rehashing can be implemented with EIP-712, but a straightforward implementation will make the signed contents opaque.
This standard provides a defensive rehashing scheme that makes the signed contents visible across all wallet clients that support EIP-712. It is designed for minimal adoption friction. Even if wallet clients or application frontends are not updated, users can still inject client side JavaScript to enable the defensive rehashing.
Specification
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.
Overview
Compliant smart accounts MUST implement the following dependencies:
-
EIP-712 Typed structured data hashing and signing.
Provides the relevant typed data hashing logic internally, which is required to construct the final hashes. -
ERC-1271 Standard Signature Validation Method for Contracts.
Provides theisValidSignature(bytes32 hash, bytes calldata signature)
function. -
ERC-5267 Retrieval of EIP-712 domain.
Provides theeip712Domain()
function which is required to compute the final hashes.
This standard defines the behavior of the isValidSignature
function for ERC-1271, which comprises of two workflows: (1) the TypedDataSign
workflow, (2) the PersonalSign
workflow.
TypedDataSign
workflow
The TypedDataSign
workflow handles the case where the hash
is originally computed with EIP-712.
TypedDataSign
final hash
The final hash for the TypedDataSign
workflow is defined as:
where ‖
denotes the concatenation operator for bytes.
In Solidity, this can be written as:
where typedDataSignTypehash
is:
If contentsType
is "Mail(address from,address to,string message)"
, then contentsTypeName
will be "Mail"
.
The contentsTypeName
is the substring of contentsType
up to (excluding) the first instance of "("
:
In Solidity, this can be written as:
A copy of the LibString
Solidity library is provided for reference in [/assets/eip-7739/contracts/utils/LibString.sol
].
For safety, smart accounts MUST treat the signature as invalid if any of the following is true:
contentsTypeName
is the empty string (i.e.bytes(contentsTypeName).length == 0
).contentsTypeName
starts with any of the following bytesabcdefghijklmnopqrstuvwxyz(
.contentsTypeName
contains any of the following bytes, )\x00
.
TypedDataSign
signature
The signature
passed into isValidSignature
will be changed to:
where contents
is the bytes32 struct hash of the original struct.
In Solidity, this can be written as:
The appended APP_DOMAIN_SEPARATOR
and contents
struct hash will be used to verify if the hash
passed into isValidSignature
is indeed correct via:
If the hash
does not match the reconstructed hash, then the hash
and signature
are invalid under the TypedDataSign
workflow.
PersonalSign
workflow
This PersonalSign
workflow handles the case where the hash
is originally computed with EIP-191.
PersonalSign
final hash
The final hash for the PersonalSign
workflow is defined as:
where ‖
denotes the concatenation operator for bytes.
In Solidity, this can be written as:
Here, hash
is computed in the application contract and passed into isValidSignature
.
The smart account does not need to know how hash
is computed. For completeness, this is how it can be computed:
PersonalSign
signature
The PersonalSign
workflow does not require additional data to be appended to the signature
passed into isValidSignature
.
supportsNestedTypedDataSign
function for detection
To facilitate automatic detection, smart accounts SHOULD implement the following function:
Signature verification workflow deduction
As the isValidSignature
signature function signature is unchanged, the implementation MUST be able to deduce the type of workflow required to verify the signature.
If the signature contains the correct data to reconstruct the hash
, the isValidSignature
function MUST perform the TypedDataSign
workflow.
Otherwise, the isValidSignature
function MUST perform the PersonalSign
workflow.
In Solidity, the check can be written as:
Conditional skipping of defensive rehashing
Smart accounts MAY skip the defensive rehashing workflows if any of the following is true:
isValidSignature
is called off-chain.- The
hash
passed intoisValidSignature
has already included the address of the smart account.
As many developers may not update their applications to support the nested EIP-712 workflow, smart account implementations SHOULD try to accommodate by skipping the defensive rehashing where it is safe to do so.
Rationale
TypedDataSign
structure
The typedDataSignTypehash
must be constructed on-the-fly on-chain. This is to enforce that the signed contents will be visible in the signature request, by requiring that contents
be a user defined type.
The structure is intentionally made flat with the fields of eip712Domain
to make implementation feasible. Otherwise, smart accounts must implement on-chain lexographical sorting of strings for the struct type names when constructing typedDataSignTypehash
.
supportsNestedTypedDataSign
for detection
Without this function, this standard will not change the interface of the smart account, as it defines the behavior of isValidSignature
without adding any new functions. As such, ERC-165 cannot be used.
For future extendability, supportsNestedTypedDataSign
is defined to return a bytes32 as the first word of its returned data. For bytecode compactness and to leave space for bit packing, only the leftmost 4 bytes are set to the function selector of supportsNestedTypedDataSign
.
The supportsNestedTypedDataSign
function may be extended to return multiple values (e.g. bytes32 result, bytes memory data
), as long as the first word of the returned data is a bytes32 identifier. This will not change the function selector.
Backwards Compatibility
No backwards compatibility issues.
Reference Implementation
A production ready and optimized reference implementation is provided at [/assets/eip-7739/contracts/accounts/ERC1271.sol
].
It includes relevant complementary features required for safety, flexibility, developer experience, and user experience.
The reference implementation is intentionally not minimalistic. This is to avoid repeating the mistake of ERC-1271, where a minimalist reference implementation is wrongly assumed to be safe for production use.
Security Considerations
Rejecting invalid contentsTypeName
Current major implementations of eth_signTypedData
do not sanitize the names of custom types.
A phishing website can craft a contentsTypeName
with control characters to break out of the PersonalSign
type encoding, resulting in the wallet client asking the user to sign an opaque hash.
Requiring on-chain sanitization of contentsTypeName
will block this phishing attack vector.
Copyright
Copyright and related rights waived via CC0.