More than half a year ago, a few friends from @ DataDanceChain and I researched whether it is possible to achieve a certain degree of anonymity without using zero knowledge proofs and relying solely on smart contracts, and whether it can be used in some real businesses? After multiple discussions, we jointly drafted the proposal standard ERC-7962 (Key Hash Based Tokens). In traditional ERC-20/ERC-721, asset ownership is directly written under the name of the "address", which is public and easily linked by transaction behavior and identity clues. ERC-7962 aims to weaken the most prominent "address tag" without changing the basic rules of Ethereum. It replaces' who owns the token 'from address to keyHash: a 32 byte' fingerprint 'obtained by hashing a public key. What we see on the chain is fingerprints circulating, not a specific wallet address being held. When you want to transfer or destroy assets, you provide a "public key+structured signature (EIP-712)" to prove that you do indeed have the private key, and the contract will be executed once it is verified and signed. The person initiating the transaction and paying the gas can be any address (such as a proxy/relay), thus completely separating "authorization" and "payment/execution". In the homogeneous token version (KeyHash20), the transfer also introduces a mechanism of "change to new fingerprint (leftKeyHash)", encouraging the replacement of keys after each use and reducing the associativity caused by long-term reuse of the same identifier. Therefore, it is suitable for scenarios that require "signature only, no need for ETH first", require gas payment on behalf of others, and require batch distribution/transfer, such as anonymous membership certificates/ticket NFTs, private collection gifting, and platform payment for new users to distribute rewards. But it is not considered 'strong privacy': the amount and flow path are still public, and the public key will appear in the transaction data during transfer, so it is more like 'bringing the address from the front to the back', rather than making the transaction relationship completely invisible. We look forward to receiving more feedback and suggestions from the community on this direction, and working together to refine it into a more usable, secure, and easily integrated standard.