Milestone Escrow
Le client bloque d’emblée la totalité du budget, réparti en jalons. Les fonds ne bougent qu’en cas de libération, de décision de l’arbitre ou d’annulation.
Solidity 0.8.28OpenZeppelin v5ETH / ERC-20
SigmaNFT Collection
Drop ERC-721 avec allowlist Merkle, phase publique, royalties et reveal différé
ERC-721ERC-2981Merkle proofsFoundry
De quoi s’agit-il
SigmaNFT ne stocke qu’une racine de Merkle pour l’allowlist (les utilisateurs soumettent une preuve, compatible avec @openzeppelin/merkle-tree), ce qui permet d’inscrire des milliers de soutiens sur l’allowlist sans écrire d’adresses on-chain. Les phases passent de Closed à Allowlist puis à Public, chacune avec son prix et son plafond par wallet, sous une offre maximale globale et immuable.
Tant que le propriétaire n’a pas révélé la collection, chaque token renvoie les métadonnées de substitution ; après le reveal, il pointe vers les métadonnées définitives. Les royalties ERC-2981 signalent aux places de marché la rémunération du créateur, et les recettes sont retirées vers le propriétaire.
Le problème métier
Un drop de NFT doit récompenser les premiers soutiens sans stocker des milliers d’adresses on-chain, empêcher les bots et les whales de rafler le mint, générer des royalties sur les ventes secondaires et éviter le sniping de rareté avant le reveal. Les implémentations naïves échouent précisément sur ces points.
Comment ça marche
- 1
Off-chain : construire un arbre de Merkle à partir de l’allowlist, publier les preuves et définir la racine de Merkle.
- 2
Le propriétaire ouvre la phase allowlist ; les wallets inscrits mintent avec leur preuve, au prix allowlist.
- 3
Le propriétaire ouvre la phase publique ; chacun peut minter jusqu’au plafond par wallet.
- 4
Après le mint, les métadonnées sont téléversées sur IPFS et le propriétaire appelle
reveal(baseURI). - 5
Le propriétaire retire les recettes.
Mesures de sécurité
- Chemins de mint nonReentrant ; compteurs mis à jour avant les callbacks de _safeMint
- Règle du paiement exact : pas de logique de remboursement, pas d’ETH perdu
- Feuilles de Merkle doublement hachées, vérifiées avec MerkleProof d’OpenZeppelin
- Offre maximale immuable ; Ownable2Step
- Le retrait fait un revert au lieu de perdre des fonds en silence
- Vérifié par fuzzing : supply ≤ MAX_SUPPLY, balance == minted × price
Fonctionnalités
- Allowlist Merkle (par preuve)
- Phases Closed → Allowlist → Public avec des prix distincts
- Limites par wallet pour chaque phase
- MAX_SUPPLY immuable
- Royalties ERC-2981
- Reveal différé
Cas d’usage typiques
- Drops PFP et artistiques, pass d’adhésion, billets d’événements
- Collections de fidélité de marque pour des clients existants
- Préventes d’objets de jeu avec révélation différée de la rareté
Limites connues
L’hébergement des métadonnées (p. ex. le pinning IPFS) est opéré off-chain.
Autres contrats vitrines
Token + Vesting + Staking
Un ERC-20 plafonné avec approbations sans gas, des calendriers de vesting avec cliff pour l’équipe et les investisseurs, et des récompenses de staking sur le modèle de Synthetix.
ERC-20EIP-2612OpenZeppelin v5
Gold-Backed Token (RWA)
L’adossement devient une condition préalable de l’émission : des tokens ne peuvent être émis que si la réserve d’or déclarée couvre la nouvelle offre totale.
ERC-20AccessControlProof of reserve
Standards : Solidity 0.8.x, OpenZeppelin, tests Foundry avec fuzzing, analyse statique Slither, code source vérifié. 223 tests · couverture 100 % · analysé par Slither.
Vous avez un projet en tête ?
Décrivez votre projet en quelques lignes. Un ingénieur senior vous répond sous 24 heures les jours ouvrés ; suivent un avis honnête, un périmètre clair et une proposition à prix fixe ou par jalons, en général en quelques jours ouvrés.
Vous préférez d’abord écrire ? Écrivez-nous
Vous échangez directement avec Ing. Ismet Mesic, Tech lead.