Web3 domains are digital identities that can be used on web3 platforms. These domains can be used as usernames when logging into dapps that accept them as credentials, and can also be attached to additional data such as website URLs or social media handles. Flare Domains allow users to easily send tokens and NFTs to one another and can potentially be used as a digital identity credential to access web3 dapps and services in the future.

The Flare community will soon have the opportunity to use these web3 domains, thanks to a partnership between Songbird Domains, Cyber Identity, and The Satraps team. The .flr domains will be introduced to the Flare community shortly after Flare Network goes live and will have various utilities, such as the ability to be voted on for use as a digital identity credential.

One of the key benefits of Flare Domains is their ability to facilitate the exchange of tokens and NFTs within the Flare community. With a Flare Domain, you can easily send and receive these digital assets using only a domain name instead of a full blockchain address. For example, you could go into your Flare Domains page and send $FLR to Cyberidentity.flr without even having to know their address. Web3 domains are a critical piece of infrastructure to bring mass adoption to decentralized technologies by providing a simple and user-friendly way for people to engage with the web3 ecosystem and participate in decentralized communities.

Web3 domains offer a more intuitive and familiar way for people to engage with decentralized applications (dapps), making it easier for them to participate in this new and rapidly growing space.

In the future, certain Flare Domain holders will be able to use their domain as a digital identity credential to access web3 dapps and services. This will be made possible through a partnership between Songbird Domains, Cyber Identity, and The Satraps team, who will be bringing additional domains with various utilities to the Flare community. These domains will be introduced and may be voted on for use as a digital identity credential through Satraps governance.

With Flare Domains as an identity infrastructure deployed on the Flare Network, we will be able to bring a host of new utilities to the Flare Community. Aside from identity verification through our partnership with Cyber Identity, Flare Domain owners can immediately enjoy voting power at the Satraps Court. Because we are partnered with the Satraps, the .flr domains will be the first tokens on the Flare Network that will be able to vote in web3 ethics.

The Satraps Court is a decentralized governance system that is designed to bring ethics and accountability to web3 ecosystems. One of the main responsibilities of the Satraps is to ensure that the web3 ecosystem operates in an ethical and transparent manner. They do this by reviewing proposals and voting on a range of issues, including codes of ethics, the evaluation of new ecosystem features, and the resolution of disputes. In addition, the Satraps are also responsible for educating and raising awareness about ethical issues within the web3 ecosystem. This can include topics such as privacy, security, and the responsible use of decentralized technologies.

The Flare Domain owners will be able to delegate their votes to other .flr names, in the same way that Satrap IDs work on the Songbird Network. Once the Satraps Court dapp is deployed, both Flare Domains and Satrap ID holders will be able to interact with each other and bring ecosystem issues, proposals, and analyses to the voting floor. #GroundUpGovernance

Punk Domains protocol was built with modularity in mind, which makes it very flexible and allows for different parts of the module to be owned by different owners (for example, TLDs or even factories can be owned by a different owners).

TLD factories

We’ll start with the main component of the Punk Domains architecture: a TLD factory.

A TLD factory is a smart contract through which you can create new top-level domains (or TLDs, such as .web3, .ape, op, .etc). Each TLD is a separate smart contract, which is only possible because factory contracts have this “magical” ability to create new contracts on-chain.

TLD contracts do not need to be created and deployed manually by any person. A new TLD contract is created dynamically on-chain, when the appropriate method in the factory contract is called (createTld method or ownerCreateTld method).

Why are there multiple factories?

Each factory holds a template for a TLD that can be created through it. These TLD templates must follow the same basic structure (the same set of base methods), but can implement some methods differently or even have some special additional methods.

For example, one TLD template can limit TLDs to the same metadata image background, while another template (from a different factory) can allow for custom domain images. Factories and templates could also differ on which business model they allow (renewable vs. one-time purchase) and in many other ways.

How many different types of TLD factories there are?

Currently we have two factories (Standard and Flexi), but we expect many more in the future. There’s no limit on how many factories can be used in the Punk Domains protocol.

Even though existing factories right now are owned by the Punk Domains governance, they can be owned by different entities in the future. The protocol allows that and it works perfectly fine.

The Forbidden TLDs contract

Because there are multiple factories that can produce new top-level domains, it’s important that they avoid collisions.

In order to coordinate, there’s a contract called PunkForbiddenTlds which holds a list of already created top-level domains. Factories, of course, are not allowed to create new TLDs with the same name (hence, the “forbidden TLDs list”).

The Forbidden TLDs list does not include only TLDs from the Punk Domains ecosystem, but also TLDs created by other protocols such as .eth by ENS, and TLDs owned by Unstoppable Domains.

The Resolver contract

Resolving a domain means querying an address (and other data) associated with this domain. There’s also a reverse process (called reverse-resolver) where you try to find domain(s) associated with an address.

Each TLD contract has a resolver and a reverse-resolver implemented by default, as methods in the TLD contract itself.

But because there are so many TLD contracts, it’s also good to have a single smart contract that can resolve all TLDs on the given chain. This contract is called PunkResolver, and is not crucial for the system to work, but it is a nice shortcut.

Instead of having to find and/or store all TLD contract addresses, you just need to know one contract address (the resolver’s address) and always resolve domains through that contract.