Launched on November 29, 2015 by Alexandre Naverniouk, Ether ID was an early attempt at a name registration system for Ethereum. The system enables registrants to attach domain names to addresses. In addition, they can attach websites to their domains.
Though it did not achieve widespread use like Ethereum Name Service (ENS) did, Ether ID is of historical interest, and the domains registered in the early days could be considered collectibles. Ownership of all domains has previously expired (2,000,000 is the max number of blocks before renewal is required). However, upon expiration, the domain and its websites remain intact. The only thing that changes is that anyone can claim ownership of them.
Contract Upgrade
On June 19, 2016, after around 30,000 domains had been registered, the unchecked-send bug was discovered in the Ether ID contract. This is a bug that prevents the built-in marketplace from operating properly. These types of problems are solvable with wrapper contracts nowadays, but at the time, Alexandre decided to copy the existing domains to a new contract. (Note that any websites associated with domains were not copied over.) This happened on June 29, 2016.
We’ll refer to the original contract as V1, and the updated contract as V2. In the 2015-16 period, a total of 32,591 domains were registered using the V1 contract. Since the domains are lacking utility and are of mostly historical interest, and since both versions can (most likely) be traded via a wrapper, I prefer domains from the older V1 contract. (Full disclosure, I own many domains in the V1, and none in the V2.) I will focus on V1 exclusively for the remainder of the article.
Wrapper Contract
I created a wrapper contract to facilitate trading of the domains registered in 2015-16 through the V1 contract. Some domains have already been wrapped and can be viewed on OpenSea.
Instructions for using the wrapper contract are as follows.
Wrapping
Let’s call your address A and the domain contained within it d. Further, we’ll call the address of the wrapper contract W. Finally, a Merkle proof M will be needed to prove that your domain is one of the original 32,591. (The proofs are included in this spreadsheet.)
Step 1: In the original contract, call changeDomain(d, 2000000, 0, W) to offer the domain to the wrapper contract.
Step 2: In the wrapper contract, call wrap(d, M) to transfer the domain over and receive a corresponding token.
Unwrapping
Suppose you hold token t in address A, and you want to unwrap to a domain. Further, let N represent the null address.
Step 1: In the wrapper contract, call unwrap(t) to have the contract offer the domain to you and burn the corresponding token.
Step 2: In the original contract, call changeDomain(t, 2000000, 0, N) to take possession of the domain.
Renewing
Since all domains are set to expire after a maximum of 2,000,000 blocks, they need to be renewed periodically. Using the wrapper contract, you can renew the domain associated with a token t by calling renew(t). Renewal using the wrapper contract must be done prior to expiration.
I should also note that there are no restrictions on which addresses can renew which tokens. It is not required that you be the owner. This design decision was a simple way to leave the door open for incorporating bulk renewal contracts at a later date.
Degenerate Tokens
When the domain associated with a token expires, the token enters what I call a degenerate state. At this point, the domain can be claimed by anyone and modified in various ways. The token remains, but the link to the underlying domain is broken.
The wrapper contract contains mechanisms for dealing with tokens that become degenerate. It labels a token as degenerate if (1) the associate domain is not owned by the wrapper contract, (2) the domain is expired, (3) the domain is listed for sale in the original contract, or (4) the domain is set for transfer in the original contract.
A degenerate token cannot be transferred, renewed, or unwrapped via the wrapper contract. You won’t be able to tell whether a token is degenerate just by viewing its listing on OpenSea. However, the wrapper contract provides a function called isDegenerate(t). For nondegenerate tokens, there is also a function called blocksUntilExpiration(t) for seeing how close the token is to becoming degenerate.
Some Words of Warning
This project requires more words of warning than usual due to the many potential pitfalls.
First off, the V1 Ether ID contract is not verified on Etherscan. While we can be fairly certain that this source code compiles to it, nothing is guaranteed. And, even if the source code can be verified, it can still have issues.
Further, note that domains are stored in the original contract as integers. It’s possible for the corresponding string to contain unprintable characters. Be aware of this when browsing the collection on a site like OpenSea.
As mentioned earlier, designing a wrapper contract for items that expire presents new challenges, and there certainly could be flaws in the wrapper code. Since domains are automatically renewed when wrapped, it won’t even be possible to test the expiration-related aspects of the contract for about 9 months.
In short, this is all very experimental, and there are many things that could go wrong. I am providing you with information and code, but you are responsible for your own actions. If you do not have advanced knowledge of smart contract programming and computer science in general, stay away! I take no responsibility for any money lost as a result of interacting with any of the contracts I mentioned here. Proceed at your own risk!