On-Chain Diagram V3+
Last updated
Last updated
NFD V3.x has on-chain storage identical to V2. Internal properties are still in global state. User-defined and Verified properties are box values.
The key difference with V3 is the registry now stores box values so that the NFDs a particular address OWNS may be easily determined off-chain (using direct chain state). Future algod endpoints allowing the fetching of box keys/values with boxes having a particular prefix will be required for this to be efficient. Until that endpoint is available, every single box value has to be fetched and filtered client-side which is completely unworkable. Fetching hundreds of thousands, or even millions of box keys to filter down to a small number shouldn't be attempted.
Master Registry Contract for all NFDs. This single smart-contract is global registration arbiter of NFDs. There is one NFD registry per Algorand network (betanet, testnet, mainnet comprising 3 independent registries). The application ID of this contract is part of part defines unique and authentic NFDs.
NFD Name registrations are stored in boxes within the registry contract. This is the 'forward lookup' mechanism which allows resolving a name to a NFD.
The box name is resolved by hashing the name with a prefix: SHA2_256("name/{nfd name}"). ie: nfdomains.algo is hashed using "name/nfdomains.algo". The 32-byte hash is then used as the box name.
The value in the box consists of the ASA ID (of the NFDs NFT) and Application ID (of the NFD Smart-Contract) - each 8-byte 64-bit Big-Endian values appended together. {ASA ID}{App ID}
Algorand address linkages (for verified addresses) to NFDs are stored in boxes within the registry contract. This is the 'reverse address lookup' mechanism which resolves an Address to one or more NFDs which point to it. The box name is resolved by hashing the address with a prefix: SHA2_256("addr/{token}/{adddr bytes}"). ie: An algorand address would be hashed using addr/algo/{32 byte algo PK}. The 32-byte hash is then used as the box name. The value in the box consists of a variable sized 'set' of NFD Application IDs (8-byte 64-bit Big-Endian values) appended together. A 0 value respresents an empty slot. Unique values are appended, or replaced in empty slots if found. The set and box will shrink/delete if values are removed from the end.
Tracking of NFDs 'Owned' by a particular address are stored in boxes within the registry contract. Because of box limitations, this value can't be set at mint time, but are initialized post-mint by a watcher process (but anything can call the ownershipAssign contract method to set initially). Future transfers are handled by the NFD calling the registry to remove the key from the seller and set for the new owner.
Is a smart contract where the data for a specific NFD is stored in global state and box values. A distinct instance and new application ID exists of this contract for every NFD. Global state is used for 'internal' properties. User-defined and verified properties are stored in distinct per-field boxes. 'Verified' fields are settable only by the NFD service itself, such as fields requiring some sort of external verification/validation. Once an application id is determined via (#2) or (#3) lookup, then all current NFD data for a particular xxx.algo NFD can be read solely by getting application/box state info from this contract, from any Algorand node.
Is a unique ASA created per-NFD to represent visual ‘ownership’ of a NFD to a user in their Algorand wallet. It will be created defaultFrozen and placed into their wallet as part of an initial series of minting operations and grouped transactions. The ASA can only move to a new owner including the setting of ownership fields in (#4) via a distinct ‘transfer’ operation controlled by (#4). As shown in the ASA once added to the owners Account, the URL will point to an ARC19 template-ipfs link which will resolve to a json body that is kept updated as NFD data is changed by its owner. The metadata will be in an ARC03 equivalent format so that Wallet/Gallery integration showing NFT holdings will show the NFD as an NFT, including its image being the Avatar chosen by the user (which itself could be an NFT).
Represents the Algorand account that is the NFD ‘Owner’
Represents an Algorand account the NFD owner chose to 'link' (also called a Verified address) with their NFD. This address is stored in the NFD but also in the registry so addresses can be looked up to determine the NFDs it is linked to.