Domains
Metadata

Metadata storage system

AZERO.ID takes domain customization and utility to the next level with its modular onchain metadata storage. Users can enhance their domains by adding custom information, such as contact details, credentials, social media links, or wallet addresses on other chains. The potential for domain holders and third-party integrations is endless.

Design

All metadata is stored in an onchain key-value mapping that follows and extends ENSIP-5 (opens in a new tab), which is the standard for storing records in ENS. It's extended as follows:

  • The avatar field extends ENSIP-12 with SS58 & PSP34 support
  • Adds external wallet address support (e.g. address.btc)
  • Adds internal AZERO.ID keys prefixed with azns (not yet used)
  • Certain keys are reserved but not yet applied in our frontend (i.e. display, keywords, notice, mail)

Following ENSIP-5, our metadata storage incorporates the concept of Service Keys (opens in a new tab). These follow a reverse-dot notation and allow linking information of external services to the domain. For example, a user can add their Twitter account to their domain by adding a com.twitter key with their Twitter handle as the value.

Pre-defined keys

These sets of pre-defined keys are used in the AZERO.ID frontend for management and display purposes. However, it's important to note that our protocol doesn't enforce either the key format or frontend-level validation rules. It remains key-agnostic and permissionless, enabling any key-value pair to be stored onchain.

KeyDescription
avatarUsed to store the avatar information for a domain, planned to support ENSIP-12 standard with SS58 and PSP34 extensions.
descriptionUsed to store the description of a domain or bio of the holder.

Please let us know in our Discord (opens in a new tab) if you'd like to see any other keys added to the list.

Size limits

💡

Please note that, regardless of its flexibility, the metadata storage should not be treated as a conventional database. Each type of onchain storage has limitations and associated costs. It should only be used to store important social information, verifiers, and credentials.

  • Keys should not exceed ≈128 bytes
  • Values should not exceed ≈32 kilobytes
CharsetsRole System