Be sure to see Reading of NFD metadatafor descriptions of how to read the metadata. This merely lists the explicit properties and some conventions

Internal Properties

All of these properties will be prefixed with 'i.' - so a field listed as asaid is really stored as i.asaid

ONLY the Contract itself can alter these properties.



ASA ID (8-byte BE). The id of the NFT created by the NFD and set into the owners account. Upon claiming, or purchase, the NFT is clawed by the NFD from seller to buyer.


The name of the NFD (may not be full portion - details in the future)


A category as set by NFDomains at mint time. Current possible values are: curated, premium, and common.


If set, account that will receive a commission upon sale. If commission2Agent is set, then after sale, commission2Agent replaces commission1Agent (and percentage) and is cleared. This allows primary and secondary sales to have different commission agents.


commission % (in tenths). 10 would be 1 %. 8-byte BE


If set, this account has placed Algo into the NFD's account in advance to be used in later claiming. Upon the NFD being purchased (initial claim only), then if the buyer is the same as the kickoff creator the amount needed to claim is their kickoff amount + the amount they're offering on the purchase. If the purchaser is not the same as the kickoff creator, then the kickofCreator account is refunded their kickoffAmount


The amount the KickoffCreator account placed into the NFD.


Highest sale price for this NFD in its lifetime (in microAlgos) 8-byte BE


The 32-byte PK of the Algorand account that owns this NFD


If this is a segment, this will be set to the App ID of this NFD's root NFD.


Only set if NFD is for sale. This is effectively a state unto itself. A for-sale NFD should NOT accept deposits. The sale price in microAlgos. 8-byte BE


The sales method in which this NFD was originally minted - currently either auction, or buyItNow


The 32-byte PK of the 'seller' of this NFD. This is the account paid upon any sale. At mint time, the seller is NFDomains and then upon claiming, the seller is always set to the new owner.


The on-chain 'last timestamp' [seconds since epoch] when the NFD was created via its app create/creation contract call.


The on-chain 'last timestamp' for updates of the NFD - sales, metadata updates, etc.


Timestamp of most recent purchase


The 'NFD contract' version. Set at creation time, and if upgraded (to version of new contract)


0 for unlocked, 1 for locked. Defaults to 0. If set to 1 by NFD owner, the contract of that NFD is completely blocked from being changed. Owner may later unlock, and upgrade on-demand if desired.


0 for unlocked, Undefined or 1 for locked. Defaults to locked. If NOT set to 0 by NFD owner, the NFD root is locked and a segment of the root can't be minted


For unlocked segment, the price in USD cents to mint a segment off this unlocked root. 400 would be $4.00. 8-byte BE value


If a root, the number of segments that have been minted from this NFD. (8-byte BE)


"0" for unlocked, Undefined or "1" for locked. Defaults to UNLOCKED. Can also be set to a Itob(xx) (64-bit Big-Endian value) representing the timestamp at which the vault should 're-lock'. If < current timestamp, then vault is UNLOCKED. If > current timestamp, then vault is locked. This is useful for 'allow airdrops for... 1 hour' sort of requests. If locked, only the owner can send new assets into the vault

User-Defined Properties

User properties are arbitrary and can be set to anything by the user.

All of these properties will be prefixed by 'u.'.

Some properties will be treated specially by the NFDomains UI, but there are no explicit rules for them. Owners may cause problems with some integrations if the conventions aren't followed though.



User / Company name



Company address, etc.


Email address that can optionally be set as a 'verified' email if user verifies their email address.


Url to redirect to via domain, can also be ipfs://XXXXX link as well.


Url to avatar image (ipfs:// supported and preferred)


Url to banner image


Twitter handle - preferably an intermediate field set prior to verification.


intermediate field - preferably used to specify the discord user (snowflake) id as part of verification process.


intermediate field - preferably used to specify the telegram id as part of verification process


DNS Zone name (ie: for possible verification.


Simple link to show on profile for viewers to click-through


User-defined Algorand Addresses (C]rypto A]ddress Algo]rand), stored comma-delimited. Exposed as top-level unverifiedCaAlgo array in API.


User Defined C]rypto A]ddress. Use token name for type. ie: ca.btc for Bitcoin deposit address. ca.eth for Ethereum, etc.


Verified Properties

All of these properties will be prefixed by 'v.'

ONLY NFDomains can currently set verified properties.

As decentralized services become available which can be trusted with these off-chain/on-chain services, NFDomains will strive to remove to remove this requirement and support these services being given the trust to set certain verified properties.



Link to verified avatar - typically ipfs:// link


The ASA ID of the avatar. NFDomains will re-assert that this ASA is still owned by accounts related to the NFD and will clear the avatar fields if not.


Link to verified banner - typically ipfs:// link


The ASA ID of the banner. Re-asserted same as avatar. /, etc.

See Reading of NFD metadatafor details. Contains packed 32-byte PKs of Algorand addresses which were verified by the owner as an address they can sign for.


DNS Zone that was verified


Telegram @handle that was verified


Discord snowflake ID that was verified


Telegram user id that was verified.

Last updated