We've received a lot of questions recently about the project, whether it's still alive, and whether we are still developing. We want to take this opportunity to assure you that we are indeed here and that we are moving forward.

Our soft-launch in April was a success. For those who missed it, we developed infrastructure for selling domain names and a key-value store for setting records on the C-Chain. We launched with four record types: C-Chain Address, X-Chain Address, Nickname, and Avatar. We created an NPM package and a basic Chrome extension for performing lookups. We had every intention of moving & building fast.

Shortly after, we stopped building. We realized that this project is critically important infrastructure. We reached out to the team at Ava Labs & have been collaborating with them since to ensure that our product will properly serve the Avalanche community. We know we have an important role to play and we want to make sure we do it right.

Our mission is to create a naming system that will integrate well with applications and subnets in the Avalanche ecosystem, while also providing utility outside of the Avalanche ecosystem. The goals of the project have not changed since the soft-launch in April, however our approach has shifted a little. We want to build a sustainable business that can carry out its mission and continue to serve the Avalanche community for years to come.

We've paused domain sales while we finalize our plans and continue discussions with Ava Labs. For those who have bought domains, you'll be able to continue using the application. No matter what happens, we want early supporters to know we are here for you & won't be forgetting you.

In the meantime, if you have any questions, feel free to send us a DM on Twitter @avvydomains or an email to [email protected]

avvy.domains is a naming system for the Avalanche blockchain. It's best explained by describing how you can use the project (see below).

Here are a few use cases for the project:

• Human-readable blockchain addresses.
  On the C-Chain, smart-contract and wallet addresses are long hexadecimal strings, like 0xC9e1aDcA290f5210f0148f06595BeCA35f32d776. By using a avvy.domains, we can use human readable names like avvy.avax to look up the contract addresses. We are also working to provide similar functionality for X-Chain addresses.
• Identity provision for dApps.
  Decentralized applications have access to a wallet address via MetaMask. Using avvy.domains, dApps can translate a wallet address into human readable name like dave.avax. This can be useful for dApps where users interact with each other. Users can also set their avatar and alias records, allowing dApps to retrieve a profile picture and a non-unique nickname to display for users in their dApp.
• Tradeable assets.
  Domain names claimed on avvy.domains can be traded to new owners. They are not ERC721 tokens, but we have implemented a mechanism to allow them to be traded on ERC721 exchanges in the future. We intend to create a domain marketplace where users may purchase & re-sell domains.
• Utility for smart contracts and dApp developers.
  Names purchased on avvy.domains are permanently owned, rather than leased. Owners can delegate access to modify domains & subdomains to others, allowing smart-contracts or other users to modify records on behalf of owners. We hope that dApps will be able to permanently live on, being referenced by their avvy domain name rather than their cryptic address.

• Integration.
  We hope that this project will be integrated in a large portion of the applications in the Avalanche ecosystem. We're looking forward to building developer tooling to simplify integration and we're excited to work closely with creators in the community.
• Extensibility.
  Mechanisms for extending the project have been put in place to allow the project to grow. We have built in functionality to allow us to change the things described in the extensibility section below.

• Determining which domains are for sale, and for what price.
  At the moment, only .avax is available for sale. We have built a simple contract to govern pricing, so we can modify that for the initial sale. However in the future, we look forward to expanding to new top level domains, and working with more complex permissioning systems for purchasing & pricing.
• Determining whether a domain can transfer from one owner to another.
  At the moment, the owner of the domain is the only one who can initiate a transfer. We've left this open to change to allow for more complex scenarios in the future. For example, in the future the owner of a domain might be able to mint an ERC721 token representing the domain. That ERC721 could be traded on NFT exchanges, and then the buyer of the ERC721 could have the authority to initiate a transfer to become the new owner of the domain. Unfortunately, this is not a trustless scenario. As the keyholder, the project developers could re-claim all of the domains from their owners. This would tank our reputation and the project, and also probably be criminal, so those are loose guarantees that we would not undertake such an action. However we understand the severity of this trust. We hope to remedy this situation as soon as possible.
• Validation mechanisms for value types.
  One of the fun things about this project is that we intend to have multiple types of records. At the moment, we have 3 record types: C-Chain Address, alias, and avatar. At the moment, there are no validations for these records. However, we would like to enable validations so that we can have guarantees on the data that will be placed into the fields (guaranteeing C-Chain Address is a valid address, alias is alphanumeric, and avatar is a web link). This will provide some guarantees for downstream users of the project. In the future, we intend to introduce other types of values as well, so the continuation of this branch would need to support new record types (again, likely as governable parameters).
• Hooks when values get set.
  This may simple get removed / cancelled as an extensibility feature, however we wanted to include it *just in case* there is some reason why consumers of the contract would want to perform some action when the domain gets updated. For example, let's say a downstream smart-contract makes use of web.avax. Perhaps they allow users to set username.web.avax, and when that value is set the downstream contract wants to execute an action. We're still exploring this one.