# Names and Hashing ### Names and Hierarchies {% hint style="info" %} #### ZNS Name Rules 1. No majuscule letters (i.e., lowercase-only) 2. Alphanumeric 3. Allows hyphen ("-") but no other symbols {% endhint %} ZNS denominates domain name hierarchies in a left-to-right, top-down fashion, e.g., for the domain `0://hello.goodbye`, `hello` is the top-level domain and `goodbye` is a subdomain of that domain. While this model of organization universally comprises analog and digital filing systems around the world, it differs from traditional domain naming. In traditional Web2 and Web3 domain name services, the domain `hello.goodbye.com` comprises three levels: the leftmost item, `hello`, third-level domain and a subdomain of the second-level domain in the structure, `goodbye`. The rightmost element in the name is the top-level domain, `.com`*.* ZNS has chosen to break with DNS tradition and utilize left-right, top-down hierarchies for several reasons: * Left-right, top-down is the standard organizational paradigm for the world’s digital file systems (Windows, Linux, Mac, etc.) and analog indexing systems (Dewey Decimal or Universal Decimal Classification, Harvard-Yenching Classification, etc.). * Left-right, top-down follows the word order and directional reading practiced by the majority of the world and world’s languages. * Finally, Left-right, top down accommodates infinite extensibility of ZNS domains (a subdomain of a subdomain of a subdomain of a subdomain…) in a manner that is intuitively parseable by humans. This feature is glaringly absent from current Web2/Web3 domain nomenclature. As a result of this, ZNS can accommodate broader routing and indexing functions than traditional DNS systems, making ZNS far more versatile than existing Web3 domain options today. ### Name Hashing and Token IDs ZNS smart contracts do not work with string representation of domains beyond the initial hashing. Every domain in the protocol is represented by its namehash. Namehash is an algorithm of recursive string hashing where a label of the top-level domain is hashed, then appended to the hash of the child label and hashed again, repeating the process for every level of the full domain string. We use similar normalization and hashing process to ENS, but with the opposite hashing direction: To communicate with ZNS smart contracts, a domain's hash is needed. This can be acquired through the ZERO Explorer application, or through ZNS Subgraphs. As every domain in ZNS is represented with a hash, any given domain's hash is used in ZNS to create `tokenId` for each individual Domain Token NFT created during registration process.\ Token ID is represented as a unsigned integer version of the domain hash: `tokenId = uint256(domainHash)`. This means that any hex converter can be used to parse a domain's hash knowing only its Token ID, and vice versa. --- # 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://zer0-1.gitbook.io/zns/names-and-hashing.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.