โFAQ
What does it mean to assign a domain?
In simple terms it means "let someone else use it for the time being". While you are holding your ownership of the domain entity, you can assign only the token to another account that would be able to use your domain in other applications (that use token ownership) until you assign it to another wallet.
Why is Canonical Owner allowed to override token ownership with Token Assignments?
Domain Token is just one part of the domain entity in ZNS. Besides that domain data is scattered around ZNS based on it's usage and necessary availability. There is a million ways to use a domain created in ZNS, so the protocol needs to cover multiple use-cases with relative ease. Since we use address binding for ownership, access control and other things, we wanted to make domain management more configurable and less limiting. People use combinations of hot and cold wallets, Safe Accounts, smart contracts and other thing for their asset management, 3rd party apps need better ways of connecting and managing domains, communities need easy access to domain management and so on.
For this reason there is a Canonical Owner, which is the owner of the domain name/record/hash in ZNSRegistry
and this data is used across the protocol to grant rights, discovery and ownership. Token should be viewed just as token - a utility tool that helps transfer domains easily, trade domains, get access to token gated chats, etc. Having the ability to assign a token to any of your wallets, like a hot wallet which you use often while you have your Canonical Owner being a Safe Account, for example, or give it to your friend to use inside a community or create multiple controlled subdomains for your company's employees and being able to revoke them as employees leave are all possible use-cases for this feature.
However, remember that properly transferring your domain token (not "assigning" through ZNSRootRegistrar
contract WILL transfer your canonical ownership along with the token).
What is an operator?
Operators are specific addresses that have been granted permission to modify a domain on its owner's behalf. This is done by adding addresses to the operator list for your account address in the ZNSRegistry
contract. Domain owners can grant an operator access to their domains' records at any point in time. This is typically done to allow third-party applications or other users the ability to manage a domain for an owner without requiring that owner forfeit their domain's NFT.
It's important to note that operators are assigned at an owner level, not a domain level. This means that if the domain is transferred to a new owner, both the old owner and their operators will lose access to it.
Many functions within ZNS use the onlyOwnerOrOperator
guard to restrict who is able to call that function.
What does it mean to revoke a domain?
Domain revocation entails forfeiting ownership of that domain and burning the associated NFT, rendering the domain available again for anyone to register. Domains and subdomains that were registered via ZERO's stake-to-mint paradigm will be refunded their stake amount (but not associated fees and gas costs) in full. Subdomains that were purchased via direct, one-time payments will not have that payment refunded if revoked.
Revocation of a parent domain with existing child subdomains will not impact those subdomains; once minted, subdomains are entirely emancipated from their parent domain. It will not be possible to mint new child subdomains under a revoked domain, however, until the parent domain is re-minted.
What is a domain hash?
A domain hash is a cryptographic hash function of that domain's full name. For example, the wilder.world
domain has a name of wilder.world
, but the label is specifically just world
.
For top level domains, or Worlds, there is no parent domain and so the domain hash is calculated as jus the hash of the label:
bytes32 domainHash = keccak256(bytes(name));
For subdomains, the parent domain hash exists and so the domain hash is instead calculated as:
bytes32 domainHash = keccak256(abi.encodePacked(parentHash,keccak256(bytes(label))));
What is a distribution configuration?
Distribution configurations specify three things:
The type of payment this domain accepts (STAKE vs. DIRECT)
The accessibility of this domain to have subdomains minted (LOCKED, OPEN, or MINTLIST)
The
ZNSPricer
contract to use for this domainThe price config that is used to determine subdomain prices encoded as bytes
This configuration is given to the domain upon registration through either registerRootDomain
or registerSubdomain
Read more in Subdomain Distributionand Base Distribution Configuration.
What is a payment configuration?
Payment configurations specify what ERC-20 token a domain accepts as payment for subdomains. It also specifies the recipient direct payments or stakes fees for subdomain registrations under that domain.
This configuration is given to the domain on registration through via registerRootDomain
, registerSubdomain
, or through using the setPaymentConfig
call.
Read more in Base Distribution Configurationand Payments.
What is a price configuration?
Price configurations specify the necessary variables required by the ZNSPricer
contract used by ZNS's registrar. Custom contracts can be used in this configuration; if this contract is one of the two pricing contracts ZERO has created, then the configuration specifies either a single price for each domain regardless of that domain label's length for FixedPricer
. If the CurvedPricer
contract is used, the base length, maximum length, curve multiplier, and maximum price of a domain are part of the config. The config then needs to be encoded into a bytes array to be able to be passed to ZNS contracts. More information is available on these values and what they mean in Pricing.
Much of this configuration handled for the user when minting through ZERO's Explorer application.
Last updated