This EIP proposes two token interfaces: ERC-KeyHash721 for non-fungible tokens (NFTs) and ERC-KeyHash20 for fungible tokens (similar to ERC-20). Both of them utilize cryptographic key hashes (“keyHash”, or keccak256(key)) instead of Ethereum addresses to manage ownership. This enhances privacy by authorizing by the public key’s ECDSA signature (address derived from keccak256(key[1:])) and matching keyHash = keccak256(key), without storing addresses on‑chain. Consequently, it empowers users to conduct transactions using any address they choose. By separating ownership from transaction initiation, these standards allow gas fees to be paid by third parties without relinquishing token control, making them suitable for batch transactions and gas sponsorship. Security is ensured by implementing robust ECDSA signature verification on key functions (transfer) to prevent message tampering.
Motivation
Traditional ERC-721 and ERC-20 tokens bind ownership to Ethereum addresses, which are publicly visible and may be linked to identities, compromising privacy. The key hash-based ownership model allows owners to prove control without exposing addresses, ideal for anonymous collectibles, private transactions, or decentralized identity use cases. Additionally, separating ownership from gas fee payment enables third-party gas sponsorship, improving user experience in high-gas or batch transaction scenarios. This proposal aligns with the privacy principles of ERC-5564 (Stealth Addresses) and extends them to token ownership.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Overview
This proposal defines two token interfaces:
IERCKeyHash721: For non-fungible tokens (NFTs), each identified by a unique tokenId, with ownership managed via keyHash (keccak256(key)).
IERCKeyHash20: For fungible tokens, with balances associated with keyHash.
Token operations (transfer) require the owner’s key(an uncompressed secp256k1 public key) and an ECDSA signature produced by the private key corresponding to the key (i.e., the address derived from keccak256(key[1:]) excluding the 0x04 prefix) to prove ownership, ensuring only legitimate owners can execute actions. Signatures follow EIP-712 structured data hashing to prevent message tampering, with per-keyHash nonces and deadlines to prevent replay attacks.
Implementers MAY optionally add administrative functions such as mint (create new tokens) and destroy (remove tokens) based on application requirements. These functions are not part of the core interface of this ERC; if provided, they SHOULD enforce strict access control, correct supply accounting, and preserve the key‑hash privacy model without exposing addresses.
Notably, the approve function is intentionally omitted. The key is designed for one-time use and is revealed only during token transfer transactions. Once revealed, holdings are typically migrated to fresh keyHashes; implementations MAY disallow reuse of previously revealed keyHash. Since transactions can be submitted by any address, the signature must be generated by the address derived from the key. This binds authorization to the key while allowing any relayer address to submit and pay gas.
Description: Transfers the specified token from the current owner’s keyHash to toKeyHash. The caller provides the owner’s key to prove ownership. The signature is verified using EIP-712 structured data. Parameters:
- tokenId: uint256 - The token ID to transfer.
- toKeyHash: bytes32 - The new owner’s key hash.
- key: bytes - MUST be a 65-byte uncompressed secp256k1 public key with prefix 0x04.
- signature: bytes - ECDSA signature produced by the private key corresponding to the key, verifying ownership and preventing malicious relay attacks.
- deadline: uint256 - Signature expiration timestamp (Unix seconds). Signature Message: EIP-712 structured data: solidity
struct Transfer {
uint256 tokenId;
bytes32 toKeyHash;
uint256 nonce;
uint256 deadline;
}
Events: Emits KeyHashTransfer721(tokenId, fromKeyHash, toKeyHash). Requirements:
- Token MUST exist (non-zero fromKeyHash).
- keccak256(key) MUST equal the current fromKeyHash.
- Signature MUST be valid.
- block.timestamp MUST be <= deadline.
- toKeyHash MUST NOT be zero.
- Updates ownership to toKeyHash.
Other Functions: name, symbol, tokenURI, and totalSupply align with ERC-721 . ownerOf returns bytes32 (keyHash) instead of an address.tokenURI is part of the core interface and MAY return an empty string if metadata is not provided.
Key Concepts
Key (key): An uncompressed secp256k1 public key (65 bytes, starting with 0x04), used to prove ownership. Implementations MUST validate the key format:
Key Hash (keyHash): A bytes32 value representing keccak256(key), identifying ownership without exposing addresses.
Token Existence: A token exists if its keyHash is non-zero.
Nonce: Nonces are tracked per keyHash and per contract. Each ERC-KeyHash contract maintains its ownmapping(bytes32 =>uint256)keyNonces. Cross-contract replay is already prevented by the EIP-712 domain (verifyingContract, chainId). Signers MUST serialize operations for the same keyHashwithin the same contract.
Recover signer address using ecrecover(digest, signature).
REQUIRE signer == address(uint160(uint256(keccak256(key[1:])))), where key is a 65‑byte uncompressed secp256k1 public key (0x04
X
Y) and key[1:] denotes the 64‑byte XY payload (prefix removed)
On successful verification, increment _keyNonces[currentOwnerKeyHash] (i.e., _keyNonces[ownerKeyHash] for ERC‑KeyHash721 and _keyNonces[fromKeyHash] for ERC‑KeyHash20) to prevent replay.
Verify block.timestamp <= deadline.
Requirements
Contracts MUST maintain mappings:
ERC-KeyHash721: tokenId to keyHash.
ERC-KeyHash20: keyHash to balance.
MUST use per-keyHash nonces (mapping(bytes32 => uint256) _keyNonces) for replay protection.
MUST enforce deadline to limit signature validity.
MUST verify signatures and hash keys in transfer.
For ERC-KeyHash20, MUST enforce strict mode for leftKeyHash by requiring it to be different from both toKeyHash and fromKeyHash. This prevents change consolidation with the recipient or original account, promoting key rotation and unlinkability.
Rationale
Advantages of Key Hash
Privacy: ownerOf and balanceOf return keyHash, not addresses. Users can use unique key pairs per token or balance, reducing linkability.
Gas Fee Separation: Anyone can call transfer with a valid signature, paying gas fees, enabling batch transactions or gas sponsorship.
Flexibility: Aligns with ERC-5564 stealth addresses, extending privacy to tokens.
Transfer Design
Open to any caller with valid signatures, ensuring only owners operate while allowing gas sponsorship.
EIP-712 signatures prevent message tampering by including all critical parameters.
Per-keyHash nonces and deadlines prevent replay attacks.
Backwards Compatibility
This proposal is not compatible with ERC-721 or ERC-20 due to bytes32 key hashes instead of addresses. Adapters can bridge to existing systems for privacy-focused use cases.
Reference Implementation
ERC-KeyHash721 Implementation
pragmasolidity^0.8.0;import"@openzeppelin/contracts/utils/cryptography/ECDSA.sol";import"@openzeppelin/contracts/utils/cryptography/EIP712.sol";contractKeyHashERC721isEIP712{usingECDSAforbytes32;stringpublicname;stringpublicsymbol;mapping(uint256=>bytes32)private_tokenKeyHashes;mapping(uint256=>bool)private_destroyedTokens;uint256publictotalSupply;mapping(bytes32=>uint256)private_keyNonces;eventKeyHashTransfer721(uint256indexedtokenId,bytes32indexedfromKeyHash,bytes32indexedtoKeyHash);eventKeyHashBurn721(uint256indexedtokenId,bytes32indexedownerKeyHash);bytes32privateconstantTRANSFER_TYPEHASH=keccak256("Transfer(uint256 tokenId,bytes32 toKeyHash,uint256 nonce,uint256 deadline)");bytes32privateconstantDESTROY_TYPEHASH=keccak256("Destroy(uint256 tokenId,uint256 nonce,uint256 deadline)");constructor(stringmemory_name,stringmemory_symbol)EIP712("KeyHashERC721","1"){name=_name;symbol=_symbol;}functionownerOf(uint256tokenId)externalviewreturns(bytes32){require(_tokenKeyHashes[tokenId]!=0&&!_destroyedTokens[tokenId],"Token does not exist");return_tokenKeyHashes[tokenId];}functiontokenURI(uint256)externalpurereturns(stringmemory){return"";}functiontransfer(uint256tokenId,bytes32toKeyHash,bytesmemorykey,bytesmemorysignature,uint256deadline)external{require(toKeyHash!=bytes32(0),"Invalid recipient hash");require(_tokenKeyHashes[tokenId]!=0&&!_destroyedTokens[tokenId],"Token does not exist");require(block.timestamp<=deadline,"Signature expired");require(key.length==65&&key[0]==0x04,"BAD_KEY_FMT");bytes32currentKeyHash=_tokenKeyHashes[tokenId];require(keccak256(key)==currentKeyHash,"BAD_KEYHASH");uint256nonce=_keyNonces[currentKeyHash];bytes32structHash=keccak256(abi.encode(TRANSFER_TYPEHASH,tokenId,toKeyHash,nonce,deadline));bytes32digest=_hashTypedDataV4(structHash);addresssigner=digest.recover(signature);addressexpectedAddress=_addressFromUncompressedKey(key);require(signer==expectedAddress,"Invalid signature");_keyNonces[currentKeyHash]=nonce+1;// 验签通过后再自增
_tokenKeyHashes[tokenId]=toKeyHash;emitKeyHashTransfer721(tokenId,currentKeyHash,toKeyHash);}functiongetNonce(bytes32keyHash)externalviewreturns(uint256){return_keyNonces[keyHash];}function_addressFromUncompressedKey(bytesmemorykey)internalpurereturns(address){// key: 65 bytes, [0] = 0x04, [1..32] = X, [33..64] = Y
require(key.length==65&&key[0]==0x04,"BAD_KEY_FMT");bytes32x;bytes32y;assembly{x:=mload(add(key,0x21))// key[1..32]
y:=mload(add(key,0x41))// key[33..64]
}bytes32h=keccak256(abi.encodePacked(x,y));// 64-byte XY
returnaddress(uint160(uint256(h)));}}
Issue: Public keys (key) are revealed in calldata; the corresponding Ethereum addresses can be derived off‑chain from keccak256(key[1:]). Use fresh keys (toKeyHash / leftKeyHash) to reduce linkability.
Recommendation: Use new key pairs per token or balance to minimize linkability. Store hashKey securely, as it is sensitive.
Key Management:
Risk: Loss or compromise of the private key corresponding to key results in loss of control. Store private keys securely.
Recommendation: Use safe systems to save key.
Gas Costs:
Issue: Signature verification and EIP-712 hashing increase gas costs.
Recommendation: Optimize implementations and consider gas sponsorship to offset costs.
Signature Malleability: Implementations MUST reject malleable signatures (low‑S, v ∈ {27, 28}). OpenZeppelin’s ECDSA helpers enforce these checks by default.