Technology

Core

The core of Butterfly Protocol consists of a set of contracts living on Ethereum. Governance Tokens (BFLY) are burned by the Governance contract to sponsor a TLD and issue a new Registry Token (ERC 721) through the Registry contract.

Governance

The Governance Contract is responsible for controlling the sponsoring (creating) TLDs. There are currently two types of sponsorship, Community and Fully Owned.

Community TLDs

Community TLDs have a lower sponsorship costs but are more limited. When a Community TLD is sponsored a batch of ERC20 tokens are created which are used to register domains under that TLD. The ERC20 tokens are split between the sponsor and BFLY holders with the rest auctioned off. The process is described in more detail in the original whitepaper.

Fully Owned TLDs

Fully Owned TLDs have a fixed cost of 100k BFLY, which are burned, and give the ultimate in flexibility. Because the issuance of BFLY was fixed at 100M that means only 1000 Fully Owned TLDs can be created. These TLDs are able to delegate domain control to Zone contracts that can live on any supported chain.

Governance Token

The Governance Token (BFLY) is an ERC20 Token and is used mainly to sponsor TLDs but can also be used to register domains under community TLDs.

Registry

The Registry Contract is used set and read a domains attributes. It provides a flexible system that can expand without updating the contract. Currently two attribute types can be set, a domain can either point to content on IPFS using a CID or delegate control to a separate Zone.

Registry Token

The Registry Token is an ERC721 Token and controls ownership of a domain. Holding the Registry Token allows you to set attributes in the Registry and register subdomains under your domain. Registering a subdomain creates a new Registry Token which gives the holder control of that subdomain. Each domain and subdomain can be independently controlled based on who holds the Registry Token for that domain/subdomain.

Zones

Zones manage subsets of domains and can live on different chains. On EVM compatible chains they are standard ERC721 contracts. The only requirements are that the token id matches the namehash for a domain and that it can return an owner. This makes it very flexible and allows us to create zone contracts for non-EVM chains as well.

Directory

(in progress)

Each chain supported by Butterfly Protocol has one Directory contract. The directory is used to set and read domain records on a specific chain. Permissions are controlled by the zones and attributes are set using a combination of zone and domain. The directory also allows a person to set a domain as the primary domain for their address to enable reverse lookup (turning an address into a domain).

Resolution

Resolving a domain is a pretty simple process even across chains. The first step is generating the namehash for the domain which is a standard and supported by several libraries. Using the namehash getAttr is called on the Registry contract which will either return the IPFS CID or which zone controls that domain. If a zone is returned the resolver sends the namehash and zone information to the directory for the chain where that zone lives to get the information.

Most of this process is handled by indexers instead of directory contracts currently but is being updated to scale more efficiently and to support non-EVM chains.