Using an NFD for sending assets to Algorand accounts
Every NFD can have multiple Algorand accounts associated with it, as well as addresses for other crypto accounts, they are:
- caAlgo[*] (C]rypto A]ccount Algo]rand)
- This is really the verified 'v.caAlgo' property expanded into a top-level property for integration ease.
- These addresses are accounts the owner had to sign for in order to add, thus they are accounts the user has keys for.
- This is the user-defined caalgo property expanded into a top-level property.
- These are accounts the owner has entered into the NFD but for whatever reasons aren't accounts they can sign for. It might be because they're custodial accounts (exchanges, etc.), multisig (because of poor wallet support/timing issues), or contract accounts.
- One thing to note is, these ARE accounts the owner had to actually enter. So there is a certain level of trust in that the owner of the NFD is saying these are valid accounts for their NFD.
- However, they can reference accounts someone else owns though (!) - so for reverse lookups (ie: NFT creator wallets) - these have a different trust level.
- Owner (the actual 'owner' of the NFD)
- This is the account that owns the NFD and is able to make changes to it, or to sell it. Listing an NFD for sale clears all metadata and can technically happen at any time, so be careful with cache lengths. An NFD and its app ID will never change, nor its name, but the data within it can change over time.
Based on the above, for SENDING ALGORAND TO AN NFD NAME, the guidance of what account to use is as follows and in the following order (only one can be chosen!).
- If caAlgo contains entries, use the FIRST account - caAlgo. The UI shows this to users as the deposit address.
- If no caAlgo is set, then use unverifiedCaAlgo. This is still an address the owner set so it should be safe to send to.
- If caAlgo and unverifiedCaAlgo are empty, fall back to owner, but ONLY IF THE NFD IS NOT FOR SALE. The NFD state property should be "owned" before accepting deposits. If not in 'owned state' (for sale, un-claimed, ..) then sending should be blocked.
All of the above choices are resolved into a single top-level property: depositAccount and if using the API, simply using the depositAccount property is all that is required.
It will be set to caAlgo, unverifiedCaAlgo, owner, or if sending should be blocked will be missing.
Note: If the NFD is not formally owned (state: owned), the depositAccount property will be missing and sending to this NFD should be blocked.
To fetch the name, wallets should use the on-chain mechanics as described in Name & Address Lookup. The API forces HTTPS and the domain is protected by DNSSEC, so MITM attacks shouldn't be an issue, but using independent Algorand nodes or your own nodes that you trust is probably best, particularly for large transfers.
The above properties will be in v.caAlgo.0.as, u.caalgo (comma delimited), i.owner.a, and code to handle the .as [algorand set] and possible merging of values will be necessary.
Make note of the exception that if i.sellamt is set to block sends as the NFD is up for sale.
See the linked github repo for details.
If this isn't something easily done, then use the REST API and the Get NFD API as described below. The 'brief' view for an NFD is sufficient to provide all of the above addresses.