---
# System prepended metadata

title: Random NFT

---

# Random NFT
On peut distinguer 3 maniere differentes de proposer des tokens de maniere "random" :

1. une collection NFT avec nombre de tokens predefini
	la solution consiste a assigner un item de la collection de maniere aleatoire
2. une collection NFT infinie (générative)
	la solution consiste a demander a un oracle d'appliquer un nombre aleatoire a un NFT precis
3. une collection SFT avec tokens et supply predefinis

## 1. Collection NFT avec nombre de tokens predefini

La solution la plus éprouvée est celle du "provenance hash".

Cette solution est tres bien expliquée sur medium dans cet article : [The Elegance of the NFT Provenance Hash solution](https://medium.com/coinmonks/the-elegance-of-the-nft-provenance-hash-solution-823b39f99473)

L'astuce consiste simplement a calculer et publier un "provenance hash" avec le contract de collection, certifiant ainsi l'authentiticité de chacun des elements de la collection, sans avoir besoin de révéler les metadonnées.

Concernant l'attribution aleatoire des NFT, la solution consiste a calculer le premier NFT de la serie d'une maniere imprevisible, par exemple en prenant le reste de la division euclidienne du niveau de block du dernier NFT minté, par le nombre total de NFT de la collection. Le block level sert ici d'entropie.

ex: 2869273 % 1250 = 523

Dans l'exemple précédent, le premier NFT de la série à être attribué sera l'id 523.

Il a apparait plusieurs contraintes à cette solution:
- la révelation des metadonnées doit se faire seulement une fois apres que tous les NFT ont été attribués.
- les metadonnées doivent etre definies de maniere tres précise, et ne jamais changer, sans quoi le provenance hash n'est plus valide. 

### Ressources Supplémentaires :

- ce [thread du forum openzeppelin](https://forum.openzeppelin.com/t/are-nft-projects-doing-starting-index-randomization-and-provenance-wrong-or-is-it-just-me/14147/11) contient des remarques interressantes sur le provenance hash
- le concept a été implementé en tant qu'[extension ERC-721](https://github.com/1001-digital/erc721-extensions/blob/main/contracts/RandomlyAssigned.sol)
- [Parrotz](https://tzdropz.com/collections/parrotz/) est un projet Tezos qui a utilisé ce concept

TODO: implementation LigoLANG ?

## 2. Collection NFT infinie

Aussi appelée "collection générative" car le principe est qu'un NFT ainsi créé sera defini par des traits completement aléatoires.

C'est le principe utilisé sur une collection populaire sur Tezos : [Randomly Common Skeles](https://commonskeles.xyz/about.html)
Cette collection a utilisé un oracle d'ubinetic (maintenant [Acurast](http://docs.acurast.com/))
La solution est composée d'un [contrat minter](https://better-call.dev/mainnet/KT1AvxTNETj3U4b3wKYxkX6CKya1EgLZezv8/) et d'un [contrat FA2](https://better-call.dev/mainnet/KT1HZVd9Cjc2CMe3sQvXgbxhpJkdena21pih) pour la collection.

TODO: reverse engineering et implementation LigoLANG


## 3. Collection SFT avec tokens et supply predefinis

Ce type de collection propose un nombre determiné de token avec pour chacun une quantité determinée. L'identifiant de token est attribué de manière aléatoire.
Cette solution necessite un nombre aleatoire, on peut utiliser un oracle ou bien simplement le block hash si il est acceptable d'effectuer la revelation dans le bloc suivant.

Solution potentielle: 
ajouter une structure de données de type (address, nat) big_map

https://research-development.nomadic-labs.com/verifiable-delay-functions.html



## Ressources Annexes

https://www.opentezos.com/smart-contracts/avoiding-flaws/#6-not-protecting-against-bots-bpev-attacks
https://www.paradigm.xyz/2021/10/a-guide-to-designing-effective-nft-launches
https://docs.openzeppelin.com/contracts/2.x/crowdsales
https://ethereum.stackexchange.com/questions/101803/ensuring-a-fair-distribution-of-an-nft-set#answer-101807
https://blog.trailofbits.com/2018/10/12/introduction-to-verifiable-delay-functions-vdfs/