Cage Calls : quatorze mois de production on-chain, combat après combat
Cage Calls est le marché de prédiction d’Armored MMA. Les fans votent gratuitement sur l’issue de chaque combat et repartent avec des Relics, les NFT qui composent l’archive on-chain des victoires de la ligue. Depuis juillet 2025, on construit et on opère toute la couche on-chain : les contrats Cairo, le SDK, l’application de marché et l’appchain qui porte l’ensemble.
L’étude de cas détaille le produit et ses mécaniques. Cet article raconte l’autre moitié : ce que ça change de livrer quand la date de mise en production est celle d’un combat, devant un public, et ce qu’on a mis en place pour que ça tienne.
La contrainte qui décide de tout
Un produit web classique se déploie quand il est prêt. Ici, les combats ont lieu à date fixe. Chaque montée de version est calée sur une soirée, et un chemin de lecture cassé pendant le combat principal ne se rattrape pas après coup : les votes se ferment au troisième round, l’oracle tranche, les Relics sont frappés. Si la chaîne ou l’indexeur répondent mal à ce moment-là, la soirée est perdue pour les joueurs.
Cette contrainte a orienté presque tous nos choix techniques. Pas parce que la blockchain est fragile, mais parce que le calendrier ne pardonne pas.
Un seul point de lecture : le SDK
Deux applications lisent la chaîne : l’app mobile d’Armored MMA, développée par les équipes de Medieval Tech, et l’application de marché que nous avons construite. Sans point de lecture commun, deux clients finissent toujours par diverger sur l’état d’un marché ou d’un Relic.
On a donc extrait un SDK TypeScript publié, par lequel tout le monde passe. Il lit d’abord l’indexeur et se replie sur le RPC si besoin. Il expose des presets réseau, des hooks React, des séries de cotes dérivées de l’historique des achats et des portefeuilles vus du joueur. Onze versions sont sorties en trois semaines, le temps de stabiliser l’interface. Une vérification automatique casse la CI si l’app lit la chaîne en contournant le SDK.
Ce paquet est aussi la frontière entre les deux équipes. Medieval Tech tient le mobile, le backend et l’administration. Nous tenons tout ce qui est on-chain. Le SDK est l’endroit où on se serre la main.
Rapatrier la chaîne
En juillet 2026, le testnet hébergé qu’on utilisait a cessé d’être maintenu. On aurait pu attendre la roadmap d’un tiers. On a préféré rapatrier la chaîne : Katana et Torii auto-hébergés sur AWS, avec un chain ID dédié, un paymaster épinglé et un sidecar VRF pour l’aléa du gacha. Quelques jours après la décision, les six environnements, du dev au mainnet, étaient de nouveau alignés.
Au passage, on a écrit un harnais de charge qui rejoue le vrai schéma de lecture de l’app mobile, et le déploiement de l’indexeur est passé en blue/green en production. Redimensionner tient en une commande.
Trois portes avant de toucher mainnet
Avant le premier déploiement mainnet, un audit de sécurité interne avait remonté onze points, dont deux critiques, tous fermés avant la mise en production. Depuis, deux montées de version sont parties sur mainnet en août 2026 : une passe sur les performances de lecture, puis un mécanisme de paiement à cotes verrouillées avec tirage bonus VRF. Les deux ont suivi le même runbook, et l’ordre compte.
- Prouver à vide. Suite de tests complète (324 tests sur 12 suites), comparaison statique avec les classes déployées, et une vérification on-chain qui doit répondre « ready ». Aucune écriture tant que cette porte n’est pas verte.
- Exécuter par script. Un script idempotent par montée de version, lancé depuis un keystore matériel, avec le hash de classe précédent conservé comme paire de rollback.
- Vérifier et consigner. On rejoue la même vérification jusqu’à « already-applied », on confirme les hashes via RPC, puis on commit le manifest. Le prochain ingénieur hérite de la vérité, pas d’un souvenir.
Aucun rollback n’a été nécessaire sur ces deux montées de version.
Le gas qui ne doit jamais manquer
Les joueurs viennent du web2. Au premier vote, un Controller Cartridge se crée tout seul, avec clés de session et paymaster. Ils ne voient jamais passer une transaction. Cette promesse ne tient que si le gas ne s’épuise pas, y compris au milieu d’une soirée de combats.
On a donc livré une console paymaster sur mainnet : recharge de slot, et une alarme quand le budget descend sous un seuil. Les alertes ont été réécrites pour être actionnables, et la dérive de configuration entre staging et production a été auditée puis éliminée.
Où on en est
Fin août 2026, les chiffres officiels de la ligue :
- 1 540 wallets uniques, créés au premier vote
- 22 786 pronostics enregistrés on-chain
- 37 % des Relics gagnés déjà réclamés
- 0 incident de sécurité, aucun fonds perdu
D’un événement au suivant, votes et utilisateurs progressent de 25 %, et plus de 35 % des joueurs reviennent d’une soirée à l’autre. Pour un produit gratuit, sur une chaîne que la plupart des fans n’avaient jamais utilisée.
Une deuxième ligue est prête à signer, sur les mêmes contrats.
Ce qu’on retient
La partie visible de Cage Calls, ce sont les Relics et le gacha. La partie qui fait tenir le produit, c’est un SDK que personne ne contourne, une chaîne qu’on contrôle, et un runbook qu’on suit même quand on est pressé. Si vous préparez un produit on-chain avec un calendrier qui ne bouge pas, c’est par là qu’on commencerait.