ERC-7962: Key Hash Based Tokens

ERCs
22

Hi,

I’ve been following the evolution of EIP-7962, particularly the shift towards a UTXO-like model for key rotation. While this significantly enhances on-chain privacy by breaking linkability between transfers, I see a critical gap in the off-chain transaction propagation layer that undermines the proposal’s core value proposition.

The Problem: Fragile Privacy via Relayers The proposal relies on third-party Relayers for gas sponsorship and transaction submission. However, in a standard architecture, users submit signed payloads directly to a Relayer via RPC/HTTP.

  • Result: The Relayer (and potentially the ISP) captures the user’s IP Address and metadata alongside the transaction intent.
  • Risk: While the blockchain sees a “KeyHash,” the Relayer sees “IP 1.2.3.4 is controlling this KeyHash.” This creates a centralized point of failure for anonymity. True privacy requires protecting both the Asset Graph (on-chain) and the Network Graph (off-chain).

Proposed Solution: Decentralized Gossip (e.g., Waku) as a Standard To achieve genuine censorship resistance and anonymity, we cannot treat the transport layer as an afterthought.

I propose that EIP-7962 should explicitly recommend (or include in the reference implementation) integrating a decentralized gossip protocol like Waku for intent propagation:

  1. User broadcasts the signed transfer payload to the Waku p2p mesh.
  2. Relayers listen to the Waku topic, pick up valid payloads, and submit them on-chain.
  3. Benefit: The Relayer receives the message from a random peer in the mesh, effectively obfuscating the originator’s IP address.

Would love to hear your thoughts on standardizing the transport layer requirements for this EIP.

23

Hello, I have a few questions regarding the proposal:
Since the standard emphasizes “one-time keys” and mandatory change, are there any recommended default practices for wallets? For example, practical suggestions such as “automatically generating a new keyHash for each transaction, a rollback process in case of failure, and a minimum key pool size”?
If bulk and gas sponsorships are supported, could you share a simple benchmark (gas comparison of single transaction vs. bulk transaction under strict change mode), and what merging/aggregation can the wallet side do to make the user’s actual cost more controllable?
Then, in the repeater-sponsored gas model, will the option of decentralized message propagation (such as Waku) be added to the reference implementation or proposal to alleviate the problem of “who submitted the signature” being associated at the network layer?
When integrating with existing DeFi, will there be a draft specification for an “official adapter/wrapper” (interface, events, unpacking process) to prevent fragmentation caused by different teams implementing it independently (like the old mobile phone charging interface)?
I’m delighted to see such an excellent proposal for a privacy layer. Although I’m just a small user, I care a lot about privacy and look forward to it truly helping us in the future.Hello, I have a few questions regarding the proposal:
Since the standard emphasizes “one-time keys” and mandatory change, are there any recommended default practices for wallets? For example, practical suggestions such as “automatically generating a new keyHash for each transaction, a rollback process in case of failure, and a minimum key pool size”?
If bulk and gas sponsorships are supported, could you share a simple benchmark (gas comparison of single transaction vs. bulk transaction under strict change mode), and what merging/aggregation can the wallet side do to make the user’s actual cost more controllable?
Then, in the repeater-sponsored gas model, will the option of decentralized message propagation (such as Waku) be added to the reference implementation or proposal to alleviate the problem of “who submitted the signature” being associated at the network layer?
When integrating with existing DeFi, will there be a draft specification for an “official adapter/wrapper” (interface, events, unpacking process) to prevent fragmentation caused by different teams implementing it independently (like the old mobile phone charging interface)?
I’m delighted to see such an excellent proposal for a privacy layer. Although I’m just a small user, I care a lot about privacy and look forward to it truly helping us in the future.

24

Hi ,
I’ve been diving into the ERC-7962: Key Hash Based Tokens proposal with great interest. As an Ethereum enthusiast, I find the concept of decoupling ownership from transaction initiation really innovative, particularly how it utilizes keyHash for privacy and enables native gas sponsorship. The shift away from address-based ownership towards a signature-driven authorization model seems like a significant step forward for privacy-preserving applications.
However, I’ve been pondering the implications for Gas efficiency, and I was wondering if the community has considered a few potential optimizations?

  1. Overhead of Signature Verification I noticed that the transfer function relies heavily on on-chain ECDSA signature recovery (ecrecover) and EIP-712 structured data hashing for every transaction. While this ensures robust security against tampering, I am curious if there are benchmark comparisons showing how this gas cost stacks up against a standard ERC-721 transferFrom? Since we are removing the approve logic (which saves gas on approvals), does the per-transfer signature verification offset those savings for high-frequency users?
  2. Native Batching Interfaces Since one of the core value propositions is separating the “signer” from the “payer” (gas sponsor), it feels like this standard is uniquely positioned to handle batch transactions more naturally than ERC-721. Would it be beneficial to include a standardized batchTransfer interface directly in the specification? As suggested in some discussions, a function allowing multiple inputs (fromKeyHashes) and outputs to be processed in a single transaction could significantly amortize the base gas costs, making the protocol much more efficient for gaming or airdrop scenarios.
  3. UTXO-like Model and Key Rotation Regarding the ERC-KeyHash20 fungible token interface, the strict requirement for a leftKeyHash (change address) to enforce key rotation is fascinating. From a gas perspective, I wonder if the constant generation and management of fresh key pairs might introduce “hidden” gas costs or computational overhead for wallets? Perhaps an optional “non-strict” mode could be considered for use cases where gas efficiency is prioritized over maximum forward privacy?
    I am really excited to see where this standard goes. The potential for “gasless” user experiences via relayers is huge, and optimizing the on-chain execution costs seems like the final piece of the puzzle to drive adoption.
25

I’m not from a technical background and I’m still pretty new to the space, so my focus is more on whether a standard can actually be implemented in the real world.

Here’s how I understand ERC‑7962:
7962 is trying to unify all the “yield‑growing tokens” into a common format that wallets, protocols, and aggregators can easily understand.
I think the idea is quite practical, because right now every yield asset works differently, and integrating them is honestly a headache.

After reading it, a few questions naturally came to mind:

  1. There are so many types of yield models—can they really be unified?
    LSTs and LRTs are manageable, but once you have more complex strategies or multi‑layered yield products, things get messy.
    I’m curious whether 7962 can actually scale to cover all of that.

  2. The standard itself isn’t the hard part—the hard part is who adopts it.
    Honestly, the biggest issue is:
    if major protocols don’t adopt the standard, it won’t move.
    I’m curious whether big players like Lido, EigenLayer, Pendle, Yearn, etc. are interested in supporting it.

  3. Risk information still feels quite fuzzy.
    Yield can be standardized, but every protocol describes risk differently.
    If the information varies too much, wallets or downstream protocols may still struggle to provide meaningful risk warnings.

  4. DeFi is multi‑chain now—how will this standard work across chains?
    If the long‑term plan is for other chains or L2s to adopt it, that becomes a whole different battle.

Overall, I think 7962 is heading in a valuable direction, especially for making downstream integrations easier.
But from my perspective, adoption, collaboration willingness, and downstream demand will ultimately determine its success.

I’m also curious how this standard will evolve and which teams will be the first to adopt it.

26

My concern is that ordinary users may find it difficult to understand why their address changes every time they send a payment. Furthermore, if the front-end wallet layer fails to implement robust automated key management (such as Hierarchical Deterministic Wallets), users run a high risk of losing control over their ‘change addresses’.

27

I’d like to raise a concern regarding Sybil Resistance and Relayer Griefing.

One of the core value propositions mentioned is separating ownership from gas payment (gas sponsorship). However, since generating a hashKey / keyHash pair is an off-chain action with zero cost (unlike funding an EOA with ETH), this creates a massive vector for Sybil attacks against the Relayers.

An attacker could:

  1. Generate 10,000 fresh keyHash identities offline.

  2. Broadcast 10,000 valid signatures for minimal operations (e.g., claiming a token or a zero-value transfer) to a Relayer.

Since the identities are anonymous and distinct on-chain, the Relayer cannot easily filter them based on history or funding source. If the Relayer processes these, the attacker effectively drains the Relayer’s funds via gas fees at zero cost to themselves.

Does the standard plan to include any mechanism to mitigate this (e.g., requiring a minimum balance proof before processing), or is this strictly left to the application layer?

28

After the bottleneck of on-chain and off-chain privacy is broken, will the expansion of application scenarios grow exponentially? Can the subsequent computing power support it? Will it impact the original system?

30

After listening to your presentation and carefully reviewing the ERC-7962 specification, I find the idea of allowing third parties to sponsor gas fees to be a very compelling innovation. I have a few questions:

  1. DeFi Integration
    In the absence of the traditional approve function, how can ERC-7962 tokens efficiently interact with existing liquidity pools or AMM protocols? Would it be necessary to design new protocols that rely on signature-based authorization instead of allowance-based approvals?

  2. Gas Overhead
    Since ERC-7962 introduces additional ECDSA signature verification and EIP-712 hashing, will the gas cost per transaction increase significantly compared to standard ERC-20 or ERC-721 interactions?

  3. Compatibility
    By using KeyHash instead of addresses, how can ERC-7962 maintain compatibility or interoperability with existing ERC-20 and ERC-721 standards and their surrounding ecosystem?

31

I see ERC-7962 as a valuable but largely exploratory attempt.

By using keyHash instead of direct address-based ownership, the proposal introduces a stronger privacy abstraction at the standard level, while also supporting the separation between the signer and the gas-paying address. This is an interesting direction, especially for identity-, credential-, or privacy-sensitive use cases.

That said, I do have some questions and concerns.
First, the cost of ecosystem compatibility is relatively high, as existing wallets, indexers, and marketplaces are almost entirely built around the address-based model, making migration non-trivial.
Second, the actual privacy gains may be limited in practice — once the public key is revealed in calldata, it can still be linked off-chain.
Third, the increased implementation complexity and additional signature verification logic may raise gas costs and the overall development barrier.

I see ERC-7962 as better suited as a complementary standard for specific privacy or identity-related scenarios, rather than a short-term replacement for general-purpose asset standards. It would be very interesting to see more real-world use cases or hybrid approaches that balance privacy improvements with compatibility with the existing address-based ecosystem.

32

ERC-7962 is one of the more elegant and pragmatic privacy-oriented token standards I’ve seen proposed for Ethereum in recent years.The core idea—replacing address-based ownership with keyHash = keccak256(uncompressedPubkey) and requiring fresh keys after every state-changing action—is conceptually clean. It delivers meaningful forward privacy (post-transfer unlinkability via mandatory key rotation) and historical unlinkability (because past records only show irreversible hashes) without forcing users into a full ZK ecosystem. For many realistic privacy use cases (anonymous collectibles, private membership tokens, off-chain-coordinated payments, or regulatory-sensitive corporate tokens), this strikes a reasonable balance between privacy strength, developer complexity, and gas cost.

However, I have some questions wanted to ask:

  1. Has anyone modeled how effective this is against realistic chain-analysis clusters (e.g., after 5–10 transfers with change outputs)? How does it compare empirically to stealth addresses (ERC-5564) + view keys?

  2. Companies needing auditable-but-private tokens (e.g., tokenized carbon credits, internal vouchers) seem like a sweet spot. Are there any pilots already underway?

Thanks for your time to check. Looking forward to your reply!

34

@0x-IHRR and I share the same concern, what the least-invasive integration strategy is for today’s DeFi:

  1. Do you envision a canonical wrapper/adapter (KeyHash20/721 ↔ ERC-20/721) so ERC-7962 assets can reuse existing DEX/lending/staking infra without rewriting core protocols? If so, would standardizing the wrapper interface/events help avoid fragmentation?

  2. Beyond wrappers, is there a recommended “approve replacement” for controlled delegation (scoped, time/amount-limited, revocable session authorization) that preserves the one-time-key / rotation goals?

  3. For users who interact with DeFi frequently, requiring one-time keys and explicit per-action signatures (plus key rotation / change management) may be too heavy compared with today’s approve/allowance workflows.
    Do you envision a “practical UX layer” on top of ERC-7962—e.g., scoped session delegation (time/amount/contract-limited), batching multiple intents into a single signature/transaction, or is the expectation that high-frequency users will mainly rely on wrappers back to ERC-20/721 for composability?

35

I want to learn that in the design of ERC-7962, has the scenario of fixed-supply tokens been considered? If mint/destroy functions are absent, can the standard still ensure broad applicability?If mint/destroy functions are allowed, how can the interface avoid creating compatibility burdens for wallets, DEXs, and other general-purpose tools?

36

Hi there! This looks like a really interesting proposal.

I’m still new to these standards, so I apologize if I’m missing something obvious. I’m trying to understand how this fits in with existing solutions:

  • For gas: It seems like ERC-4337 (AA) Paymasters already handle gas sponsorship.

  • For privacy: From what I understand, ERC-5564 (Stealth Addresses) provides anonymity without needing to change the token standard itself.

Could you help me understand the main advantages of this approach compared to combining those existing standards?

38

I really like ERC 7962 and I see it as a major step forward for expanding practical use cases of web3.

One practical weakness of ERC 7962 is handling highly dynamic real world credentials. In many offline scenarios, qualifications change frequently. Employees leave, memberships expire, and access rights may need to be frozen temporarily. While ERC 7962 technically supports burning or invalidation, the current model still feels very engineering driven from a user experience perspective.

At scale, especially with many offline checkpoints or third party verifiers, revocation becomes a systems problem. How to achieve near real time synchronization, low latency verification, and low cost revocation across distributed terminals is not clearly addressed at the standard level.

A possible direction worth discussing is treating revocation as a core design concern, for example through standardized revocation registries, short lived credentials, or verifier friendly caching and update mechanisms. Without a clear and operational revocation story, adoption in real world environments with frequent state changes will remain difficult.

39

I think ERC-7962 introduces a very interesting ownership abstraction by replacing address-based ownership with keyHash. From a privacy and UX perspective (especially gas sponsorship and offline authorization), this feels like a meaningful step forward compared to traditional ERC-20/721 models.

That said, the current privacy guarantees seem more “unlinkability-reducing” than true strong privacy, since public keys still appear in calldata during execution. In practice, the effectiveness heavily depends on wallet-level key rotation and tooling, which are not yet widely available.

Another open question is composability: many existing DeFi and NFT protocols assume address-based ownership, so ERC-7962 may need standardized adapter patterns to interoperate with the current ecosystem.

I’m curious about how ERC-7962 maintainers think about practical privacy guarantees in real-world usage. Since public keys are still revealed in calldata during execution, how do you envision preventing long-term linkage if wallets don’t strictly enforce one-time or rotating keys?

Additionally, is there any ongoing discussion around standardized adapter patterns to improve composability with existing address-based DeFi/NFT protocols, or is ERC-7962 intentionally positioned as a more isolated primitive?

I’d love to hear how you see these trade-offs evolving as tooling matures.

Overall, I see ERC-7962 as a strong experimental primitive rather than a drop-in replacement, with real potential in privacy-sensitive NFTs, credentials, and gas-sponsored UX if tooling and patterns mature.

40

I think the core of the ERC-7962 proposal lies in focusing on privacy and flexibility. It replaces the original address with keyHash, separates asset ownership from the initiator of the transaction, and adds several layers of security mechanisms, precisely addressing the privacy shortcomings of traditional ERC-20 and ERC-721 standards. Moreover, it can accommodate large-scale demands such as batch transfers and third-party gas payments, making it quite practical.

Its most valuable aspect is finding a balance between the inherent transparency of the blockchain and the privacy users desire, without sacrificing operational flexibility and maintaining security. It is suitable for scenarios like high-end NFT collections, private financial transfers, and platforms distributing benefits to a large number of users.

41

My take is that ERC-7962 can meaningfully reduce public address linkability, but it doesn’t magically “solve privacy” end-to-end. Once you spend, you still leak information through the transaction itself (e.g., the public key shows up), and in practice most people will route intents through relayers/paymasters/RPCs. That shifts a lot of the privacy burden from “what’s on-chain” to “who sees my intent + metadata off-chain”, which feels like the real bottleneck.

On scalability, I’m not too worried about raw “compute” in the abstract—the EVM will price whatever work we ask it to do—but the design choices matter: frequent key rotation / change-style outputs can increase storage churn, and batching is a double-edged sword. It’s great for amortizing overhead and UX, but it also makes it easier to pack a lot of ops behind one sponsored transaction, so the relayer becomes both the scaling lever and the DoS choke point.

If we want to claim “privacy bottleneck broken”, I’d like to see a clearer threat model for relayers/RPCs and some recommended defaults for transport-level privacy and abuse controls.

42

Hi everyone,

I’ve been following the discussion and wanted to echo the points raised by @0xBrick-Li regarding compatibility and @annecn037 regarding privacy limitations.

From a development perspective, I have a few concerns about where ERC-7962 fits into the current roadmap:

  1. Conflict with Account Abstraction (ERC-4337/EIP-7702): The ecosystem is already solving “Gas Sponsorship” and “Signer Separation” at the account level via Paymasters and Smart Accounts. By embedding this logic directly into the token standard, are we essentially duplicating the work of AA? It seems like this adds unnecessary gas overhead for a feature that might soon be handled globally by the account layer.

  2. Infrastructure Friction (The “Cold Start” Problem): Beyond the DeFi integration issues mentioned earlier, I’m concerned about the tooling gap. Indexers (The Graph), explorers (Etherscan), and wallets are optimized for standard address formats. If KeyHash becomes the norm for this standard, does the proposal include a migration path or a “compatibility layer” for existing off-chain infrastructure? Without it, the integration cost for dApps seems prohibitively high.

  3. Privacy Trade-offs: If the public key is revealed in the calldata for EIP-712 verification, the privacy gain seems strictly temporary (pre-interaction). Is the complexity of managing non-standard addressing worth it if the on-chain footprint can still be linked by sophisticated analytics tools?

I’d love to hear if the authors view this as a niche standard for specific privacy credentials, or if there is a plan to bridge the gap with the existing AA ecosystem.

43

I’ve spent some time reading through ERC-7962 and the discussion here, and I find the idea of key-hash-based ownership quite interesting. It feels like a meaningful attempt to rethink how token ownership is represented on Ethereum, rather than just layering features on top of existing address-based models.

What I find most compelling is the separation between “who owns the token” and “which address submits the transaction.” This could make relayer-based or gas-sponsored flows much smoother, and in theory give users a better experience where they don’t need to worry as much about holding ETH just to move assets. I also like that the design moves away from directly tying ownership to a single visible address, which could be useful for privacy-sensitive use cases like high-value NFTs or institutional token management.

That said, I do have a few open questions and concerns that I think are worth discussing:

  1. Privacy in practice:
    While using a keyHash instead of a direct address is a clear improvement, signatures still reveal the public key during verification. I’m curious how strong the privacy guarantees really are in real-world usage. Would users need to rotate keys frequently to avoid linkability? If so, how complex would that be in practice?

  2. Wallet and ecosystem support:
    Most existing wallets, explorers, and marketplaces are built around addresses as identities. It’s not entirely clear to me how smoothly ERC-7962 tokens would integrate with current tooling. Would this require major wallet UX changes, or is there a lightweight way to support this model without breaking too much of today’s infrastructure?

  3. Batch operations and gas efficiency:
    I wonder if the standard should more explicitly consider batch transfers or aggregated proofs. If this model is meant to scale for games, airdrops, or large collections, clearer guidance on batching could make it more practical.

Overall, I see ERC-7962 as an interesting complementary model rather than a replacement for ERC-20 or ERC-721. It introduces a different way of thinking about ownership that could be very useful in specific contexts, especially where privacy and flexible transaction submission matter.

I’m curious to hear how others see this tradeoff between new flexibility and compatibility with today’s Ethereum tooling

44

ERC-7962 represents a fundamental paradigm shift from the legacy “address-centric” model of ERC-721 to a “privacy-first, intent-centric” architecture1. By replacing public wallet addresses with $KeyHash$ as the primary identifier of ownership, the protocol effectively decouples the user’s permanent on-chain identity from their transient asset holdings.

The Strategic “Badass” Perspective: The UX-Privacy Convergence

The most compelling aspect of ERC-7962 is its solution to the “Privacy-UX Paradox.” Historically, privacy-preserving tools have been friction-heavy. However, by integrating Relayer/Paymaster mechanisms (Gas Sponsorship) and separating the transaction initiator from the asset owner, ERC-7962 creates a bridge for mass adoption

Decoupling Execution from Ownership: The ability for any address to initiate a transaction via a signed intent ensures that users—whether humans or AI Agents—can operate without the burden of gas management or complex wallet interactions.

The UTXO Evolution: Implementing a UTXO-style “One-time Key” rotation is a bold architectural choice. It transforms the public ledger from a surveillance tool into a robust trust-anchor, where asset flows remain unlinkable to the prying eyes of chain-analysis6.

Technical Critique & Critical Questions

While the vision is stellar, the implementation faces “Real-World” friction points that warrant further exploration:

Algebraic Limitations: The current implementation utilizes Hash-based proofs primarily for equality verification. In a future dominated by complex DeFi logic, will the protocol eventually evolve toward a full algebraic Zero-Knowledge (ZK) system to support inequalities (e.g., “Does this AI Agent have at least X reputation?”) without compromising the $KeyHash$ foundation8?

Key Rotation Fatigue & Gas Economics: While the protocol mandates key rotation for privacy integrity , this inevitably leads to higher gas costs compared to standard ERC-20/721 models. How can we optimize the Spoon OS layer or L2-specific precompiles to mitigate the “Privacy Tax” for high-frequency micro-transactions?

The “Key Management” Single Point of Failure: By removing the approve mechanism to protect the public key, the burden shifts entirely to the user’s ability to manage their in . For the next billion users, what does a decentralized “Social Recovery” mechanism look like for a $KeyHash$-based identity?

Conclusion

ERC-7962 is not just a token standard; it is a blueprint for the Machine Economy. It provides the necessary infrastructure for AI Agents and privacy-conscious users to interact with the blockchain in a way that is both frictionless and cryptographically secure.