# Identity We will initially use EVM address and ENS names as usernames for users. As ENS is also used as an alias for wallet address, building on top of ENS also make supporting feature such as subscription and gifting simpler as we can simply look up the user’s wallet address from the ENS contract (note that wallet address is the same across different EVM chain). To onboard, a user must generate an ECDSA key pair, and add the public key to the [Registrar contract](https://github.com/autism-org/contracts). This new ECDSA key pair is derived by producing a SHA-256 hash of the result of calling `web3.eth.person.sign('Sign this message to generate a GUN key pair with key nonce: 0')`. The goal of using derived key achieve three purposes: * to allow users to *authenticate their social messages without risking their primary wallet keys*, as the risk profile of a wallet private key (access to fund) is much higher than one’s social identity * to allow users to *update a new key pair by incrementing the message nonce* in the case when their previous key is compromised * to allow users to *recover their social identity using their wallet* without having to remember another seed phrase. The Registrar contract consists of two major functions: * **`update(bytes pubkey)`**: update `pubkey` for the `msg.sender` * **`updateFor(address account, bytes pubkey, bytes proof)`**: update `pubkey` for `adress` as long as `proof` is valid using `ecrecover` Each update will emit a `RecordUpdate` event. Anyone can then watch for those events and index all users’ identities into whatever database they so choose. The reference implementation of the [indexer node](https://github.com/autism-org/indexer) uses postgres to store all users’ identities. **Support for Other Blockchain and Naming Systems** We believe that composability is one of the main source of innovation in crypto, and plan to include support any naming system based on demand in the future. We categorize these systems into two broad categories: * **Smart-Contract Platform**: systems such as BSC, DOT, and SOL that supports smart contract can be supported by deploying similar contract to their platform. * **DNS-based Naming System**: systems such as traditional domain name and decentralized naming system (i.e. [*bob.com*](http://bob.com/), *alice.crypto*) can be supported by requiring a `TXT` record update under the format `autism:`, of which the indexer can then watches for record updates from those domain. These should cover the majority of different identities solution exist today. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.zkitter.com/developers/identity.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.