We are live! Follow us on Twitter @avvydomains to keep up with development.
The domain name system for the Avalanche
C-Chain, X-Chain, and more!
Claim yours now.
Have questions? Read about avvy.domains
Buy Domains
My Domains
Lookup
Questions?
Connected to Avalanche C-Chain ({{ this.network }})
Not connected - connect to Avalanche C-Chain to interact
MetaMask not detected - install MetaMask and connect to Avalanche C-Chain to interact
MetaMask not connected MetaMask not installed
Install MetaMask to use this application Connect to the Avalanche C-Chain to use this application.
Buy Domains
Type the domain you want to purchase in below to check if it is available.
{{ purchaseSubmissionError }}
{{ message }}

{{ purchaseDomain }} is available for purchase for {{ purchasePrice | fromWei('ether') }} AVAX

Gas estimate: {{ purchaseGasEstimate }}

You are buying a name in the avvy.domains name system, in the `avax` namespace. The `.avax` notation is a convenient way to reference the Avalanche ecosystem. avvy.domains is not affiliated with Ava Labs.

Oh no! Someone already owns {{ purchaseDomain }}

Congratulations! You now own {{ purchaseDomain }}!

Look up an address
Type the domain you want to look up
This address isn't owned, or no values were found.
X-Chain Address:
C-Chain Address:
Nickname
Avatar
My Domains
You don't have any domains
{{ domain.name }}.{{ domain.tld }}
Back to domain list
{{ domain.name }}.{{ domain.tld }}
This subname is not saved. To save it to the blockchain, set a value below.
X-Chain Address:
C-Chain Address:
Nickname
Avatar
What is avvy.domains?

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

How can I use avvy.domains?

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 (high priority).
  • 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.
What is the long-term vision for the project?
  • Community ownership.
    This project is designed to be released to the Avalanche community. The project developers have retained some control for now, to support development as we determine how the project will evolve. However, we have built in a mechanism to release the contract into the wild when the time is right. We hope to create an ownership coin that will allow owners to govern the project and to profit from the trading of domains.
  • 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.
What extensibility features have been built in?

In the future, we hope that all of these features will be governable by stakeholders in the project.

  • 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.
  • Routing the proceeds from the initial sale of domains.
    These proceeds will go to the project developers to start, to fund further development. We intend to have some sort of community distribution system in the future via a stakeholder token. Holders of the token would be able to vote on parameters like domain price, and would also receive proceeds from the sales based on their stake in the project.
  • Placing a commission on domain trades.
    We have no intention of placing commissions on the trade of domains. However, we have left this open as a possibility for the community to vote on in the future. Perhaps it will be permanently set to zero, or perhaps it will be left open as a governance parameter that stakeholders will have the ability to vote on.
  • 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.