Valuing the Handshake Naming System (HNS)

What is DNS

Before we talk about the Handshake Naming System (HNS), which is a novel attempt to decentralize the Domain Naming System (DNS), a quick overview of what DNS itself looks like will be extremely useful. If you are already familiar with DNS, including the ICANN root zone, you can click here to skip directly to the Handshake stuff.  To get a good functional understanding of DNS, let’s start with the anatomy of a domain name, using "mail.google.com" as an example:

• "com" is a Top Level Domain (TLD) and is run by Verisign inc., who has been granted that extremely lucrative opportunity by a complicated bureaucracy called ICANN (more on them in a moment) for a period of 10 years, with the contractual right to renew as long as they don't screw up in some big way. This brings in around a billion dollars of revenue annually; Verisign has a market cap of over 20 billion dollars.

• Verisign (aided by registrars like Namecheap, GoDaddy etc, who act as brokers) allows anyone who pays a standard fee to rent a second level domain (SLD) below com, like the "google" part of our mail.google.com example. I use the word "rent" here because there is no way to have true ownership over an SLD; instead you get what is effectively a renewable tenancy over it, governed by the terms of a standardized contract with the TLD manager. You are not free to do whatever you like with "your" domain; like a rented apartment, there are restrictions, and you can be evicted or have the terms of your lease modified at times. 

• Finally, the mail part of our mail.google.com example domain is what’s known as a subdomain. Subdomains are managed by the entity currently controlling the SLD (in this case, Google) and are often used for organizational purposes like separating out different functions of a website. Subdomains are occasionally also granted to third parties; for example tumblr gives out subdomains to users (e.g. myusername.tumblr.com) on a first-come first-serve basis, but the problems inherent to SLDs are even worse for subdomains — your use of the subdomain is 100% at the mercy of the SLD manager ,and most TOS's allow them to be revoked for any reason at all and with no warning; this played out for Tumblr users when the sites over-active porn filter caused blogs to disappear for something as innocuous as an oil painting with a nipple in it. 

Thus at the top of the Domain Name System (DNS) are TLDs like "com," "org," or "net." These are run by companies like Verisign, who profit by renting and renewing SLDs like google.com or wikipedia.org, in the process making billions of dollars per year. Which entity controls what SLDs is recorded on the nameservers run by the registries (e.g. Verisign, et al), which leads to an interesting question: if Verisign is in charge of maintaining the list of who owns what .com domains, where is the ownership info for who owns .com itself (and the other TLDs) recorded? 

That information is recorded in a file called the root zone, ultimately under ICANN's authority, which contains entries for each TLD (like com, org, net, etc) that tell people whose servers to go talk to if you want to resolve a com domain, org domain, net domain, or whatever else. By controlling the apex of the namespace ICANN has a huge amount of power, and like all powerful bureaucracies they have over the years abused and mishandled this power in many ways, which we'll go over later in this document; for now it suffices to know that in the status quo the entire DNS system is controlled at the top by a single entity.

What is Handshake?

Handshake is a way to fairly assign and record the ownership of top-level domains (the domains at the end of a url, like ".com"), without giving any centralized party control over the assignment process, or the ability to alter records of ownership without the owners consent.

Specifically, Handshake is a blockchain based root zone for new TLDs, designed to be able to coexist peacefully alongside the existing root zone which serves TLDs like com, and org, or even eventually absorb it entirely. If this sentence didn't make sense to you, just keep reading. 

So as we said in the beginning, Handshake is a blockchain based root zone—and the root zone is the ledger where ownership over top-level domains are recorded. Thus, by interacting with the Handshake blockchain, users are able to register and operate their own top level domains (like for example, .2d, or .nb, .coin, .smith etc). 

Importantly, handshake is not a new TLD registry like e.g. Namecoin's ".bit" or ENS's “.eth.” Handshake exists one level above those solutions,  and opens up a new continent of "namespace" where users can launch their own TLDs. Moreover, by simply creating a new blockchain-based root zone but not trying to reinvent any wheels when it comes to other aspects of the DNS, Handshake remains compatible with the massive amount of DNS infrastructure already out there — for example, if someone registers a Handshake TLD like .jackson, they can use existing TLD management tools (EPP, various suites like Google's nomulus, etc) to sell SLDs like alice.jackson or bob.jackson.

What are the advantages of Handshake?

Handshake names do all of the things normal DNS names do, but instead of renting them from corporations like Verisign, who themselves operate at the pleasure of ICANN, you can own them yourself and no one can modify or confiscate them without your consent. Saying that Handshake is to ICANN domains as Bitcoin is to fiat money wouldn't be far off,  as these benefits should sound fairly familiar to anyone who's spent time thinking about Bitcoin. However there are important benefits that Handshake has that are unique to the naming use-case:

The Handshake root zone is a canonical but decentralized root of truth

 Zooko came up with a well-known trilemma for decentralized (he calls it "distributed" in the document, but same meaning for our purposes) naming, saying that names could be secure, distributed, or human-readable, choose two. Notably Zooko also said "I didn't prove that it is impossible to have all three features, I only said that I doubted that your namespace will have all three, if you think your namespace design can provide all three, then lay out an argument that it can do so." The core of this dilemma is the difficulty of having a "root of truth" without relying on centralized parties — once you have even one source that everyone trusts you can bootstrap everything else on top of that foundation. That is, as long as we all agree to trust Alice, we can always just ask Alice whether Bob, Carol, or Dave are in fact who they claim to be. This is basically how things work in DNS —with ICANN as Alice.  Nakamoto Consensus, the consensus algorithm pioneered by Bitcoin and adopted by Handshake, provides a simple way for anyone to verify that a specific ledger is the "one true ledger" without resorting to any centralized authorities like Alice or ICANN.  To deeply understand how this works, I cannot recommend strongly enough that you read Michael Nielsen's extremely in-depth but concisely explained "How the Bitcoin protocol actually works." However, it's very long so you may wish to come back to it — for now we will vastly oversimplify and just say that in Handshake, as in Bitcoin, whichever blockchain is the longest is the real ledger, and length of chain is an objective fact that any client can verify very easily. Excitingly, this lets us solve Zooko's Triangle cleanly: Handshake's blockchain is a decentralized source of truth, handshake names are human readable, and because each Handshake name has an associated set of cryptographic keys, Handshake names are secure. 

Having this root of trust solves one of the biggest problems in security: trusted CAs. 

Without getting too deep into technical details that are out of scope for this paper, the current security model of the internet requires that you trust a few hundred organizations known as Certificate Authorities to authenticate that when you think you're talking to "google.com" you actually are. This has in the past failed spectacularly several times. Handshake lays the foundation to do away with CAs entirely, using the Handshake blockchain as the root of trust, and each Handshake name as its own self-authenticating certificate.  

Handshake names are assigned in a fair auction-based method that can be participated in by anyone in the world.

Perhaps the biggest difference between Handshake and Bitcoin at the protocol/consensus level is that Handshake includes an on-chain auction system for assigning names in a fair way. Anyone in the world can anonymously bid on a name they want, and after a set period of time, the highest bidder gets the name. I wrote a very in-depth guide to this process here, since a deep understanding of it is obviously useful to anyone who intends to invest in Handshake names — I'll briefly summarize  three key points here in the interest of brevity. 

1. Not all names are openable for auction. Importantly, all of the TLDs that already exist in the ICANN root zone (eg: com, org, io, etc) are reserved and cryptographically claimable by the owners of those names, the top 100,000 most visited websites as determined by Alexa are also reserved (so e.g. the owner of Bitcoin.com gets the name "bitcoin" on Handshake, and Google gets "google").

2. The remaining names, which can be bid on are openable for auction only after a random delay, from 0 to 52 weeks.  After 52 weeks, any biddable name can have an auction opened. This is to ensure that there is a slow rollout, and no one comes and buys up all the "best names" on day one. The week when a name is released can be found by taking the SHA3 hash of the name, modulo 52. You can do that manually of course, or if you just search for the name you want on Namebase's domain search it will show you when it's available — to search for up to 1000 names at once, hit the “power search” button on that page. 

3. Once a name is openable, anyone can initiate an on-chain auction for that name. The auction will start around 6 hours after it was initiated. After the auction is active, users have 5 days to use their HNS coins to bid, and can optionally also use their HNS coins to add a "blind" — other users can only see the combination of bid + blind (know as a "lockup") but only the bid actually "counts" towards who wins the auction—the blind will be returned at the end of the auction whether the bidder wins or loses.  After the 5 day bidding period is over, there is a 10 day period during which users can reveal their lockups, showing how much they bid, and how much was just a blind. Once the 10 day reveal period is over, the highest bidder burns HNS equivalent to the second highest bidder's price, and is awarded the name. All of the other bidders who have lost are now able to reclaim their coins and go bid on other names. 

Again anyone who is interested in this is strongly encouraged to read this article which goes into much more depth, and provides a lot of concrete examples as well as discussing what happens in edge cases like a tie.

Handshake names truly belong to the key holder, and are hard to censor or seize

In the ICANN-dominated status quo, domain names can be seized for a surprising variety of reasons, by a surprising number of global governments both large and small, despotic and democratic alike. This happens more often than one would think. What is legal in one country might not be legal somewhere else, and since different TLDs are under different jurisdictions, what will be a safe use of "your" domain is sometimes hard to figure out. Handshake names are owned by whoever has the private key corresponding to that name, and (like Bitcoin) cannot be seized or altered by any other party. For people who don't care about this property of Handshake, it's easy to delegate key management to someone else, trading in the T34 tank of self-managed keys in cold storage for a more convenient Honda Civic. For someone who is worried that someone might try and take their name away, Handshake's cryptographic guarantees are equal to Bitcoin's. 

Understanding the value of Handshake names 

Naturally scarce digital items are extraordinarily rare

Objects in the physical world are naturally scarce  —  but nearly all digital objects are naturally abundant, and are made scarce only by artificial constraints  —  empirically a very tricky thing to pull off. If we see a beautiful jade figurine in a market, making a second one identical to the first is no small matter  —  maybe someone skilled in the art could create a decent copy, but it would require significant work, materials, time, and in the end still might not fool the most careful examiner.

This difficulty comes from the infinite complexity of the "real world" as compared to the simplified reality of the digital. Our jade figurine in the real world has literally millions of billions of atoms that determine its nature; a jade figurine item in a game is usually fully determined by a few thousand lines of code. To apprehend it in-game is to have absolutely everything we need to copy it and make a second figurine, or a million more. This truth about digital assets, that the marginal cost to replicate them tends to be near zero, led to the hollowing out of huge content industries previously protected by the relatively "easy" scarcity of the physical.

Bitcoin, interestingly, is also not "naturally" scarce  —  the reason that there will never be more than 21 million Bitcoins has nothing to do with a physical inability to produce more  —  rather, it's the product of an artificial scarcity consensus that has proven itself extraordinarily robust in the face of all manner of attacks over the past 10 years. Bitcoin is remarkable not for creating a naturally scarce digital asset, but for creating such robust scarcity artificially.

Namespace, on the other hand, is a nearly unique example of a naturally scarce asset. The number of actively used words in a language is limited. On the one hand the supply of valuable namespace is inflated by new words ("blockchain" in 2008, e.g.) being coined, and on the other hand it's constantly being deflated by old words (overmorrow used to be a common word for "the day after tomorrow") shifting into disuse.

Unsurprisingly, in light of this natural scarcity, the domain name system is astronomically valuable, probably in the hundreds of billions of dollars. What number you settle depends on exactly how you calculate: all of the second-level-domains in aggregate (google.com, namebase.io, all the way down to askdjalqwe.capital etc) can be thought of as "stock", but the TLDs (like com, org, io, etc) themselves are probably better valued as a function of their flows; that is, the SLDs one can profit from the registration and renewal of if one owns a TLD. The market's valuation of e.g. the flows from "com" can be approximated by Verisign's marketcap, which hovers around 20B; an offer for 1 billion to purchase the .org registry was widely derided as an underpriced insider sweetheart deal, so one gets the idea that the aggregate value of the TLDs can be quite high.

The implications for Handshake are interesting — all Handshake names are TLDs that are capable of selling SLDs, so the value of a Handshake name should be assessed as the value of the TLD itself. You can see this play out in bidding — the names which seem like they'd be especially useful as SLD-suffixes tend to go for a lot (for example, .coin, .crypto, etc.)

Specifically what (type of) names are going to be valuable?

The answer to this question depends on how people end up using names. Here are a few use patterns I've been thinking of:

Bare names as TLDs/web addresses (TLDs as URLS)

People may use Handshake names as bare TLDs. At first it feels kind of weird to type a word in the URL bar and not have a "dot" something suffix, but you get used to it, and I could see this catching on especially for single-purpose sites where it makes them feel almost like UNIX commands. For example amipwnd/ is a site for checking whether your commonly used passwords are in any leaks, downforeveryoneorjustme/ (or its lithe cousin dfeojm/) check whether a site is actually down or something’s just wrong with your internet, and whatsmyip/, well, I’ll let you figure that one out.

Interestingly this not only is theoretically supported by the DNS specs, but is currently being used. The manager of the .ai TLD, a venerable cypherpunk named Vincent Aron Cate, who also happens to be one of the founders of the well known Financial Cryptography conference series, has a website hosted on the ai TLD itself! Apparently it doesn't work in 100% of browsers, but for most people, if you just copy-paste "http://ai/" into your browser, you can see a very awesome 90s style page for the ai registry. That this basically works "out of the box" is good news for HNS name compatibility.

Bare names as crypto addresses

Another reason that people may value names that work well as single words is that they make cool crypto addresses. There's a simple trick to allow wallets to use HNS names as addresses for literally any cryptocurrency (just add a TXT record with the relevant addresses in some standard format the wallet providers agree to — if you read the previous section, getting this done is definitely one of the most important "bridges" we can build early on).

So instead of having to do that stressful thing where Satoshi tells Alice his address is 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, and Alice sends him 0.000001 BTC as a test, but she misheard the G as a J and has to start over, Satoshi can just tell Alice "send to satoshi please" and when Alice enters "satoshi" in her wallet, it does a quick DNS lookup to check Satoshi's BTC address and then sends the coin. Having your own name, or some other cool word as your crypto address is likely to become a thing, like vanity plates, HK millionaires paying for phone numbers with lots of 8s in them, etc etc. I think it's silly, but I also really, really want to get my name as my address, so there it is.

Names that are well suited for issuing SLDs

Other names that may be valuable are those which work well for issuing SLDs. For example, common last names (joe.smith, alice.yang etc) or suffixes which are good for domain hacks like how del.icio.us worked back in the day, or things like ".coin" for SLDs like bit.coin, privacy.coin etc.

Besides scarcity, infrastructure adoption drives value

The easily understood scarcity of digital namespace is what brought the initial set of investors to Handshake; what will increase the value of Handshake names and the HNS token (more on the token in a moment) is increased real usage of the Handshake DNS itself.

The analogy of domain names to offline real estate is a decent one; both have a natural scarcity, are more or less valuable depending on the neighbors, and in the case of TLDs, can be income-producing assets. However since traditional DNS providers, browsers, VPNs, web hosts etc don't support Handshake by default, the HNS root zone is like an undeveloped island surrounded by ocean on all sides. However unlike the nearby mainland where houses are built on swampland, houses on HNS island have 100 feet of beautiful bedrock underneath them! Still, at the outset of the project, the only way to get to the island was by rowing a boat there yourself.

Surprisingly, only 4 weeks after launch a major DNS provider (NextDNS, the only Mozilla trusted resolver other than Cloudflare) supported Handshake resolution, albeit only for users who selected to turn on that setting. A great deal of infrastructure has sprung up in the four weeks after that (we're currently on week 8 after launch, so still very early) including proxies, various VPNs supporting HNS, and people making their own DNS servers available to the public. These early solutions require a lot more user work than is ideal; people have to download something, or modify some settings, but with NextDNS on board and other providers currently discussing default support, the path to many users being able to simply type a Handshake URL into their browser and have it "just work" is clear.

Adoption by content creators drives infrastructure adoption

Getting more browsers and DNS providers to support HNS is important because it increases the number of users who can easily view Handshake sites. Getting that support is also pretty straightforward: browsers and DNS resolvers will support things that will prevent them from losing existing users, or help them gain new users. And what users want is access to interesting content.

So put simply, if Handshake can get 1000 truly useful and interesting websites being resolved to HNS names, it will cause a lot of infra providers to start paying real attention. If it can get 10,000, it will be in a way un-ignorable for many providers, and will have a really decent shot at long term adoption and inclusion into the complex fabric of technologies that make up what we experience as "the internet."

Understanding the value of the HNS token

The HNS token's value is tied directly to network usage.

There are two main mechanisms that link increased usage of the Handshake Naming System and an expected increase in the price of the HNS coin.

The first is the burn mechanism discussed at length in the auctions section: HNS coins are burned every time an auction with at least two bids concludes. This has resulted in about 1% of the circulating supply being burned in only two months. Comparing this to other tokens with burn mechanisms is pretty pointless given all of the differences in situation, mechanism, etc but however you look at it this is a remarkable level of activity from a network in its infancy: it took MKR/DAI over a year to have burned as much USD value as HNS has done in 8 weeks. 

While comparing value burned is in my opinion not especially useful, I do think it's interesting to compare the amount of risk involved in various token-driven networks. Handshake looks very good in this department—it has the same highly effective burn dynamics that traders love in exchange platform tokens like BNB or Bitfinex's LEO, but has none of the counterparty risk that the exchange will simply stop honoring the token burn policy, alter it unilaterally, go out of business, etc. It also isn't subject to anything analogous to the risk that MKR holders got a tough demonstration of recently—that a big price crash in ETH caused enough MKR to be printed that not only was all of the previously burned MKR restored, the system is actually currently inflated by a little under 6000 MKR or 2 million dollars. 

Unlike MKR, HNS which is burned stays burned permanently, and unlike BNB, LEO, etc. the rules for burning HNS are "set in stone" at the protocol level. This isn't to denigrate either MKR or the exchange platform tokens, which over the years have proven themselves to be lucrative investments, but it's worth pointing out that HNS offers a similar mechanism with substantially less inherent risk.

The second mechanism that links increased usage to value for the coin is the need to use HNS to renew names and also to alter or add DNS records to names you own. The more names are registered, the more demand there will be for HNS to renew and edit those name records; One can hedge the risk that HNS increases in price dramatically by holding enough HNS to send the bi-annual "heartbeat" transactions required to renew names, and the update transactions necessary to modify name records, further reducing the amount of HNS available on the market for new buyers.

HNS Token distribution

At the genesis block, there are 1.36 billion HNS coins with an additional 680k available to be mined, for a fully diluted supply of 2.04 billion. The first halving of the mining reward will occur after 3.25 years—after 5 years about 430k (60%) of the mineable coins will have been mined, and after around 100 years, the very last mineable HNS coin will be mined. Of the initial 1.36 billion coins, a full 952 million (70% of the initial supply, 47% of the fully diluted) is available to be claimed by:

1. Anyone who had more than 15 followers on Github, and also had valid SSH+PGP keys on their GitHub account, during the week of February 4th, 2019 (roughly 170,000 accounts)

2. People whose PGP keys are included in the strong set (roughly 30,000 keys)

3. Hacker News accounts older than 1.5 years old with linked Keybase accounts (about 19,000 accounts)

It's very much too early to rate the success of this distribution mechanism. My anecdotal experience is that of developers who received the airdrop, most of them immediately sold it, and a much smaller percentage became very interested in the project and joined discussion groups, started building things, etc. Investors interested in estimating the true supply of the coin should note that due to a long delay between the snapshot of Github accounts and the chain going live, many developers who would have been eligible have since lost access to the keys they would need to claim the airdrop. Only [get the actual number] a single digit percentage of the airdrops have been claimed, and the number of daily claims dropped off sharply after an initial spike; I think it's highly likely that only 10% of these coins are ever claimed, and the rest will eventually be considered "burned" as a result of lost keys.

Besides the programmatic airdrop, 7.5% of the initial supply was granted to the founding contributors and 7.5% was sold to investors in exchange for 10.2 million dollars. Notably, because the contributor list was extremely broad and generous with people who made tangential contributions early on, and because the initial investment event was a "party round", the 15% allocation to contributors and investors went out to 1356 distinct addresses, and no single entity controls more than 1.5% of the initial supply. Of the initial investors, Founder's Fund and Andreessen Horowitz had the biggest allocation at 1.5% each; the largest team member allocation is 1.4%, and the remaining allocations are mostly closer to 0.1%. Many token projects had poor market performance as a direct result of individuals owning 10-60% of the token supply, so Handshake's initial highly diffuse distribution is a nice derisking factor.

Aside from the investor and contributor allocations, significant allocations of tokens were given to a bunch of the pillars of the open source software community like the Apache foundation, LibreSSL, the EFF, the Mozilla Foundation, Arch Linux, etc. In addition to token grants, the $10.2 million raised from investors was also donated (in full!) almost immediately after it was raised, to the same set of foundations as cash grants.

Outlook

In conclusion, the use case for Handshake is extremely clear, and the early adoption metrics (coin burn, names registered, community adoption, hashrate) all seem extremely strong. I'll be updating this post as time goes on, in order to stay up to date on the investment case for Handshake names and HNS. Feedback always appreciated—I'm @wheatpond on twitter.