ERC-7962: Key Hash Based Tokens

ERCs
45

In my opinion, the value of ERC-7962 is not in immediate large-scale adoption, but in the direction it sets for the evolution of Ethereum accounts and wallet interactions. The proposal focuses on standardizing how contract accounts or wallets can explicitly declare their capabilities, reducing hidden assumptions between DApps and wallet implementations.

From an ecosystem perspective, ERC-7962 addresses a long-standing issue: many DApps implicitly assume users are EOAs or use a specific wallet type. This leads to poor compatibility, complex frontend logic, and fragmented user experience. By introducing a standardized interface, ERC-7962 shifts DApp design from “guessing wallet behavior” to verifying capabilities on-chain.

Technically, I agree with the idea, but I also think adoption will take time:

  • Wallets, SDKs, and frontend frameworks need to support the standard

  • Multiple account abstraction approaches currently coexist

  • Developers will only adopt it when the practical benefits are clear

Overall, I see ERC-7962 as one of the building blocks for account abstraction and modular wallets. It may not change how developers write code immediately, but in the long run, it will influence how DApps detect account capabilities and how wallets expose their functionality. These kinds of “slow-moving” standards are essential for Ethereum’s sustainable evolution.

46

ERC-KeyHashToken strikes me as a cutting-edge spec that bakes privacy straight into the token itself, delivering a lean, low-cost fix for niche headaches that today’s add-ons handle poorly.

Yet ripping out address-based ownership would mean rewiring every wallet, block explorer, tax tool, and user habit we’ve spent years cementing—an overhaul so steep that mass migration is almost off the table.

Rather than dethrone ERC-20 or ERC-721, the standard is far likelier to thrive alongside them, serving privacy-first apps, gas-subsidized products, and permissioned enterprise flows as a specialized sibling, not a universal successor.

47

I’m currently learning about Ethereum, and after reviewing ERC-7962, I was reminded of the 2021 auction of a copy of the U.S. Constitution organized by ConstitutionDAO. Perhaps due to the transparency of on-chain fundraising, the auction lost by a narrow margin. If the ERC-KeyHash20 transfer design from ERC-7962 had been used, the outcome might have been different.

49

We often talk about asset ownership, but Alex’s example of “Starbucks members entering an Airport Lounge” made me realize the fatal defect of ERC-721 in real-world commercial scenarios: Zero Privacy.

Here are my study notes and some critical thoughts on ERC-7962. I welcome any discussion or counter-arguments:

1. The Core Breakthrough: An NFT Version of the UTXO Model

I believe this is the most “hardcore” design of the protocol. Traditional ERC-721/20 balance models inevitably lead to address reuse, allowing on-chain detectives to easily map out a user’s complete Asset Graph via the ownerOf function.

ERC-7962 introduces a UTXO-like “One-Time Key” mechanism similar to Bitcoin. Once a Key Hash interacts (e.g., transferring part of the tokens), the remaining assets are automatically moved to a new, mathematically unrelated Key Hash. This “automatic rotation” severs the transaction traceability link from the bottom up, effectively achieving “Front-end Invisibility, Back-end Verification”.

2. A Pragmatic Trade-off on “Decentralization”

In the Q&A session, Alex was very honest about the fact that to achieve the ultimate Web2 user experience (No Gas, No Seed Phrases), ERC-7962 sacrifices some decentralization in actual implementation (like the DataD case).

• Relayer Mode: Users only need to sign a message to express intent. The merchant (e.g., Starbucks) acts as the Relayer to put the transaction on-chain and pay the Gas.

• Reflection: While the on-chain signature ensures that asset ownership cannot be tampered with, this model relies heavily on the liveness of the Relayer. If the merchant’s server goes down or they decide to censor, the user—despite owning the asset on-chain—might be temporarily unable to operate it. This seems to be a necessary compromise to “onboard Web2 users”.

3. A Potential Compatibility Challenge: The Vanishing Approve

To prevent the public key from being exposed during authorization, ERC-7962 removed the approve mechanism entirely.

This is a very bold design choice. We know that mainstream protocols like OpenSea and Uniswap rely heavily on the approve + transferFrom logic. This implies that ERC-7962 cannot be directly compatible with existing NFT marketplace infrastructure and may require the construction of a separate trading ecosystem. Will this limit its initial liquidity?

Conclusion: ERC-7962 is a standard with a strong sense of “commercial pragmatism.” It moves away from the technical purity of demanding users manage their own private keys. Instead, through Key Hash and Account Abstraction, it attempts to untie the deadlock where enterprises are afraid to use Web3 (due to client privacy leaks) and users don’t know how to use Web3 (due to high barriers).

I look forward to seeing more real-world use cases land based on this standard!

50

Just came here cause too many anormaly comment. @SamWilsn did you think the same as me?

52

I’m new to Ethereum and just checked out ERC-7962,which addresses critical privacy gaps in existing Ethereum token standards by using keyHashes instead of public addresses, effectively reducing on-chain identity linkability. The split between ownership and transaction initiation, plus third-party gas sponsorship, makes it super accessible for Web2 folks too. Honestly, it balances privacy, ease of use, and security in a way that feels long overdue!

53

ERC-721 successfully established the foundation of NFTs by enabling on-chain ownership and uniqueness. However, as NFT applications expanded, its limitations became evident, especially in terms of flexibility, upgradeability, and support for complex use cases. These issues make it less suitable for long-term or large-scale applications.

ERC-7962 attempts to address these problems by introducing a more modular and extensible design. This allows NFTs to evolve without frequent contract redeployment, which can significantly reduce development and maintenance costs. From this perspective, it represents a meaningful improvement toward practical and sustainable Web3 infrastructure.

That said, some questions remain. The added flexibility may increase system complexity, raising concerns about security risks and implementation difficulty. I am also curious about how widely ERC-7962 will be adopted and whether existing ERC-721 projects can migrate smoothly. Overall, ERC-7962 is a promising step forward, but its real impact will depend on adoption, tooling support, and long-term performance in real-world applications.

54

I have carefully read the ERC-7962 protocol you compiled. The further development ideas regarding privacy are quite significant.

Regarding the specific application scenarios of member identification in it, I have a few thoughts.
Currently, the mainstream method for the project party to conduct token distribution is to conduct a transaction snapshot. After using the ERC-7962 protocol, the snapshot becomes a hash key instead of a wallet address. So, as a user, is there a way to identify whether the project party is using ghost accounts to encroach upon users’ rights during the emptying phase while protecting privacy? Otherwise, the implementation of the second season’s token distribution plan will be affected.

Thank you!

55

Sorry, I just noticed. I think it might be because I gave a presentation on ERC-7962 to a class of students, and the tutor encouraged them to discuss and share their thoughts. So perhaps it has caused some inconvenience regarding this post on the forum. I have spoken with the tutors, and they have made some adjustments, so things might improve later.@SamWilsm

1 Like
56

Traditional ERC-20 tokens make all asset movements on-chain transparent, which sometimes involves privacy-related issues. The KeyHash mechanism and the logic of mandatory change to new hashes introduced by ERC-7962 is a giant step forward in privacy protection at the protocol level, making on-chain footprints harder to track. While this extremely strong privacy attribute protects users, it may also face challenges in terms of compliance. I am curious about how the developer community views the compatibility issue between this standard and the future of RWA compliance.

57

ERC-7962 is a conceptual exploration of Ethereum’s token ownership model: by replacing addresses with key hashes, it decouples authorization from transaction execution and elevates privacy improvements and gas sponsorship to first-class design goals. While this vision is coherent and forward-looking, its privacy largely relies on user discipline rather than protocol-level guarantees, its UTXO-style model conflicts fundamentally with the account-based DeFi ecosystem, and it introduces significantly higher implementation and security complexity. As a result, ERC-7962 is better viewed as a research-oriented and experimental standard than as a practical successor to ERC-20 or ERC-721 in the near term.

58

I feel that ERC-7962 successfully decouples identity and ownership through KeyHash and UTXO models, but there are still limitations in the Relayer interaction layer regarding privacy leaks and traceability of the fund chain, because ERC-7962’s hash mechanism achieves static privacy but does not solve dynamic privacy. If the Relayer is malicious or subject to regulatory review, they can still associate it with real-world identity based on IP address, transaction timestamp, and Gas fee payment source. Therefore, I have a bold idea to cut off the direct connection between the Relayer and the funds by introducing a ‘Privacy Pool + ZK Credential’ mechanism. Here, the hidden pool involves pooling a large sum of funds, making it impossible for the agent to know the source of these funds or to link them to their real-world identity through timestamps and Gas fee payment sources. The ZK credential uses cryptographic mathematics to correspond “deposit rights” and “withdrawal rights” in the air without revealing information, providing the agent with a credential to transfer and trade. The agent does not know who the recipient of this credential is. ERC-7962 hides “identity,” uses the Privacy Pool to hide “relationships,” and finally securely connects using ZK Credentials. In summary, ERC-7962 hides “identity,” uses the Privacy Pool to hide “relationships,” and finally securely connects using ZK Credentials

59

I read ERC-7962 and like the idea of using keyHash = keccak256(pubkey) + signatures to decouple the signer from the tx sender (sponsorship / delegation) while keeping ownership off plain addresses. The forced key rotation via leftKeyHash is also interesting.But I’m still unsure about this: For ERC-KeyHash20, does the leftKeyHash != from/to rule create practical friction for common flows (partial sends, batching), and is there a recommended pattern for multi-output transfers?

60

A pragmatic middle ground between ERC-20 and ZK-Privacy

This proposal strikes a pragmatic balance between the radical transparency of ERC-20 and the heavy-duty anonymity of protocols like Tornado Cash or Railgun.

While solutions like Tornado Cash focus on mathematically “breaking” the link between deposit and withdrawal via mixers, and Railgun creates a shielded pool for DeFi interactions, ERC-7962 offers a lightweight alternative: Privacy by Obfuscation.

By enforcing a UTXO-like model with keyHash, this standard provides excellent forward privacy. Although the transaction graph remains visible (unlike ZK solutions), the irreversibility of the hash effectively mitigates the risk of simple “address labeling” by analytics firms (e.g., Nansen or Etherscan). This level of privacy is likely sufficient for many commercial use cases—such as GameFi rewards or B2B settlements—where the goal is protecting business intelligence rather than evading state-level surveillance.

Furthermore, the native separation of authorization (signing) and execution (gas payment) solves a major UX hurdle that usually requires complex meta-transaction relayers.

One concern/suggestion: The success of this standard will depend entirely on wallet integration. Since the “change output” (leftKeyHash) logic mirrors Bitcoin’s UTXO model, current Ethereum wallets aren’t designed to manage these “disposable key pools”. It might be beneficial to mention or standardize a “Key Discovery” mechanism to prevent users from losing track of their fragmented balances.

61

English Comment (EN)

ERC-7962 (Key Hash Based Tokens) introduces a meaningful architectural shift compared to traditional ERC-20 and ERC-721 standards by decoupling asset ownership from Ethereum addresses and representing ownership through a keyHash verified by EIP-712 signatures.

From a privacy perspective, this is a significant improvement. In current token standards, addresses are publicly visible and easily linkable through on-chain analysis, which exposes users’ identities and financial behavior. By storing only the keyHash on-chain while keeping the hashKey off-chain, ERC-7962 provides a lightweight privacy enhancement without relying on zero-knowledge proofs. This approach is particularly attractive for high-value NFTs, institutional finance, and decentralized identity (DID) use cases.

Another notable advantage is the separation of ownership and transaction initiation. This design natively supports gas sponsorship and batch operations, reducing user friction and enabling third-party relayers to handle transaction costs. Such flexibility can greatly improve user experience in gaming platforms, NFT marketplaces, and large-scale token distribution scenarios.

However, there are also trade-offs to consider. The hashKey must still be used during signature generation, which introduces potential risks if key management is poor. Additionally, EIP-712 signature verification increases gas consumption, and the conceptual complexity of managing hashKeys may raise the learning curve for non-technical users.

Overall, ERC-7962 should be viewed not as a replacement for existing standards, but as a complementary option tailored for privacy-sensitive and enterprise-level applications. With improved wallet abstraction and key management tooling, this standard could become a strong foundation for next-generation privacy-aware token systems.

62

Yes, You’re absolutely right. It is recommended that wallet/SDK implementers integrate an ERC-5564-style stealth address scheme to automatically generate and manage one-time keys, rather than requiring users to manually reuse or manage key pairs.

To achieve “unlinkable change,” ERC-KeyHash20 borrows Bitcoin’s forced change-address mechanism, at the cost of one extra state write compared to standard ERC-20, and requiring wallets to additionally manage a “change key” for every transfer. This is a tradeoff between privacy and gas cost/engineering complexity. Implementers are encouraged to automate key derivation at the wallet layer (e.g., by batch pre-generating keys via a stealth address scheme) to reduce this complexity for end users. At the protocol level, one could also consider allowing the leftKeyHash check to be skipped for full-amount transfers (remaining = 0) to further cut costs, but the current version of the spec does not include this optimization.

It’s very nice of you for digging into this.You’re right that we’re tightly coupled to secp256k1/ecrecover right now, and that’s intentional for v1 — it keeps the privacy trick (address derived straight from the pubkey) simple and cheap, without needing extra on-chain state to track verifier types.

A broader verifier model (pubkeys, EIP-1271 contracts, P-256/passkeys, threshold keys) is definitely something we’ve thought about conceptually, e.g. tagging keyHash with a verifier type and dispatching accordingly. But it’s not a free extension — EIP-1271 in particular is in real tension with the “unrevealed until spend” property since contract addresses are public and pre-deployed, and any multi-verifier setup opens up downgrade-attack surface we’d need to design around carefully.

we’ll extend this if/when there’s real demand for it, but we’re not committing to a specific direction yet. Keeping it minimal for now was a deliberate choice, not an oversight. Appreciate the push though, this is exactly the kind of feedback we want during the draft phase.

63

AA solves “how an account can be operated,” while ERC-7962 solves “how ownership can avoid being tracked” — these are two different dimensions of the problem. AA doesn’t actually solve the problem ERC-7962 is targeting (privacy). Even with a smart account + Paymaster, ownerOf/balanceOf still returns a public, permanent address (the smart account address itself). That address remains permanently linkable — anyone can still look up what that smart account has held or transacted historically.

Gas sponsorship is a byproduct of ERC-7962’s signature model, not a design goal in itself. The “separation of gas payment from ownership” mentioned in the spec is simply a natural side benefit of the model where “ownership is proven via signature, and anyone can submit the transaction” — this ERC isn’t specifically trying to solve “gas sponsorship” as a way to compete with AA. The core goal has always been privacy (keyHash replacing addresses); gas flexibility just comes along for free.

The two aren’t mutually exclusive either — they can be stacked. You can absolutely use a smart account to call ERC-7962’s transfer (with the smart account acting as the relayer and a Paymaster covering gas), while token ownership is still tracked via keyHash without exposing any address. In other words, AA handles “how this call gets initiated and who pays for it,” while ERC-7962 handles “how this token’s ownership stays unlinkable” — one is the account layer, the other is the token-ownership layer. They can coexist and complement each other; it’s not an either-or competition.

Gas overhead comparison isn’t necessarily a losing trade either. ERC-4337 itself carries substantial overhead — bundlers, the EntryPoint contract, account validation logic, and the whole associated flow. By comparison, ERC-7962 is just a single EIP-712 signature plus an ecrecover call — on gas alone, it’s not necessarily heavier than a full AA transaction. And regardless of whether AA is used or not, ERC-7962 doesn’t add “extra” or “unnecessary” overhead on top of an equivalent AA setup — because AA never provided privacy capabilities in the first place. This overhead is ERC-7962’s unique value, not duplicated spending.

64

Both are good questions, let me address them directly.

On infrastructure friction (the cold start problem): You’re right, the current draft doesn’t offer a migration path or compatibility layer, that’s a real gap. Indexers would need custom subgraphs for KeyHashTransfer721/KeyHashTransfer20, explorers can’t meaningfully render a bytes32 keyHash as a “holder,” and wallets need to rework balance aggregation logic. This tooling cost is genuine and falls on the ecosystem as a whole, not something an adapter layer can trivially paper over. This is something we need to work on for a future revision, possibly with reference indexer/subgraph implementations to lower the integration bar.

On privacy trade-offs: Also a fair challenge, and I want to be precise rather than oversell this. Compared to standard ERC-20, where balanceOf(address) is a direct, permanent, near-zero-cost lookup, forcing a fresh keyHash per transfer removes that direct query entirely, an analyst has to stitch together a holder’s history across disconnected keyHashes using indirect signals. That’s a real, structural increase in analysis cost.

But it doesn’t make tracking “nearly impossible.” What this mechanism defeats is address-reuse clustering. What it does not defeat is amount and timing correlation, the same technique that still lets firms like Chainalysis trace Bitcoin despite its design forcing fresh change addresses. If A transfers in an amount and B transfers out a near-identical amount shortly after, that’s a strong linkage signal regardless of how many times the keyHash changed in between. Actually closing that gap would require something like mixing/CoinJoin or ZK-based amount hiding, which is out of scope for this proposal. So the more accurate framing is: compared to ERC-20, this significantly raises the cost of on-chain analysis and lowers the reliability of its conclusions, but that’s not equivalent to unlinkability against a sophisticated analyst.

The practical recommendation for implementers is to pair this with ERC-5564 stealth addresses for automated one-time key derivation (eliminating the “lazy key reuse” failure mode), and to use Announcement-based discovery rather than off-chain coordination (avoiding leaking correlatable metadata through side channels). Amount/timing obfuscation is out of scope for the token standard itself and would need to be handled at the application layer.

Thanks for pushing on both of these, I’ll record the tooling gap and the more precise privacy framing as open items for the next draft.

65

You’re absolutely right that keyHash and address are both just one-way encodings of the same underlying public key, and the public key itself is the true root identifier. That much is correct. But concluding that “the two approaches are essentially the same” overlooks two points.

First, “the public key can be computationally recovered” and “the public key can be directly indexed and queried” are not the same order of difficulty. An address is permanently public and queryable from day one, whereas a keyHash’s corresponding public key can only be computed after a specific transfer signature has actually occurred. More importantly, even if the public key leaks, asset control remains secure — without the private key, no valid signature can be forged. What’s weakened is privacy, not security.

Second, keccak256(key) is just the minimal baseline implementation. Implementers can perfectly well switch to keccak256(key || salt) at deployment. That way, even if the public key leaks, it can’t be mapped back to which on-chain keyHash it corresponds to, further cutting the linkage.

You’re right that the public key is the ultimate identifier and that you can’t have your cake and eat it too — ERC-7962 doesn’t claim to achieve perfect unlinkability. Its value lies in turning “revelation” from a protocol default of permanent public exposure into an on-demand, one-time, protocol-enforced key-rotation event (the leftKeyHash strict mode), while still keeping assets safe from theft even after revelation. This is genuinely a tradeoff-based approach, not a definitive solution to all linkability concerns.

66

From a wallet-user perspective, I agree that key discovery is essential. People should not need to understand or manually keep track of separate key hashes to know what they own.

A good wallet experience should make it clear what the total balance is, which parts are spendable, and what happens when someone restores on a new device. If that is unclear, users may reasonably worry that funds have disappeared even when they have not.

It would be helpful for the standard to set clear expectations around discovery and recovery, so wallet behavior is more consistent from the start.

1 Like