Smart Contract NFT minting with Rarities

Question

I'm trying to work out how an NFT collection might be sold on Cardano in the future, specifically by making use of smart contracts.

Let's say that I am creating a 10k pfp collection or something of the sort where each NFT has different attributes and therefore there is some sort of rarity distribution. As the creator of the project I can mint all 10k NFTs and transfer them over to a smart contract. For simplicity we'll say there is one NFT per transaction, so I have 10k UTXOs sitting at my smart contract with 1 NFT each.

When someone comes along to purchase an NFT, how can I make it so they are distributed a random NFT. Since they construct the transaction off the blockchain, they can just select the rarest available NFT.

I am able to come up with a mechanism where I might be able to sell placeholder "redeemable" NFTs that people can purchase and send back to the smart contract, but that would require me to then create a transaction on my end where I consume the buyer's placeholder NFT and one of the unpurchased NFT UTXOs to eventually send the buyer their asset. I don't like this solution because the final transaction, the one executed by the creator to send the NFT, can be executed by off-chain code that isn't transparent to the buyers, which would allow for it to rigged or otherwise incorrect in some way, and the buyer's would be unaware.

I apologize if this is the wrong venue for this question, but I'm eager to start writing Plutus code.

Thanks.

Answer 1

We could use your redeemable approach and make it so the seller cant rig it.

This is the idea, you will need to create 2 different minting policies, one for your NFTs and one for the redeemable NFTs, it is important that both policies do not allow duplication of the asset names (you can do that with something like this https://forum.cardano.org/t/mary-era-nfts-alonzo-era-nfts-which-are-better/82034/24)

Additionally, the policy of the redeemable tokens must allow anyone to burn the token.

So first, you create (but don't mint or reveal yet) the name of your main NFTs, the name of your NFT will have encoded the attributes of the metadata in base 58 for example (or hex even).

And you will have something like:

AwesomeNFT00001mASD34fR342332

The bold part is the encoded metadata.

Then without revealing the asset name of these tokens yet, you create a redeemable token for each, which asset name is the hash of the original token encoded in base58.

AwesomeNFT00001mASD34FR342332 -> FHY45G86DFHY45G86DFHY45G86D

Now you have in policy 1

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.AwesomeNFT00001mASD34FR342332

And in policy 2

0000000000000000000000000000000.FHY45G86DFHY45G86DFHY45G86D (Redeemer token)

And you place all these redeemable tokens in your contract. Once all the redeemable tokens are sold. You then mint the real tokens and place them in a contract with the following condition:

The eUTXO can only be spent if an asset with policy id "0000000000000000000000000000000" and an asset name which is equal to the hash encoded in base58 of the asset name of the token inside this eUTXO is brunt.

Of course, you could have more validations on the contracts, etc.

Now because the contracts don't have access to the transaction metadata, we can't really enforce which values will be there, so this is why I encoded the metadata in the token name instead.

All hashes, encoded values, and policy IDs are dummy values just for demonstration.

In essence, the key would be to commit to the attributes without revealing them, so the buyers cant choose, and the minter cant rig it as they already committed to the value.

I think the current trend of having the NFT attributes in the transaction metadata is not very good, as we can't access these attributes from the contracts, we need to find a better way to express and display attributes on the tokens themselves (and not the transactions)