# $CUBE — Protocole du cube partagé ### Documentation complète *Document de conception — version de travail* --- ## Table des matières **Partie I — Ce que c'est** 1. [Résumé](#1-résumé) 2. [Avertissement : ce que ce protocole n'est pas](#2-avertissement--ce-que-ce-protocole-nest-pas) 3. [Le principe en une page](#3-le-principe-en-une-page) 4. [Pourquoi le cube et pas autre chose](#4-pourquoi-le-cube-et-pas-autre-chose) **Partie II — L'objet** 5. [L'état du cube](#5-létat-du-cube) 6. [Le score d'une face](#6-le-score-dune-face) 7. [Les mouvements et leurs effets](#7-les-mouvements-et-leurs-effets) 8. [Les six camps](#8-les-six-camps) **Partie III — L'économie** 9. [Le prix d'un mouvement](#9-le-prix-dun-mouvement) 10. [Répartition du prix](#10-répartition-du-prix) 11. [La rémunération des camps](#11-la-rémunération-des-camps) 12. [La cagnotte](#12-la-cagnotte) 13. [La boucle complète](#13-la-boucle-complète) **Partie IV — L'arc** 14. [La résolution](#14-la-résolution) 15. [L'expansion](#15-lexpansion) 16. [Les époques](#16-les-époques) **Partie V — Le token** 17. [Rôle du token](#17-rôle-du-token) 18. [Distribution](#18-distribution) 19. [Le jour J](#19-le-jour-j) **Partie VI — Technique** 20. [Représentation de l'état](#20-représentation-de-létat) 21. [Les permutations](#21-les-permutations) 22. [Architecture des contrats](#22-architecture-des-contrats) 23. [Engagement chiffré sur la résolution](#23-engagement-chiffré-sur-la-résolution) 24. [Invariants](#24-invariants) 25. [Sécurité](#25-sécurité) **Partie VII — Réalité** 26. [Théorie des jeux](#26-théorie-des-jeux) 27. [Paramètres à calibrer](#27-paramètres-à-calibrer) 28. [Ce qui peut mal tourner](#28-ce-qui-peut-mal-tourner) 29. [Phasage](#29-phasage) 30. [Communication](#30-communication) 31. [Questions ouvertes](#31-questions-ouvertes) 32. [Glossaire](#32-glossaire) --- # Partie I — Ce que c'est ## 1. Résumé Un seul Rubik's cube, partagé, dont l'état vit dans un contrat. Six couleurs, six camps. On rejoint un camp en immobilisant du $CUBE sur une couleur. Chaque face a un **score** : le nombre de ses cases actuellement de la bonne couleur. N'importe qui peut payer, en $CUBE, pour tourner une face. Le mouvement s'applique immédiatement, et il déplace les cases de plusieurs camps à la fois — jamais seulement les siennes. **L'argent des mouvements est redistribué aux camps, proportionnellement à leur score.** Un camp bien rangé encaisse ; un camp en désordre ne touche presque rien. Une partie est détruite, une partie s'accumule dans une cagnotte. La cagnotte n'est libérée que lorsque le cube est entièrement résolu. À ce moment-là, il **grandit** : 3×3 devient 5×5, puis 7×7. Chaque époque est plus longue, plus chère et plus difficile que la précédente. Le cœur du sujet tient dans une propriété mathématique de l'objet lui-même : **on ne peut pas résoudre un Rubik's cube sans défaire ce qui est déjà en place.** Un cube ne peut donc pas être résolu par des acteurs purement égoïstes. Il faut que quelqu'un accepte de reculer. --- ## 2. Avertissement : ce que ce protocole n'est pas Cette section vient en deuxième position délibérément. Tout le reste du document doit être lu à sa lumière. ### 2.1 Il n'y a aucun revenu extérieur Le cube ne produit rien. Il n'y a pas de frais de trading captés ailleurs, pas d'activité tierce sur laquelle prélever, pas de flux venant d'en dehors du protocole. **Tout l'argent qui sort vient de l'argent qui est entré, moins ce qui a été détruit.** C'est une économie fermée, à somme négative après destruction. Le format exact d'un jeu avec prélèvement — le modèle du poker, pas celui d'un péage. ### 2.2 Ce que cela interdit - **Ne jamais parler de rendement.** Ce qu'un camp encaisse vient de ce que les joueurs ont payé, pas d'une production de valeur. - **Ne jamais présenter le mécanisme comme garantissant une hausse.** La destruction est proportionnelle à l'activité ; sans activité, il n'y a rien. - **Ne jamais l'appeler un protocole financier.** C'est un jeu à enjeu, et le dire est la seule position tenable. ### 2.3 Ce que cela n'interdit pas Un jeu à enjeu peut parfaitement fonctionner, durer et avoir de la valeur. Le poker en ligne est une industrie. Ce qui tue ce genre de projet, ce n'est pas le format — c'est de le maquiller en produit financier et de se faire démonter par la première personne compétente qui regarde. **La position honnête est plus solide que la position déguisée**, et sur ce type de projet elle est aussi la seule qui survive à un examen public. ### 2.4 La conséquence sur la durée Un jeu vit tant qu'on y joue. Il n'y a pas d'activité extérieure pour prendre le relais pendant les périodes creuses. Le mécanisme d'époques (partie IV) est la seule réponse structurelle : quand l'activité ralentit, le coût de résolution devient inférieur à la cagnotte accumulée, quelqu'un résout, et une nouvelle époque commence. **Le protocole se relance lui-même au lieu de mourir lentement.** C'est le mécanisme le plus important du design, et c'est celui à ne pas casser. --- ## 3. Le principe en une page ``` ┌────────────────────────┐ │ LE CUBE │ │ état dans le contrat │ └───────────┬────────────┘ │ ┌──────────────────────────┼──────────────────────────┐ │ │ │ ▼ ▼ ▼ Six faces Un mouvement Six camps chacune a un score coûte du $CUBE on rejoint en de 0 à N et est détruit immobilisant │ en partie du $CUBE │ │ │ └──────────────────────────┼──────────────────────────┘ │ Le prix payé est réparti : ───────────────────────── · une part détruite · une part à la cagnotte · une part aux camps, au prorata de leur score │ ▼ Le cube est résolu ? │ ┌──────────┴──────────┐ │ non │ oui ▼ ▼ on continue cagnotte payée cube agrandi nouvelle époque ``` ### Ce que fait un joueur, concrètement 1. Il achète du $CUBE et l'immobilise sur une couleur. Il est maintenant dans ce camp. 2. Il touche une part des mouvements payés par les autres, proportionnelle au score de son camp. 3. Pour augmenter ce score, il paie pour tourner une face — mais ce faisant, il paie tout le monde, y compris ses adversaires. 4. Un autre joueur peut défaire son mouvement au coup suivant. **Le paradoxe central, et c'est ce qui fait tourner la machine :** pour augmenter sa part du pot, il faut alimenter le pot. --- ## 4. Pourquoi le cube et pas autre chose ### 4.1 La propriété qui n'existe nulle part ailleurs Sur une grille de cases, ma case est à moi. Ce que je fais ne concerne que moi. Sur un cube, **aucune action n'est locale.** Tourner une face déplace vingt cases appartenant à quatre camps différents. Il est structurellement impossible d'agir sans affecter les autres. Ce n'est pas une contrainte ajoutée par le design. C'est la géométrie de l'objet. ### 4.2 La propriété qui fait le récit Résoudre un Rubik's cube exige, à un moment, de **défaire une face déjà terminée** pour placer les pièces suivantes. C'est vrai de toutes les méthodes de résolution existantes, sans exception. Traduit en termes de camps : **le cube ne peut pas être résolu si chaque camp refuse de reculer.** Il faut soit une coordination réelle, soit un acteur assez gros pour porter le recul tout seul. C'est une vérité mathématique sur l'objet, pas une métaphore marketing. Elle donne au projet une chose rare : un récit qui est aussi une contrainte réelle du système. ### 4.3 Le cube est aussi son propre visuel Un objet 3D, immédiatement reconnaissable partout dans le monde, qui bouge à chaque action, qui s'anime, se filme et s'intègre ailleurs. Sur un projet dont la seule ressource de croissance est l'attention, ce n'est pas un détail cosmétique — c'est l'actif principal. ### 4.4 Ce que le cube n'apporte pas Il n'apporte aucun flux, aucun sous-jacent, aucune utilité en dehors de lui-même. Voir section 2. --- # Partie II — L'objet ## 5. L'état du cube ### 5.1 Structure Un cube de taille `n` possède 6 faces de `n²` cases, soit `6n²` cases au total. | Taille | Cases | Cases par face | |---|---|---| | 3×3 | 54 | 9 | | 5×5 | 150 | 25 | | 7×7 | 294 | 49 | | 9×9 | 486 | 81 | Chaque case porte l'une des six couleurs. L'état complet du cube est la liste ordonnée de ces couleurs. ### 5.2 Le centre est fixe Sur un cube de taille impaire, la case centrale de chaque face ne bouge jamais, quelle que soit la rotation appliquée. **C'est elle qui définit l'identité de la face.** La face « rouge » est la face dont le centre est rouge. Cette définition est stable pour toute la durée d'une époque, ce qui garantit qu'un camp sait toujours quelle face est la sienne. Le protocole n'utilise que des cubes de taille impaire, pour cette raison précise. Un cube pair n'a pas de centre fixe et l'identité des faces devient ambiguë — ce qui rendrait la notion de camp incohérente. ### 5.3 État initial Au début de chaque époque, le cube est mélangé par une séquence aléatoire suffisamment longue pour atteindre une position uniformément distribuée. L'aléa utilisé doit être imprévisible et non influençable. Un aléa dérivé d'un hash de bloc est insuffisant sur une chaîne disposant d'un séquenceur : quelqu'un pourrait choisir la position de départ. --- ## 6. Le score d'une face ### 6.1 Définition ``` score(face X) = nombre de cases actuellement sur la face X dont la couleur est X ``` Le score va de 1 (seul le centre, qui ne bouge jamais) à `n²` (face entièrement rangée). | Taille | Score minimum | Score maximum | |---|---|---| | 3×3 | 1 | 9 | | 5×5 | 1 | 25 | | 7×7 | 1 | 49 | ### 6.2 Ce que le score représente C'est la seule variable qui compte pour un joueur, et elle est immédiatement lisible sur l'image du cube. Pas de graphique à interpréter, pas d'indicateur composite : **on voit le score en regardant.** ### 6.3 Le score total ``` score total = somme des six scores ``` Il va de 6 (cube maximalement mélangé) à `6n²` (cube résolu). **Le score total n'est pas constant.** C'est le point qui distingue ce jeu d'un jeu à somme nulle : un mouvement peut augmenter l'ordre global, ou le diminuer. Autrement dit, **les joueurs peuvent collectivement créer ou détruire de la valeur de position.** C'est ce qui rend la coordination possible — et intéressante. ### 6.4 Affichage public Trois chiffres suffisent à raconter l'état du protocole à n'importe quel instant : ``` 🔴 8/9 🔵 4/9 🟢 6/9 🟡 3/9 🟠 9/9 ⚪ 5/9 Ordre total : 35 / 54 Cagnotte : 41 200 $CUBE ``` C'est l'objet à publier en continu. Il bouge à chaque mouvement, il tient dans une image, il se partage sans explication. --- ## 7. Les mouvements et leurs effets ### 7.1 Le catalogue Sur un cube 3×3, il existe **18 mouvements** : 6 faces × 3 rotations (un quart de tour horaire, un demi-tour, un quart de tour antihoraire). Sur les cubes plus grands s'ajoutent les rotations de tranches internes, ce qui augmente considérablement le nombre de mouvements possibles et la longueur des solutions. | Taille | Mouvements distincts | Cases déplacées par mouvement | |---|---|---| | 3×3 | 18 | 20 | | 5×5 | 54 | 44 (rotation externe) | | 7×7 | 108 | 68 (rotation externe) | ### 7.2 La propriété qu'il faut connaître pour jouer C'est la règle qui donne sa profondeur au jeu, et elle n'est pas évidente : > **Tourner une face ne change pas son propre score, ni celui de la face opposée.** Quand on tourne la face rouge, les cases qui sont dessus permutent entre elles mais restent sur la face rouge. Le score rouge est inchangé. La face opposée n'est pas touchée du tout. **Seules les quatre faces adjacentes voient leur score bouger.** Conséquences directes : - **Pour améliorer son propre score, il faut tourner une face adjacente à la sienne.** On ne peut jamais s'améliorer en tournant sa propre face. - **Tout mouvement qui m'améliore affecte trois autres camps.** Il n'existe aucun coup gratuit. - **Chaque camp a une face « neutre »** — la sienne — et une face « inoffensive » — l'opposée. Cette structure est ce qui empêche l'existence d'une stratégie dominante simple. Le jeu se lit, et il se lit d'autant mieux qu'on comprend cette règle. C'est de la profondeur réelle, pas de la complexité ajoutée. ### 7.3 Atomicité Un joueur peut soumettre **une séquence de mouvements en une seule transaction**, et paie le prix de chacun. Ce n'est pas un confort, c'est une nécessité : sans cela, un joueur exécutant une résolution en cinquante coups se ferait interrompre au vingtième par quelqu'un d'autre, et perdrait tout ce qu'il a payé. ```solidity function play(uint8[] calldata moves) external; ``` --- ## 8. Les six camps ### 8.1 Rejoindre On rejoint un camp en immobilisant du $CUBE sur une couleur. Le montant est libre. Il n'y a ni whitelist, ni sélection, ni limite. ```solidity function join(uint8 color, uint256 amount) external; function leave(uint8 color, uint256 amount) external; // après délai ``` ### 8.2 Le délai de sortie Sortir d'un camp — ou en changer — est soumis à un délai. Sans lui, la stratégie optimale serait triviale : attendre le dernier moment et basculer sur le camp qui vient de monter. Le délai force à s'engager **avant** de savoir, ce qui est la condition pour que le choix de camp ait un sens. ### 8.3 La part d'un joueur ``` part du joueur = sa mise sur la couleur / total misé sur cette couleur ``` Ce qu'un camp encaisse est réparti entre ses membres au prorata. ### 8.4 Pondération temporelle La mise prise en compte pour la rémunération n'est pas la mise instantanée mais une **moyenne sur une fenêtre glissante**. Sans cette pondération, il suffirait d'entrer massivement juste avant une distribution et de sortir juste après. La pondération rend l'engagement réel et rend visible, dans les chiffres publics, la différence entre un camp installé et un camp de circonstance. ### 8.5 Ce qui n'est pas fait, et pourquoi **Pas de token distinct par couleur.** L'idée d'émettre six tokens échangeables a été écartée : leur prix serait déterminé par la spéculation et non par le score, ce qui ferait diverger le prix affiché de la réalité du cube et créerait une couche réflexive impossible à expliquer. La mise par couleur, elle, est un chiffre exact, vérifiable et directement lisible. **Pas de propriété de cases individuelles.** Un système où chaque case appartient nominalement à quelqu'un multiplie la complexité sans rien ajouter : ce qui compte est déjà agrégé dans le score de la face. --- # Partie III — L'économie ## 9. Le prix d'un mouvement ### 9.1 Un prix dynamique, pas fixe Le prix d'un mouvement suit l'activité récente, selon un mécanisme de tarification de congestion : ``` si activité récente > cible → le prix monte si activité récente < cible → le prix redescend ``` Le prix évolue par pas multiplicatifs bornés, à partir d'un prix plancher. ### 9.2 Pourquoi dynamique **Anti-spam.** Un prix fixe permet à un acteur bien doté d'inonder le cube de mouvements pour un coût constant. Un prix qui monte rend l'inondation exponentiellement chère. **Capture des pics.** Pendant un conflit intense, le prix monte, donc la destruction et la cagnotte augmentent au moment exact où l'attention est maximale. **Autorégulation.** Quand plus personne ne joue, le prix redescend jusqu'à ce que jouer redevienne bon marché. Le mécanisme se relance de lui-même. **Un chiffre à regarder.** Le prix du mouvement devient un indicateur public de la tension en cours, au même titre que les scores. ### 9.3 Pourquoi pas de limite par adresse Toute limite fondée sur l'adresse est contournée par la multiplication des adresses, qui coûte quelques centimes. Une limite par adresse ne gêne que l'utilisateur honnête. **Le prix est la seule limite qui ne se contourne pas**, parce qu'elle ne dépend d'aucune identité. ### 9.4 Échelle selon la taille du cube Sur un cube plus grand, un mouvement déplace une proportion plus faible de l'ensemble et les solutions sont bien plus longues. Le prix plancher de base doit donc être calibré par époque, en fonction de la taille — sans quoi les grandes époques deviendraient prohibitives ou dérisoires. --- ## 10. Répartition du prix Chaque mouvement payé est réparti immédiatement : | Destination | Part indicative | Fonction | |---|---|---| | **Détruit** | ~30 % | Réduit l'offre proportionnellement au conflit | | **Cagnotte** | ~30 % | Construit l'enjeu de l'époque | | **Camps** | ~40 % | Rémunère les positions, au prorata des scores | | **Équipe** | **0 %** | — | ### 10.1 La part camps Elle est répartie entre les six camps proportionnellement à leur score : ``` part du camp X = montant × score(X) / score total ``` Puis, à l'intérieur d'un camp, au prorata des mises pondérées dans le temps. **Un camp à 9/9 encaisse neuf fois plus qu'un camp à 1/9.** L'écart est brutal, et c'est délibéré : c'est ce qui rend le score désirable et donc le conflit permanent. ### 10.2 Aucune part à l'équipe Aucune fraction des flux ne va à l'équipe. Une allocation peut exister dans l'offre initiale, vestée et annoncée publiquement, mais elle ne se sert jamais dans le fonctionnement. C'est l'une des deux seules choses qu'un observateur peut vérifier en trente secondes — l'autre étant l'immuabilité des contrats. Ce sont donc les deux qui comptent réellement en présentation. --- ## 11. La rémunération des camps ### 11.1 Modèle en réclamation Rien n'est distribué automatiquement. Le contrat tient un accumulateur par couleur, et chaque membre réclame quand il veut. ```solidity mapping(uint8 => uint256) accPerShare; // accumulé par unité de mise, par couleur mapping(address => mapping(uint8 => uint256)) debt; ``` Une boucle de distribution sur une liste d'adresses est à la fois un vecteur de blocage — une seule adresse récalcitrante gèle tout — et une bombe à gas. **Le modèle en réclamation est le seul acceptable.** ### 11.2 Ce que voit un joueur ``` Ton camp : 🔴 Rouge Score 8/9 Ta mise 12 400 $CUBE (2,1 % du camp) À réclamer 318 $CUBE Sur 24 h + 1 042 $CUBE ``` ### 11.3 Ce que cette rémunération n'est pas Ce n'est pas un rendement. C'est une part des sommes payées par les joueurs qui ont bougé le cube. S'il n'y a aucun mouvement, il n'y a aucune rémunération. Le libellé dans l'interface doit être « part des mouvements », jamais « APR » ni « rendement ». Ce n'est pas une précaution juridique, c'est une question d'exactitude — et le premier observateur compétent qui verra un APR affiché comprendra que le reste est également maquillé. --- ## 12. La cagnotte ### 12.1 Fonctionnement Une part de chaque mouvement s'accumule dans une cagnotte, verrouillée et publiquement visible. Elle ne peut être libérée que par une résolution complète du cube. ### 12.2 Le compte à rebours implicite C'est le meilleur objet public du protocole, et il ne demande aucun effort de communication : ``` Cagnotte 41 200 $CUBE Coût estimé d'une résolution ~52 000 $CUBE (≈ 47 mouvements au prix actuel) Écart −10 800 ``` Quand la cagnotte dépasse le coût de résolution, résoudre devient rentable. **Tout le monde peut faire ce calcul, en permanence, et voir l'échéance approcher.** Cet écart est le chiffre à publier en continu. Il crée une anticipation réelle sans qu'aucune date n'ait été annoncée. ### 12.3 Le double mouvement qui rend la tension permanente Deux forces jouent en sens contraire sur cet écart : - **La cagnotte monte** à chaque mouvement joué. - **Le coût de résolution monte** quand quelqu'un mélange davantage le cube. Les camps bien placés ont intérêt à repousser la résolution — ils encaissent leur score. Mais chaque mouvement qu'ils jouent pour brouiller **alimente la cagnotte**, donc rapproche le moment où résoudre devient rentable. **Se défendre revient à financer son adversaire.** Cette tension n'a pas besoin d'être équilibrée par des paramètres : elle est structurelle. ### 12.4 Le plafond mathématique Sur un cube 3×3, toute position est résoluble en **20 mouvements au maximum** — c'est un résultat démontré, connu sous le nom de nombre de Dieu. Conséquence directe : **le coût de résolution d'un 3×3 est plafonné à 20 fois le prix du mouvement**, quel que soit le degré de mélange. Il est donc impossible de rendre un 3×3 durablement inatteignable. Deux nuances importantes : - Atteindre ce minimum de 20 coups exige un solveur optimal, coûteux en calcul. Un solveur courant produit des solutions de 50 à 60 coups, donc trois fois plus chères. **Il existe un avantage réel et légitime à disposer d'un meilleur solveur.** - Sur les cubes plus grands, le nombre de Dieu n'est pas connu et les solutions atteignent plusieurs centaines de mouvements. **Le plafond monte donc considérablement à chaque expansion**, ce qui allonge naturellement chaque époque. C'est ce qui donne au protocole son rythme : les premières époques sont courtes et fréquentes, les suivantes longues et rares. --- ## 13. La boucle complète ``` Un joueur veut améliorer son camp │ ▼ Il achète du $CUBE et paie un mouvement │ ├──► 30 % détruit ── offre réduite ├──► 30 % à la cagnotte ── enjeu qui grossit └──► 40 % aux camps ── dont ses adversaires │ ▼ Le cube bouge — 20 cases changent de camp │ ▼ Trois autres camps sont affectés │ ▼ Ils veulent riposter ──────────────────┐ │ │ ▼ │ La cagnotte grossit │ │ │ ▼ │ Elle dépasse le coût de résolution │ │ │ ▼ │ Quelqu'un résout ── cagnotte payée │ │ │ ▼ │ Le cube grandit ── nouvelle époque ────┘ ``` Trois entrées de $CUBE dans le système : acheter pour miser sur un camp, acheter pour payer des mouvements, et l'immobilisation permanente des mises. Une seule sortie : les parts réclamées et la cagnotte. Et une fuite permanente : la destruction, proportionnelle au conflit. --- # Partie IV — L'arc ## 14. La résolution ### 14.1 Condition Le cube est résolu lorsque les six faces ont leur score maximal simultanément. ``` score(X) = n² pour les six couleurs ``` ### 14.2 Qui peut résoudre N'importe qui. Il n'y a ni inscription, ni appartenance à un camp, ni autorisation. Un observateur extérieur qui n'a jamais joué peut arriver, payer la séquence complète et emporter la prime. ### 14.3 Répartition de la cagnotte | Destination | Part indicative | |---|---| | Auteur de la résolution | ~20 % | | Tous les camps, au prorata des mises pondérées dans le temps | ~70 % | | Détruit | ~10 % | **Pourquoi l'auteur ne prend pas tout.** S'il emportait la totalité, le jeu se réduirait à une course de robots au dernier coup, et tous ceux qui ont tenu une position pendant l'époque n'auraient rien. **Pourquoi il prend une part substantielle.** Il paie réellement la séquence — potentiellement des dizaines de mouvements au prix courant. Sans prime significative, personne ne résout, et la cagnotte gonfle indéfiniment sans jamais être libérée. **Pourquoi la pondération temporelle est indispensable.** Sans elle, il suffirait de miser massivement au bloc précédant la résolution pour capter la majeure partie de la cagnotte. La pondération sur une fenêtre longue rend cette manœuvre coûteuse et lente, donc visible. ### 14.4 Le vol de solution Une séquence de résolution soumise en clair est copiable : un observateur du mempool peut la reprendre à son compte et la soumettre avec une priorité supérieure. C'est un risque réel, il est traité par engagement chiffré (section 23). --- ## 15. L'expansion ### 15.1 Le mécanisme À chaque résolution, le cube passe à la taille impaire supérieure. ``` 3×3 → 5×5 → 7×7 → 9×9 → 11×11 → ... 54 150 294 486 726 ``` Le nouveau cube naît mélangé, et une nouvelle époque commence immédiatement. ### 15.2 Pourquoi c'est le meilleur élément du design **C'est un événement rare, anticipé, et daté par la progression** plutôt que par un calendrier. On ne promet pas une date : on affiche un écart qui se referme. C'est infiniment plus solide qu'une feuille de route. **Cela crée un historique.** « Le cube a été résolu quatre fois. Il est en 11×11. » Un projet qui accumule un passé vérifiable a quelque chose que la quasi-totalité des lancements n'ont pas. **Cela donne une raison réelle d'arriver tôt** — les premières époques sont courtes, bon marché, et les résolutions atteignables — sans qu'aucune promesse ne soit nécessaire. **Cela allonge naturellement les époques.** La longueur des solutions croît fortement avec la taille, donc chaque époque suivante est mécaniquement plus longue et plus chère. Le rythme se calme tout seul, sans intervention. ### 15.3 Ce qui change à chaque expansion | | Effet | |---|---| | Nombre de cases | Croît en `n²` | | Score maximal par face | Croît en `n²` | | Mouvements disponibles | Croît avec les tranches internes | | Longueur des solutions | Croît fortement | | Durée attendue de l'époque | Croît fortement | | Prix plancher du mouvement | Recalibré par formule sur `n` | ### 15.4 Ce qui ne change pas Les mises restent en place d'une époque à l'autre. Les camps persistent. Un joueur installé sur le rouge depuis la première époque reste sur le rouge. C'est ce qui donne du sens à la durée : **l'ancienneté d'un camp est une donnée publique, cumulée sur toute l'histoire du protocole.** --- ## 16. Les époques ### 16.1 Ce qu'est une époque La période entre deux résolutions. Chacune a sa taille de cube, sa cagnotte, son historique de mouvements et son auteur de résolution. ### 16.2 Le tableau d'histoire ``` Époque 1 3×3 résolu en 4 j 11 h cagnotte 18 400 par 0x7f2a… Époque 2 5×5 résolu en 12 j 03 h cagnotte 96 100 par 0x3b91… Époque 3 7×7 en cours — 6 j cagnotte 41 200 ``` Ce tableau est l'objet le plus précieux du protocole en communication. Il ne peut pas être fabriqué, il s'accumule tout seul, et il raconte l'histoire du projet mieux que n'importe quel document. ### 16.3 La propriété d'auto-relance C'est le mécanisme le plus important du design entier, et il mérite d'être compris précisément. Si l'activité chute, le prix du mouvement redescend (section 9). Le coût de résolution baisse donc mécaniquement, tandis que la cagnotte reste à son niveau. **L'écart se referme sans que personne n'ait rien fait.** Arrive un moment où résoudre devient nettement rentable. Quelqu'un le fait — n'importe qui, y compris un observateur extérieur. La cagnotte est distribuée, le cube grandit, une nouvelle époque commence avec un événement. Un jeu classique meurt lentement, avec un intérêt qui s'érode sans fin. **Ici, une période creuse produit mécaniquement un événement.** C'est ce qui remplace la nécessité d'animer en permanence, et c'est ce qui doit être protégé avant tout le reste lors du calibrage. --- # Partie V — Le token ## 17. Rôle du token ### 17.1 Les usages | Usage | Effet sur l'offre | |---|---| | **Seule monnaie des mouvements** | Une part détruite à chaque coup | | **Seul moyen de rejoindre un camp** | Immobilisée tant qu'on reste | | **Monnaie de la cagnotte** | Verrouillée pendant toute l'époque | | **Monnaie de la rémunération** | Redistribuée | ### 17.2 Le test On retire le token. Il ne reste rien : aucun mouvement possible, aucun camp, aucune cagnotte, aucune rémunération. Le cube devient une image fixe. Il n'existe pas de version du produit sans le token, et rien ne peut tourner avant son lancement. La contrainte est satisfaite au sens strict. ### 17.3 Les deux réducteurs d'offre **La destruction** est proportionnelle au conflit. Elle est visible, mesurable et cumulative. Mais elle ne se produit que s'il y a de l'activité. **L'immobilisation** est plus importante en pratique. La somme des mises sur les six camps, plus la cagnotte, représente du token qui ne peut pas être vendu. Sur une époque active, cet encours est le meilleur indicateur public de l'état réel du protocole : un seul chiffre, lisible on-chain, impossible à truquer. ### 17.4 Ce que la mécanique fait et ne fait pas Rendre le token obligatoire ne **crée** pas de demande. Cela **convertit** l'envie de jouer en demande de token. - Des gens jouent → il faut du token → pression acheteuse - Personne ne joue → aucune demande → la mécanique amplifie la baisse exactement autant qu'elle amplifierait la hausse Un document affirmant qu'une mécanique de destruction garantit une hausse est malhonnête, et sera lu comme tel par les seules personnes dont l'avis compte. --- ## 18. Distribution Le document ne fixe pas de chiffres — ils exigent une modélisation dédiée. Les contraintes structurelles sont indépendantes des chiffres. - **Aucune part des flux à l'équipe.** L'allocation d'équipe, si elle existe, provient de l'offre initiale, est vestée sur plusieurs années, et annoncée avant le lancement. - **Une allocation nulle n'est pas un bon signal.** Elle suggère un portefeuille dissimulé ou une équipe qui partira. Une allocation faible, vestée et visible est plus crédible que zéro. - **La liquidité initiale est verrouillée**, et c'est vérifiable dans le contrat. - **Une réserve d'amorçage de cagnotte** est justifiable : sans elle, la cagnotte de la première époque part de zéro et le premier jour n'a aucun enjeu. Cette réserve doit être annoncée, plafonnée et non renouvelable. - **Le flottant du premier jour détermine tout :** ``` Valorisation totale au jour J = montant levé ÷ part d'offre vendue ``` Un flottant trop mince produit une valorisation affichée élevée qu'un seul vendeur suffit à diviser par deux. C'est le mode d'échec le plus fréquent des lancements, indépendamment de la qualité du produit. --- ## 19. Le jour J ### 19.1 Séquence 1. **Vente à prix unique.** Tout le monde au même prix, aucun sniping possible par construction. Le montant levé devient la liquidité, verrouillée. 2. **Le cube naît mélangé** dans la même transaction que la clôture de la vente. 3. **Les camps ouvrent immédiatement.** Le premier usage possible du token est de rejoindre une couleur. 4. **Le premier mouvement est jouable dans la minute.** La cagnotte commence à se remplir. 5. **Les premières réclamations sont possibles le jour même.** ### 19.2 Ce qu'il faut avoir préparé - **La visualisation 3D en direct**, avant tout le reste. C'est le produit. Un cube qui ne s'anime pas à chaque coup n'a aucun intérêt. - **Le robot de publication** opérationnel dès le premier bloc. - **Une réserve d'amorçage de cagnotte**, sans quoi il n'y a aucun enjeu le premier jour. - **Quelques joueurs par couleur**, prêts à occuper les six camps. Un cube où cinq camps sont vides n'est pas un jeu. ### 19.3 Ce qu'il ne faut pas faire - Annoncer une date avant que les contrats soient déployés et vérifiés. - Afficher un rendement, un APR, ou une projection de prix. - Promettre une date de résolution : c'est l'écart cagnotte/coût qui parle, pas un calendrier. --- # Partie VI — Technique ## 20. Représentation de l'état ### 20.1 Encodage Chaque case tient sur 3 bits (six couleurs, valeurs 0 à 5). | Taille | Cases | Bits | Slots de 256 bits | |---|---|---|---| | 3×3 | 54 | 162 | **1** | | 5×5 | 150 | 450 | 2 | | 7×7 | 294 | 882 | 4 | | 9×9 | 486 | 1 458 | 6 | **L'état complet d'un cube 3×3 tient dans un seul mot de stockage.** C'est une propriété rare et très favorable : lire ou écrire l'état entier coûte une seule opération de stockage. ### 20.2 Indexation Les cases sont numérotées face par face, en lecture ligne par ligne : ``` index = face × n² + ligne × n + colonne ``` Cet ordre est figé pour toute la vie du protocole. Toutes les tables de permutation en dépendent. ### 20.3 Scores mis à jour de façon incrémentale Recalculer les six scores en parcourant toutes les cases après chaque mouvement est inutilement coûteux. Un mouvement ne déplace qu'un nombre restreint de cases — 20 sur un 3×3. Il suffit donc de recalculer le delta sur les cases effectivement déplacées : ``` pour chaque case déplacée : si elle était chez elle avant → score de son ancienne face −1 si elle est chez elle après → score de sa nouvelle face +1 ``` Les six scores tiennent dans un seul mot supplémentaire. --- ## 21. Les permutations ### 21.1 Nature d'un mouvement Un quart de tour d'une face est une **permutation fixe des indices**, identique quel que soit l'état du cube. Elle se décompose en cycles de longueur 4. Sur un 3×3, un quart de tour comprend : - 2 cycles de 4 parmi les 8 cases non centrales de la face tournée - 3 cycles de 4 parmi les cases des quatre faces adjacentes Soit **5 cycles de 4, donc 20 cases déplacées**. Le centre ne bouge pas. ### 21.2 Implémentation Les permutations sont des constantes en mémoire de code, jamais en stockage : ```solidity // 5 cycles de 4 indices, pour chacune des 6 faces uint8[4][5][6] internal constant CYCLES_3 = [ /* ... */ ]; function applyQuarter(uint256 state, uint8 face) internal pure returns (uint256) { for (uint256 c; c < 5; ++c) { uint8[4] memory cy = CYCLES_3[face][c]; uint8 tmp = _get(state, cy[3]); state = _set(state, cy[3], _get(state, cy[2])); state = _set(state, cy[2], _get(state, cy[1])); state = _set(state, cy[1], _get(state, cy[0])); state = _set(state, cy[0], tmp); } return state; } ``` Un demi-tour est deux quarts de tour ; un quart antihoraire, trois. On ne stocke qu'une table par face. Les tables doivent être **générées puis vérifiées par un test exhaustif**, pas écrites à la main. Le test de référence : appliquer quatre quarts de tour de la même face ramène exactement à l'état initial, pour toutes les faces et depuis un état aléatoire. Une erreur d'un seul indice dans une table est indétectable à l'œil et fausse tout le protocole. ### 21.3 Vérification de résolution ```solidity function isSolved(uint256 state, uint8 n) internal pure returns (bool) { for (uint8 f; f < 6; ++f) { uint8 center = _get(state, f * n * n + (n * n) / 2); for (uint8 i; i < n * n; ++i) { if (_get(state, f * n * n + i) != center) return false; } } return true; } ``` En pratique, la vérification se fait par comparaison des six scores à `n²`, qui sont déjà tenus à jour. --- ## 22. Architecture des contrats | Contrat | Responsabilité | Immuable | |---|---|---| | `CubeState` | État, permutations, scores, vérification de résolution | Oui | | `Game` | Mouvements, tarification dynamique, répartition | Oui | | `Camps` | Mises, délai de sortie, pondération temporelle, réclamations | Oui | | `Pot` | Cagnotte, engagement chiffré, versement | Oui | | `Epochs` | Expansion, recalibrage, historique | Oui | ### 22.1 Principes non négociables - **Immuabilité totale.** Pas de proxy, pas de mise à jour, pas de pause. Sur un protocole aussi court, l'absence de clé est vérifiable en trente secondes et vaut mieux que toute promesse de gouvernance. - **Aucun paramètre modifiable par une adresse.** Prix plancher, parts de répartition, délais, fenêtres de pondération : tout est constant. - **Retrait, jamais distribution.** Aucune boucle de paiement. - **Comptabilité interne.** Les soldes ne se lisent jamais via `balanceOf`, sinon un simple envoi direct au contrat fausse la comptabilité. - **Séparation des caisses.** Mises, cagnotte et rémunérations en attente sont comptabilisées séparément. Aucun chemin de code ne doit permettre de servir l'une avec les fonds d'une autre. ### 22.2 Contrainte sur le token Le $CUBE ne doit comporter **aucun prélèvement au transfert, aucun rebasement, aucune liste noire, aucune fonction de pause.** Un prélèvement au transfert casserait immédiatement la comptabilité des mises et de la cagnotte. Cette contrainte est à graver dans le contrat du token lui-même. --- ## 23. Engagement chiffré sur la résolution ### 23.1 Le problème Une séquence de résolution visible dans le mempool peut être copiée et resoumise avec une priorité supérieure. Celui qui a fait le travail — et éventuellement acheté du temps de calcul pour trouver une solution courte — se fait prendre la prime. ### 23.2 Le mécanisme **Étape 1 — engagement.** Le joueur soumet `keccak256(séquence, sel, son adresse, état actuel du cube)` avec un petit dépôt. Rien n'est lisible. **Étape 2 — exécution.** Après un délai minimal et dans une fenêtre limitée, il révèle la séquence. Le contrat vérifie la correspondance, applique la séquence, prélève le prix des mouvements, et verse la prime si le cube est résolu. ### 23.3 Détails qui comptent **L'engagement inclut l'état du cube au moment de l'engagement.** Si quelqu'un joue entre-temps, la séquence ne correspond plus à l'état et l'exécution échoue. C'est le risque assumé par le solveur, et c'est ce qui rend la course intéressante : plus on attend pour être sûr, plus on risque d'être doublé. **Le délai minimal entre engagement et exécution** empêche de faire les deux dans le même bloc, ce qui annulerait la protection. **Le dépôt d'engagement est perdu si l'exécution n'a pas lieu**, sans quoi il serait gratuit de spammer des engagements pour bloquer les autres. **Plusieurs engagements peuvent coexister.** Le premier à exécuter avec succès emporte la prime. Il n'y a pas de réservation exclusive, ce qui éviterait un blocage volontaire. --- ## 24. Invariants | # | Invariant | |---|---| | **I1** | Le multiensemble des couleurs est conservé par tout mouvement : exactement `n²` cases de chaque couleur, en permanence | | **I2** | Quatre quarts de tour d'une même face ramènent à l'état initial | | **I3** | Les scores stockés sont toujours égaux aux scores recalculés depuis l'état | | **I4** | La somme des scores est comprise entre 6 et `6n²` | | **I5** | Tourner une face ne modifie ni son score ni celui de la face opposée | | **I6** | Le total des mises comptabilisées est égal au solde de la caisse des camps | | **I7** | La somme des rémunérations réclamables n'excède jamais la caisse correspondante | | **I8** | La cagnotte ne peut décroître que par une résolution valide | | **I9** | Aucune séquence d'opérations ne permet de retirer plus de token qu'on n'en a déposé, hors rémunérations et cagnotte | | **I10** | Un état résolu déclenche toujours la fin d'époque, sans exception ni chemin de contournement | **I1 et I3 se testent par fuzzing sur séquences aléatoires longues.** Ce sont les deux invariants critiques : une erreur dans une table de permutation corrompt le premier, une erreur de mise à jour incrémentale corrompt le second, et aucun des deux n'est visible à l'œil. --- ## 25. Sécurité ### 25.1 Niveau état | Vecteur | Traitement | |---|---| | Erreur dans une table de permutation | Génération automatique + test exhaustif (I1, I2) | | Dérive du score incrémental | Vérification croisée périodique (I3) | | Mélange initial prévisible | Aléa non dérivable d'un hash de bloc | | Débordement d'index sur cube étendu | Bornes explicites par taille | ### 25.2 Niveau économique | Vecteur | Traitement | |---|---| | Inondation de mouvements | Prix dynamique croissant, jamais de limite par adresse | | Entrée juste avant une distribution | Pondération temporelle des mises | | Sortie juste après un gain | Délai de sortie | | Bascule vers le camp qui monte | Délai de changement de couleur | | Nuisance pure — brouiller sans miser | Coûteux et sans gain : le nuisible paie et n'encaisse rien. Autolimité. | | Vol de séquence de résolution | Engagement chiffré (section 23) | | Accaparement de la cagnotte par mise tardive | Pondération sur fenêtre longue | ### 25.3 Le vecteur qui n'est pas résolu **Un acteur suffisamment capitalisé peut exploiter une époque entière.** En prenant une position majoritaire sur plusieurs camps, il récupère la majeure partie de ce qu'il paie en mouvements. Son coût net se réduit à la part détruite et à la part revenant aux autres. Il peut alors piloter le cube et déclencher la résolution au moment qui l'arrange. Ce qui limite l'attaque, sans l'empêcher : - **La part détruite est irrécupérable.** Chaque mouvement lui coûte réellement. - **La pondération temporelle** l'oblige à immobiliser du capital longtemps avant, ce qui est lent et visible. - **L'accumulation est publique.** Les mises par couleur sont lisibles en permanence, donc l'accaparement se voit venir. - **Les autres peuvent réagir** en misant sur les camps délaissés, qui deviennent alors très rémunérateurs par tête. Cette limite doit être écrite dans la documentation publique. La dissimuler serait à la fois malhonnête et inutile : elle est évidente pour quiconque lit le mécanisme. ### 25.4 Vecteurs classiques Réentrance sur toute sortie de fonds ; arrondis systématiquement en faveur du protocole et vérifiés par fuzzing ; bornage explicite de la longueur des séquences soumises ; blocage par adresse refusant de recevoir, évité par le modèle en réclamation ; attaque par donation, évitée par comptabilité interne. --- # Partie VII — Réalité ## 26. Théorie des jeux ### 26.1 Le dilemme central Le score total n'est pas constant (section 6.3). Cela signifie que les joueurs peuvent collectivement créer ou détruire de la position. | Comportement collectif | Ordre total | Rémunération globale | |---|---|---| | Tous coopèrent | Élevé | Élevée, mais l'époque se termine vite | | Tous se combattent | Bas | Basse, et l'époque s'éternise | | Certains coopèrent | Intermédiaire | Ceux qui coopèrent financent les autres | C'est un dilemme du prisonnier étendu à six joueurs, avec une particularité : **la défection n'est pas gratuite.** Chaque coup de brouillage alimente la cagnotte, donc rapproche la fin de l'époque, donc réduit la durée pendant laquelle le défecteur profitera de sa position. ### 26.2 Les deux camps qui émergent Ils ne sont pas définis par le protocole ; ils apparaissent tout seuls. **Les rentiers** ont un bon score et encaissent. Ils veulent retarder la résolution. Mais chaque coup qu'ils jouent pour brouiller finance la cagnotte. **Les solveurs** visent la prime. Ils veulent que le cube approche de l'ordre. Ils sont d'autant plus motivés que la cagnotte est grosse — c'est-à-dire d'autant plus que les rentiers se sont battus. **Chaque camp nourrit l'autre.** Il n'y a rien à équilibrer par paramètre. ### 26.3 Absence de stratégie dominante simple Trois raisons structurelles : - **Aucun coup gratuit** (section 7.2) : tout mouvement qui m'améliore affecte trois autres camps. - **Intentions cachées** : on voit les mises et l'état, mais pas ce que les autres vont jouer. - **Espace d'états immense** : même sur un 3×3, il y a plus de 43 trillions de positions. Un robot peut calculer la résolution optimale, mais il ne peut pas calculer **quand engager du capital face à cinq adversaires humains aux intentions inconnues.** Le calcul ne suffit pas ; c'est une décision de capital et de moment. ### 26.4 Ce que font les robots Ils viendront, et c'est souhaitable. Ils : - arbitreront les coups sous-évalués, ce qui fait le volume et donc la destruction - maintiendront le cube vivant 24 heures sur 24 sans intervention humaine - se disputeront les résolutions, ce qui garantit que la cagnotte est toujours libérée Le risque réel est qu'ils rendent le jeu inintéressant pour un humain. Deux amortisseurs : le prix dynamique, qui rend le spam coûteux, et le fait que **détenir une position n'exige aucune réactivité** — un joueur passif peut simplement miser et encaisser sans jamais jouer un coup. --- ## 27. Paramètres à calibrer | Paramètre | Trop bas | Trop haut | |---|---|---| | Prix plancher du mouvement | Spam, cube illisible | Personne ne joue | | Vitesse d'ajustement du prix | Pas d'effet anti-spam | Prix erratique | | Part détruite | Sink insuffisant | Jeu trop coûteux | | Part cagnotte | Enjeu faible, époques molles | Peu de rémunération courante | | Part camps | Aucun intérêt à miser | Cagnotte anémique | | Prime de résolution | Personne ne résout | Course de robots au dernier coup | | Délai de sortie | Bascule opportuniste | Position perçue comme piégée | | Fenêtre de pondération | Accaparement tardif possible | Nouveaux joueurs découragés | | Amorçage de cagnotte | Premier jour sans enjeu | Subvention farmable | ### 27.1 Le calibrage critique Le rapport entre **part cagnotte** et **prix du mouvement** détermine à lui seul la durée moyenne d'une époque, puisqu'il fixe la vitesse à laquelle la cagnotte rattrape le coût de résolution. C'est le paramètre qui décide du rythme entier du protocole, et il doit être simulé sur plusieurs scénarios d'activité — forte, moyenne, quasi nulle — avant d'être figé. Une fois les contrats déployés, il ne sera plus modifiable. **Cible raisonnable pour la première époque : quelques jours.** Assez court pour que la première résolution arrive vite et prouve que le cycle fonctionne. Assez long pour que la tension monte. --- ## 28. Ce qui peut mal tourner ### 28.1 Personne ne joue Le risque principal, et il n'a pas de parade mécanique complète. Sans mouvements, il n'y a ni destruction, ni cagnotte, ni rémunération. Le cube devient une image fixe. **Ce qui amortit :** le prix baisse automatiquement, donc résoudre devient bon marché, donc quelqu'un finit par emporter la cagnotte accumulée et une nouvelle époque démarre avec un événement. Le protocole ne meurt pas silencieusement ; il produit au moins un dernier temps fort. ### 28.2 Les robots vident le jeu Ils domineront les résolutions et l'arbitrage. Un humain ne peut pas rivaliser sur la vitesse. **Ce qui amortit :** miser ne demande aucune réactivité. Le jeu reste jouable pour un humain en tant que position, pas en tant que réflexe. ### 28.3 Un seul acteur accapare Voir 25.3. Non résolu, seulement rendu lent, coûteux et visible. ### 28.4 Le cube est trop dur ou trop facile Une première époque qui dure une heure ne raconte rien. Une qui dure six mois épuise l'attention. C'est un problème de calibrage, et il n'est corrigeable qu'à la génération suivante puisque les contrats sont immuables — d'où l'importance de la simulation préalable. ### 28.5 Personne ne comprend Le mécanisme complet exige un effort. Le raccourci utilisable est : *six couleurs, tu en choisis une, tu paies pour la faire monter, les autres peuvent la faire redescendre.* Si l'interface n'arrive pas à faire tenir cela en une image et trois chiffres, le reste ne sert à rien. ### 28.6 Réglementaire C'est un jeu à enjeu, où l'on engage de l'argent avec un résultat incertain dépendant en partie du comportement d'autrui. Selon les juridictions, cela peut relever de la réglementation des jeux d'argent. Conséquences : géo-blocage, conditions d'utilisation explicites, aucun affichage de rendement, aucun ciblage de juridictions restrictives. Et la conséquence stratégique déjà connue : **aucun acteur régulé ne relaiera publiquement ce produit.** ### 28.7 L'accusation de jeu à somme négative Elle est fondée (section 2). La seule réponse tenable est de l'avoir écrit soi-même, en clair, avant qu'on ne le découvre. Un projet qui l'assume dès sa documentation est infiniment plus solide qu'un projet qui se fait démonter dessus la deuxième semaine. --- ## 29. Phasage **Phase 0 — Simulation.** Modéliser la durée d'époque selon plusieurs profils d'activité et fixer les paramètres. Aucun code de production. C'est un point de décision réel : si la durée d'époque est ingérable dans tous les scénarios, le design doit changer. **Phase 1 — Le moteur d'état.** `CubeState` seul : permutations, scores, résolution. Génération automatique des tables et test exhaustif. C'est ici que se trouve l'essentiel du risque de correction, et c'est court. **Phase 2 — Le jeu.** Mouvements, tarification dynamique, répartition, camps, cagnotte. Tests d'invariants par fuzzing, en priorité I1, I3 et I9. **Phase 3 — La visualisation.** Cube 3D en direct, animation à chaque coup, historique, intégration ailleurs. **C'est le produit**, pas un habillage. À traiter avec au moins autant de sérieux que les contrats. **Phase 4 — Testnet public.** Une époque complète jouée en conditions réelles, avec des joueurs, jusqu'à la résolution et l'expansion. Non négociable : c'est la seule façon de vérifier le calibrage avant de le figer. **Phase 5 — Lancement.** Vente, cube mélangé, camps ouverts, premier mouvement dans la minute. --- ## 30. Communication ### 30.1 Ce que le protocole produit tout seul Un robot qui publie automatiquement : ``` Coup joué par 0x4a1c… — face bleue, quart horaire 🔵 4→7 🟢 6→4 🟡 3→3 ⚪ 5→4 Cagnotte 41 380 (+180) ``` Chaque coup est un événement, chaque résolution est un temps fort. **C'est du contenu infini qui ne demande aucune rédaction**, et c'est la seule ressource de croissance dont dispose un projet sans flux extérieur. ### 30.2 Les trois objets partageables - **L'image du cube** — reconnaissable partout dans le monde, sans traduction. - **L'écart cagnotte / coût de résolution** — un compte à rebours qui n'a pas besoin de date. - **Le tableau d'histoire des époques** — impossible à fabriquer, s'accumule tout seul. ### 30.3 La phrase > **Un seul Rubik's cube. Six camps. Tout le monde peut le tourner.** Ce qui vient après est du détail. Si cette phrase ne suffit pas à faire cliquer, aucune explication supplémentaire ne le fera. ### 30.4 Ce qu'il ne faut jamais écrire « Rendement », « APR », « passif », « garanti », « protocole DeFi ». Chacun de ces mots est faux ici, et chacun sera relevé. --- ## 31. Questions ouvertes 1. **Faut-il des tokens de couleur échangeables** plutôt que de simples mises ? Cela donnerait six graphiques et une expérience plus proche du trading, au prix d'une couche réflexive où le prix diverge du score. Écarté en v1, réexaminable. 2. **La prime de résolution doit-elle être fixe ou proportionnelle à la cagnotte ?** Une prime proportionnelle rend la résolution toujours attractive ; une prime fixe permet à la cagnotte de grossir davantage avant d'être prise. 3. **Faut-il autoriser plusieurs cubes simultanés** — un launchpad de cubes ? Cela dilue l'attention, qui est l'unique ressource, mais crée un flux de créations. Probablement non. 4. **La taille doit-elle croître à chaque résolution, ou une époque sur deux ?** La croissance en `n²` est rapide et pourrait rendre les époques trop longues trop vite. 5. **Que se passe-t-il si personne ne résout pendant très longtemps ?** Faut-il une baisse programmée du prix du mouvement au-delà d'un certain délai, pour garantir la relance ? Cela renforce l'auto-relance mais ajoute un paramètre temporel. 6. **La pondération temporelle doit-elle s'appliquer aussi à la rémunération courante**, ou seulement au partage de la cagnotte ? 7. **Faut-il un mode coopératif explicite** — un mécanisme permettant à des camps de s'engager à ne pas se nuire pendant N blocs ? Cela rendrait la propriété de coordination jouable au lieu d'être seulement théorique. --- ## 32. Glossaire **Cagnotte** — Part accumulée des mouvements, verrouillée, libérée uniquement par une résolution complète. **Camp** — Ensemble des joueurs ayant misé sur une même couleur. **Case** — Une facette du cube. Un cube de taille `n` en compte `6n²`. **Engagement chiffré** — Soumission du hash d'une séquence de résolution avant sa révélation, empêchant sa copie dans le mempool. **Époque** — Période entre deux résolutions. Chacune a sa taille de cube et sa cagnotte. **Expansion** — Passage à la taille impaire supérieure après une résolution. **Nombre de Dieu** — Nombre maximal de mouvements nécessaires pour résoudre n'importe quelle position. Vaut 20 pour un 3×3 ; inconnu au-delà. **Pondération temporelle** — Prise en compte de la durée de la mise et non de son montant instantané, pour empêcher l'entrée opportuniste. **Score d'une face** — Nombre de cases de la bonne couleur actuellement présentes sur cette face. **Score total** — Somme des six scores. Non constant : mesure l'ordre global du cube. **Tarification de congestion** — Prix du mouvement qui monte avec l'activité récente et redescend en période calme. --- ## Annexe A — Les dix décisions qui définissent le protocole 1. **C'est un jeu à enjeu, pas un protocole financier.** L'écrire soi-même, en premier. 2. **Cubes de taille impaire uniquement.** Sans centre fixe, l'identité des faces est ambiguë et la notion de camp s'effondre. 3. **Tourner une face ne change pas son propre score.** C'est ce qui interdit tout coup gratuit et donne sa profondeur au jeu. 4. **La cagnotte n'est libérée que par une résolution complète**, et l'écart avec le coût de résolution est le compte à rebours public du protocole. 5. **Le prix du mouvement est dynamique.** C'est la seule protection anti-spam qui ne se contourne pas par multiplication d'adresses. 6. **Pondération temporelle partout.** Sans elle, tout se capte au dernier bloc. 7. **Séquences atomiques et engagement chiffré.** Sans les deux, résoudre est impossible en pratique. 8. **Expansion à chaque résolution.** C'est ce qui donne un arc, un historique, et une raison d'arriver tôt. 9. **Le prix baisse quand personne ne joue.** C'est la propriété d'auto-relance, et c'est le mécanisme le plus important du design. 10. **Zéro flux à l'équipe, immuabilité totale.** Les deux seules choses vérifiables en trente secondes, donc les deux seules qui comptent. --- ## Annexe B — Ce que ce document ne résout pas Par honnêteté, et parce que ces points seront soulevés : - **Aucun revenu extérieur.** L'économie est fermée et à somme négative après destruction. - **Un acteur très capitalisé peut exploiter une époque.** Rendu lent, coûteux et visible, pas empêché. - **Les robots domineront l'exécution.** Amorti par le fait que miser ne demande aucune réactivité. - **La durée d'époque n'est calibrable qu'avant le déploiement**, puisque les contrats sont immuables. - **Le produit dépend entièrement de l'attention.** Sans regard, un cube ne vaut rien — contrairement à un protocole adossé à une activité qui existerait sans lui.