[Uniques v2] Explaining "Claims with the off-chain signature" distribution method

[Yuripetusko]

Hey @jsidorenko, from the upcoming pallet unique v2 features, this one seems really interesting. Could you describe it here a bit more so we could have a single place to discuss it until it's implemented?

[jsidorenko]

After checking different NFTs distribution approaches, I found those the most common:

• public claims where anyone could simply claim NFTs until the supply lasts (optionally it's possible to set the price per claim)
• Merkle tree based claims. That method allows constructing a pretty large list of users eligible for a drop (you can specify user's address and NFT's id), calculate the Merkle tree root hash and store it on-chain. Storage-wise, you will store only a single hash (or a small array of hashes for the large data set) instead of storing all the eligible addresses. The downside of this approach is the need to update the root hash every time you want to change the list of addresses. Good reading on that topic
• Coupon-based distribution. It's a way to pre-sign multiple claims and distribute those signatures offchain. On a technical level, you will first need to sign some object, e.g. { collection_id, item_id, receiver_address }. Then, you should provide all the information + the signature to the end-user. Finally, the end-user will call a claim(collection_id, item_id, signed_object) and get his NFT.
  With that approach it's easier to manage the lists, no need to submit any transactions on-chain and store any data upfront. But, the only drawback is the inability to revoke the signature. Although I saw some projects keeping an extra array of revoked signatures. Some reading on that approach

[Yuripetusko]

Great thank you, sounds a bit like jwt.

[jsidorenko]

Yep, there are similarities. The first time I saw it, was the DAI contract where this approach was called as Permit pattern, which later got spec'ed in EIP-2612.

[HashWarlock]

For the coupon-based distribution, we did something similar in our Phala World pallet for whitelisted accounts for the NFT Sale. We sign the account with a Purpose enum then verify the claim & mint the NFT to the user. Here is some of the code here:
https://github.com/Phala-Network/khala-parachain/blob/05b55c42d84ca7bf3841197b5b954a3a4b397800/pallets/phala-world/src/nft_sale.rs#L526-L536

verify_claim function:
https://github.com/Phala-Network/khala-parachain/blob/05b55c42d84ca7bf3841197b5b954a3a4b397800/pallets/phala-world/src/nft_sale.rs#L1098-L1114

One thing I thought for revoking signatures would be creating a permissioned account as the Signer for the collection's team then change the Signer account if signatures need to be revoked & regenerate the signed coupons list off-chain for the approved accounts to retrieve their new coupon via the API like described in the article mentioned. That way if an approved account were to get a failed transaction due to the change of the Signer account then they can call the retrieve coupon again & have a new coupon that would allow the mint to go through. It's a small inconvenience, but removes the need to manage an array of revoked signatures along with having to store all signatures off-chain in a DB to be able to revoke the exact signature that was generated for a specific user since signatures change every time they're signed.

[jsidorenko]

One more cool thing about the pre-signed claims is the ability to set the metadata within that claim. The metadata would be part of the claim object and it would be possible to display the NFT a user will receive before he starts claiming.