Moteur de Staking Whitepaper v1.0
Le Moteur de Staking BlazePhoenix est un coffre mono-actif et une facilité de crédit pour le BZPX sans aucun oracle, parce que la garantie et la dette sont le même token. L’Identité Maîtresse de Conservation (Master Conservation Identity) est imposée à chaque transaction qui déplace de la valeur par le modificateur conserves — une transaction qui laisserait le registre revendiquer plus que ce que le contrat détient est annulée. L’émission est divisée par deux sur huit périodes de deux ans (eight two-year periods), sous forme close sur l’horloge des blocs ; un boost quadratique rémunère l’engagement de blocage jusqu’à 2.75× à sept ans ; deux accumulateurs disjoints versent l’émission et les intérêts des emprunteurs sans aucune subvention croisée ; la maintenance voyage dans les transactions ordinaires, bornée en gas ; et n’importe qui sur terre peut déclencher le coupe-circuit avec une preuve on-chain d’insolvabilité. La conception repose sur une discipline, partagée avec l’agrégateur BlazePhoenix et appliquée ici au capital du protocole lui-même : calculer, ne pas faire confiance. Chaque rendement, chaque taux et chaque contrôle de solvabilité découlent de l’état de la chaîne par une arithmétique qu’un lecteur peut refaire — aucun flux de prix, aucune flotte de keepers, aucun tableau de bord auquel il faudrait croire. Trois limites sont énoncées d’emblée, car une garantie ne vaut que par l’honnêteté de ses bords. Le moteur est en construction — l’avertissement ci-dessus, et non une note de bas de page. Des rôles administratifs existent, et chacun est énuméré avec la ligne qui le borne : un admin dont les pouvoirs de déplacement de valeur n’atteignent pas le principal des stakers (§10.3), et un gardien dont le pouvoir le plus fort ne déplace aucun fonds (§12). Et le blocage n’est pas inconditionnel : deux voies d’arrêt existent, délibérément dissemblables, chacune spécifiée intégralement et dont la provenance est consignée de façon permanente (§12). Ce qu’un lecteur doit évaluer, ce n’est pas notre honnêteté mais notre source.
Statut : le moteur est en construction
L’agrégateur de liquidité BlazePhoenix est le produit en production. Le moteur de staking n’est pas en production : il est en cours d’ingénierie active. Ce document spécifie la conception du moteur de staking telle qu’elle est — chaque équation, invariant, constante et point d’entrée nommé ci-dessous constitue la spécification à laquelle l’implémentation est tenue — afin qu’un lecteur puisse évaluer le moteur avant qu’il n’existe. Publier d’abord la conception est le bon ordre des opérations pour un logiciel immuable : un contrat qui ne peut être corrigé doit être jugé avant d’être déployé, non après, et ce document est bâti pour rendre ce jugement possible — chaque nombre re-dérivable, chaque garantie énoncée avec son point d’application et sa limite dans le même paragraphe. Lorsque le moteur sera livré, le bytecode déployé deviendra canonique et ce document en deviendra l’archive ; d’ici là, le document est l’affirmation publique et falsifiable du moteur sur ce qu’il sera. Texte intégral, en anglais : https://blazephoenix.xyz/staking-whitepaper.md
§1 · Une discipline, deux moteurs
BlazePhoenix est un protocole financier on-chain complet, bâti à partir de deux moteurs imbriqués — un agrégateur de liquidité et un moteur de staking — qui partagent une discipline : calculer, ne pas faire confiance. Chaque prix, chaque rendement et chaque contrôle de solvabilité du protocole découlent de l’état de la chaîne par une arithmétique qu’un lecteur peut refaire. Aucun service de routage, aucun oracle de prix, aucun keeper, aucune voie de mise à niveau : là où la plupart des protocoles demandent qu’on les croie, celui-ci publie les moyens de le vérifier.
§2 · La thèse du staking et l’Identité Maîtresse de Conservation
Un agrégateur route la liquidité des autres ; un protocole doit aussi cultiver la sienne. Le Moteur de Staking BlazePhoenix transforme le BZPX d’un solde statique en capital productif — un instrument de rendement, une ligne de crédit collatéralisée et le mécanisme d’alignement qui lie les détenteurs de long terme au succès du protocole — et il fait tout cela dans un seul contrat, gouverné par une seule équation.
§3 · Le token et le calendrier d’émission
Un milliard de BZPX, fixé pour toujours, sous la forme d’un ERC-20 ordinaire : 18 décimales, aucune voie d’émission, aucun frais au transfert, aucun rebasing, aucun hook de transfert, ni pause ni liste noire — les six invariants de déploiement consignés dans le dépôt de staking, vérifiés contre le bytecode du token au moment du câblage. L’offre entièrement diluée est connue dès la genèse ; la rareté est une propriété du contrat, non une politique. La répartition du milliard entre les allocations du protocole est un enregistrement au niveau du protocole et figure avec le document compagnon et l’enregistrement on-chain du token lui-même ; ce document porte la part que le moteur impose — le budget d’émission
§4 · Staking bloqué obligatoire et la courbe de boost
En clair : il n’y a pas de staking liquide — chaque dépôt engage son capital pour une durée choisie, et le protocole se contente d’honorer la durée. Précisément :
§5 · La Doctrine du Double Accumulateur (Dual-Accumulator Doctrine)
Le Moteur verse deux rendements distincts à partir de deux sources disjointes, et un staker en gagne un ou les deux selon qu’il emprunte ou non. C’est la partie la plus subtile de la conception et la raison pour laquelle un seul contrat peut servir épargnants et emprunteurs sans que l’un subventionne l’autre. La comptabilité suit le schéma d’accumulateur éprouvé dans tout le DeFi : un index global par part avance à mesure que la valeur arrive, chaque position mémorise l’index de son dernier règlement, et le rendement en attente est la différence multipliée par le poids de la position. Les deux accumulateurs avancent sur la même horloge — _updateGlobal s’exécute en premier à chaque point d’entrée,
§6 · La facilité de crédit
Les protocoles de prêt cassent bien plus souvent à l’oracle qu’aux mathématiques : un flux manipulé fait paraître sans valeur une garantie saine — ou saine une garantie sans valeur — et la logique de liquidation, si correcte soit-elle, s’exécute sur un mensonge. BlazePhoenix ne durcit pas l’oracle ; il supprime la catégorie. L’actif remis en garantie et l’actif emprunté sont le même token : un staker bloque du BZPX et emprunte du BZPX contre lui, si bien que le ratio prêt/valeur d’une position est un pur rapport entre deux quantités d’un même token — la dette sur le stake — et n’exige aucun prix externe pour être évalué. Il n’y a pas de flux à manipuler, pas de fenêtre de TWAP
§7 · Liquidation
Une position devient liquidable lorsque les intérêts courus ont érodé son stake jusqu’à 5% de sa dette — la garantie en une phrase : une position peut être liquidée exactement quand debt × 100 ≥ stake × 95, vérifié à l’identique sur la voie sans permission et sur la voie autonome, et pas un bloc plus tôt. La saisie exécute alors une cascade fixe :
§8 · Maintenance Autonome (Autonomous Maintenance)
Les liquidations doivent être ponctuelles, les intérêts doivent être accumulés et les boosts de blocage expirés doivent être libérés — et la réponse habituelle de l’industrie à ces trois besoins est une flotte de bots keeper off-chain qui surveillent la chaîne. Si les bots s’arrêtent, le livre pourrit. C’est exactement le type de dépendance de liveness que ce protocole refuse partout ailleurs, aussi le Moteur de Staking la supprime-t-il : le livre se nettoie de lui-même, à partir du flux organique de l’usage ordinaire.
§9 · La Surface de Vérification
Un protocole qui garde de la valeur ne devrait pas demander qu’on le croie ; il devrait publier les moyens de le vérifier. Le Moteur de Staking transforme sa propre intégrité en un ensemble de lectures publiques, gratuites et on-chain, afin que n’importe quelle partie — un staker, un auditeur, un concurrent, un sceptique — puisse confirmer en un seul eth_call que le contrat détient ce qu’il déclare devoir. Aucun tableau de bord, aucun subgraph, aucun indexeur, aucune confiance.
§10 · Sécurité Économique
La sûreté du Moteur repose sur une arithmétique qu’un adversaire ne peut pas tordre, non sur des hypothèses qu’un adversaire peut briser. Sans oracle et sans dépendance off-chain, le modèle de menace est exceptionnellement réduit, et chaque menace restante est refermée par une propriété structurelle imposée à chaque transaction plutôt que par la vigilance d’un opérateur.
§11 · Le Cycle de Vie d’une Position
La mécanique des sections précédentes se comprend mieux en suivant une position tout au long de sa vie, avec des nombres concrets. Les chiffres globaux de ce parcours sont illustratifs — ils fixent les dénominateurs par rapport auxquels la part de la position est calculée — mais chaque constante et chaque formule appartiennent au contrat lui-même, et chaque nombre ci-dessous en découle.
§12 · Urgences et le Coupe-circuit
Le blocage n’est pas inconditionnel, et prétendre le contraire fausserait la garantie. Deux voies d’arrêt existent, et elles sont délibérément dissemblables.
§13 · Conclusion
Nous voulions faire de la solvabilité une propriété du code plutôt qu’une affirmation à son sujet, et le moteur que ce document spécifie est cette intention menée à son terme. Une identité de conservation, imposée comme condition d’annulation à chaque transaction qui déplace de la valeur, rend inatteignable l’insolvabilité par fonctionnement ordinaire ; une conception mono-actif supprime l’oracle qui casse la plupart des prêteurs avant même qu’il puisse exister ; la maintenance voyage dans l’usage ordinaire, bornée en gas, sans aucun keeper ; et l’arrêt de dernier recours appartient à quiconque peut prouver, à partir du seul état de la chaîne, qu’il est nécessaire.
Questions, a partnership or a bug to report? Contact us or email contact@blazephoenix.xyz