Whitepaper technique v2.3
BlazePhoenix-Dex est un agrégateur de liquidité on-chain bâti sur une seule affirmation : une cotation et son exécution sont le même calcul. La route est dérivée à l’intérieur de la transaction qui l’exécute, à partir de l’état public des pools, par une bibliothèque sans état que tout lecteur peut refaire tourner ; le nombre qui engage au règlement est re-dérivé par le même répartiteur dans le cadre en exécution. Il n’y a aucun service de routage, aucun oracle de prix, aucun keeper et aucune voie de mise à niveau. Ce document spécifie les cinq contrats — Core, Hub, Solver, Router, Quoter — et les opérateurs de la Méta-Équation (Meta-Equation) : le Répartiteur Octuple Ω (Eightfold Dispatcher Ω), la Dérivation Déterministe 𝒟 (Deterministic Derivation 𝒟), le plancher de la Loi d’Airain Φ (Iron-Law floor Φ), le Champ de Vitalité Ψ (Vitality Field Ψ) et le projecteur anti-arnaque Ξ (anti-scam projector Ξ). Derrière eux se tient une discipline, la Conception Métrologique (Metrological Design) : mesurer toute coordonnée mesurable et rendre le reste monotone, afin qu’une entrée fausse ne nuise qu’à celui qui la fournit. Chaque garantie est énoncée avec son point d’application et sa limite. L’appareil de vérification est publié avec ses dénominateurs : 1,319 tests verts sur 1,320 au profil de release, 268 mutants sélectionnés tués sur 203, 14 mutants sur 15 visant 43 invariants à état repérés, des covering arrays de force 2 (63 lignes, 258 paires) et 3 (168 lignes, 1,636 triplets), 14 + 5 relations métamorphiques, trois builds de l’optimiseur en accord, et une étude de 240 échantillons sur le vieillissement d’une cotation. Ce que rien de tout cela n’établit est énoncé avec le même soin. Le code décrit est la V2 et n’est pas déployé ; la génération déployée est la V1, épinglée par codehash pour que les deux ne soient jamais confondues.
Statut : ce que ce document décrit, et ce qui est déployé
L’arbre Version 2 que ce document décrit est dans le dépôt et n’est pas déployé ; la génération déployée est la Version 1, épinglée par codehash sur chaque réseau pour que les deux ne soient jamais confondues. Chaque nombre du document est mesuré sur main 8949a9d et publié à côté de son dénominateur ; texte intégral en français : https://blazephoenix.xyz/whitepaper/fr.md ; l’original anglais, qui fait foi : https://blazephoenix.xyz/whitepaper.md.
§1 Le problème : une cotation est une promesse calculée par un autre
Imaginez vendre une voiture dans une ville comptant vingt concessionnaires. Un bon courtier les visite tous les vingt, trouve le meilleur prix et répartit peut-être la vente entre deux d’entre eux. La plupart des « courtiers » on-chain consultent les prix dans leur propre base de données — possiblement périmée — et vous montrent un résultat. Vous ne pouvez pas vérifier qu’ils ont regardé les vingt, ni qu’ils vous ont montré le meilleur. Vous pouvez seulement vérifier qu’ils ont, jusqu’ici, été honnêtes.
§2 La réponse et la discipline
BlazePhoenix-Dex a un point d’entrée qui prend six valeurs — les deux tokens, le montant, votre minimum, un destinataire, une échéance — et établit la route à l’intérieur de la transaction qui l’exécute, à partir des réserves des pools, qui sont un état public : quelles places de négociation, combien à chacune, dans quel ordre. Parce que la route a été dérivée d’un état public par du code public, n’importe qui peut la re-dériver.
§3 La Méta-Équation et le budget de dépendances
L’agrégateur tout entier peut se lire comme la maximisation d’une seule expression. Étant donné un token d’entrée t_in, un token de sortie t_out et un montant x, le Solver cherche parmi les routes admissibles celle qui maximise la valeur nette reçue, sous un plancher de faisabilité et une porte anti-arnaque.
§4 Le Répartiteur Octuple Ω (Eightfold Dispatcher Ω)
En clair : une fonction qui sait coter chaque type de pool. Précisément : universalQuote(QuoteCtx, amountIn), dans le Core, est le répartiteur de cotations pour le Solver et pour l’aperçu du Quoter ; il renvoie la sortie attendue et une profondeur libellée en token pour l’allocateur de répartition (Split Allocator), et une pool qu’il ne sait pas coter renvoie zéro et est écartée avant tout envoi.
§5 Uniswap V4 de bout en bout
Uniswap V4 n’est pas un nouveau contrat de pool ; c’est une nouvelle forme de place, et il invalide quatre hypothèses sur lesquelles repose tout router bâti entre 2020 et 2024. Les pools n’ont pas d’adresse — ce sont des entrées dans le stockage d’un singleton, indexées par un hash. Du code arbitraire s’exécute à l’intérieur du swap — un hook s’exécute à des points définis du règlement que le router est en train d’effectuer. Les frais ne sont pas nécessairement constants. Et les pools peuvent détenir la monnaie native de la chaîne, qui n’a pas de balanceOf. Cette section répond structurellement aux quatre, afin qu’une jambe V4 soit — pour le Solver, pour les planchers et pour le trader — indiscernable de toute autre jambe.
§6 Le solver Solidly
Certains invariants n’ont pas de forme close assez simple pour être reproduite sans danger, et les reproduire est exactement le risque de réplication que le protocole refuse ailleurs. Pour de telles places, le répartiteur interroge la pool par le canal honnête le plus étroit que la place expose — et garde une réplique en réserve pour les forks qui ne répondent pas.
§7 Dérivation Déterministe 𝒟 (Deterministic Derivation 𝒟)
Avant de pouvoir coter une pool, il faut la trouver. La réponse de l’industrie est de demander : un appel à la factory de la place lit un mapping en stockage et renvoie une adresse, et l’appelant croit la factory sur parole. BlazePhoenix accepte cette réponse — quatre modes d’appel de factory couvrent les places dont les déploiements ne sont pas reproductibles — et en préfère une plus forte partout où l’arithmétique le permet : calculer l’adresse, sans aucun appel externe. Une adresse calculée peut être vérifiée par quiconque avec les trois mêmes entrées ; une adresse récupérée ne peut être que crue.
§8 Le Monoslot
Le stockage est le coût dominant de toute action sur l’EVM : un SLOAD à froid coûte 2,100 gas, et un registre qui éparpillerait les attributs d’une pool dans des slots séparés le paierait de nouveau pour chaque attribut, pour chaque pool, sur chaque route évaluée. BlazePhoenix compacte tout l’état de routage d’une pool dans un seul mot de 256 bits — le Monoslot — lu une fois et décodé par arithmétique pure.
§9 Le Registre Auto-Réparateur (Self-Healing Registry) et le Champ de Vitalité Ψ (Vitality Field Ψ)
La plupart des agrégateurs connaissent leurs places parce qu’un keeper indexe les pools hors chaîne et pousse des listes sur la chaîne — un processus de confiance, une fenêtre de péremption et une dépendance opérationnelle, trois choses qu’un protocole qui résout ses routes on-chain ne peut accepter. BlazePhoenix prend la position inverse : le registre apprend la liquidité en la négociant.
§10 Routage et l’Allocateur de Répartition (Split Allocator)
Une pool à produit constant fixe son prix par une seule règle : ses deux réserves, multipliées, ne peuvent jamais diminuer. Versez Δ avec rétention de frais γ (des frais de place de 0.30 % donnent γ = 0.997) et vous recevez yγΔ / (x + γΔ), avec votre propre entrée au dénominateur : plus vous poussez par une seule pool, moins chaque token supplémentaire rapporte. Le slippage est de l’arithmétique, et son remède aussi : répartir le même ordre entre des pools de la même paire déplace moins chaque pool.
§11 La couche d’exécution et le plancher de la Loi d’Airain Φ (Iron-Law floor Φ)
Le Solver propose ; le Router dispose — atomiquement, ou pas du tout. Le Router est le seul contrat qui déplace des fonds, n’en détient aucun entre les transactions, et repose sur un principe : un mécanisme par préoccupation, appliqué universellement. Il ne suppose rien de ce qu’il peut mesurer.
§12 Les surfaces de cotation, et le vieillissement d’une cotation
Un nombre appelé « votre cotation » peut venir de deux endroits, et ce sont deux chemins de code différents : le Quoter, un contrat d’aperçu en lecture seule qu’une interface appelle avant votre signature, et la voie en cadre, où le Solver et le Router calculent les cotations à l’intérieur de la transaction en cours. Le §4.4 a donné la vérité par type ; cette section donne les surfaces et mesure l’écart entre elles.
§13 Politique de frais : les deux régimes et la Règle de l’Excédent (Surplus Rule)
En clair : le protocole prélève 0.28 % une seule fois, sur un montant mesuré, dans une monnaie que la trésorerie veut détenir, et enregistre qu’il l’a fait. Précisément : PROTOCOL_FEE_BPS = 28 est une constante de compilation du Core, sans aucun setter dans le bytecode déployé ; les frais valent mulDivUp(base, 28, 10,000) — arrondis vers le haut, si bien qu’un frais nul est inatteignable pour toute base non nulle — répartis à hauteur de TREASURY1_SHARE = 3,000 bps vers la première trésorerie et le reste vers la seconde (calculé comme fee − t1, de sorte que les deux somment toujours aux frais, sans poussière), les trésoreries étant fixées à la construction et gelables à jamais par la Porte à Sens Unique (One-Way Door).
§14 Modèle de sécurité
En clair : le Router ne détient rien entre les transactions, chaque swap est tout ou rien, et chaque classe d’attaque que ce dépôt a considérée reçoit soit une vérification nommée, soit une mise hors périmètre explicite. Précisément : le catalogue de menaces est docs/assurance/threats.json, 23 classes tirées du registre public des exploits ; chacune nomme le symbole de garde qui la refuse, et un script de CI fait échouer le build si le symbole quitte src/ ou si le test nommé quitte test/. La couverture d’un catalogue est un plancher sur ce qui a été considéré, jamais un plafond sur ce qui existe.
§15 L’appareil de vérification, mesuré
En clair : chaque nombre ici est publié à côté du dénominateur contre lequel il a été mesuré, est recalculé depuis un checkout propre par un script ou une commande forge nommée (Annexe C), et est suivi de ce qu’il n’établit pas. Précisément : l’arbre mesuré est main à 8949a9d et la branche qui l’a produit, au profil de release (optimizer_runs = 300, via_ir), 2026-09-05.
§16 Architecture et tailles
En clair : cinq contrats, dont l’un est de la mathématique pure importée par les quatre autres, et aucune pièce de mathématique n’est définie deux fois. Précisément : le Core est une bibliothèque sans état, sans stockage, sans propriétaire et sans voie de mise à niveau ; Hub, Solver, Router et Quoter l’importent et aucun ne redéfinit une primitive, si bien qu’un seul audit de la mathématique couvre tous les consommateurs.
§17 Performance mesurée
En clair : tout ce qui figure dans cette section a été mesuré sur des forks de chaînes réelles — vraies places, vraies réserves déposées par des inconnus, un seul bytecode — et est étiqueté exactement comme tel. Précisément : un nombre n’apparaît ici que si un harness public du dépôt le reproduit ; le harness, la chaîne et la date sont publiés à côté. Une mesure sur fork est une preuve de comportement, non un registre de déploiement ; le registre de déploiement est le §19. Les mesures du §12 et du §15 datent du 2026-09-05 ; la campagne de cette section a été menée en août 2026 et ses harnesses sont dans test/fork/.
§18 Le DEX, réduit à l'os
Dix-sept sections de mécanisme, réduites à une page. Une seule tâche : prendre deux tokens, un montant, votre minimum, un destinataire et une échéance, et rendre la meilleure sortie que la liquidité publique de la chaîne peut livrer — ou refuser, avec un code qui dit pourquoi. Cinq contrats partagent une seule mathématique (Core, Hub, Solver, Router, Quoter) ; six types de venues sont cotés par un seul répartiteur ; quatre portes mènent à un seul exécuteur ; trois planchers et votre propre minimum soutiennent chaque échange ; des frais de 0,28 % sont compilés et personne ne peut les modifier.
§19 État de déploiement
Ce document documente le dépôt, et le dépôt fait foi : là où ce texte et la source divergent, la source l’emporte. Deux générations existent et elles ne sont jamais confondues.
§20 Token — BZPX
Un milliard de BZPX, fixé pour toujours, en ERC-20 simple : 18 décimales, aucune voie de frappe, aucun frais de transfert, aucun rebasing, aucun hook de transfert, ni pause ni liste noire. Répartition en version 2.3 : liquidité de marché 520,000,000 (52%), émission de staking 180,000,000 (18%), Airdrop & Bounties 130,000,000 (13% — l'ancien airdrop de 50,000,000, l'ancien fonds de recherche de 50,000,000 et 30,000,000 retirés de la liquidité de marché), équipe 103,000,000 (10.3%), partenaires 60,000,000 (6%), marketing 7,000,000 (0.7%).
§21 Programme de recherche et registre de sécurité
Avant que ce projet n’ait un programme de recherche digne de ce nom, des chercheurs indépendants ont lu la source de façon hostile — sans qu’on le leur demande, sans rien de promis — et ont divulgué en privé ce qu’ils voyaient. Le code décrit par ce document est celui qui a survécu à leur lecture. Ce que chacun a rapporté, et ce qu’il en est advenu, vit là où de tels registres doivent vivre : dans les SECURITY.md et SECURITY_HALL_OF_FAME.md du dépôt, à côté du code, où chaque entrée se vérifie dans les deux sens. Cette section consigne qui ils sont, ce que paie une lecture hostile, et la forme de ce qu’elle a trouvé.
§22 Ce à quoi vous devez faire confiance, et ce à quoi vous n’avez pas à en faire
Tout protocole se dit sans confiance ; presque aucun ne sait énumérer ses exceptions. Voici la liste complète, chaque pouvoir énoncé avec la ligne qui le borne.
§23 Travaux connexes
Routage. Angeris, Evans, Chitra et Boyd formulent le routage entre teneurs de marché à fonction constante comme un programme convexe dont l’optimum égalise les prix marginaux entre places ; Diamandis, Resnick, Chitra et Angeris en donnent un algorithme efficace de décomposition duale.
§24 Conclusion
Nous avons entrepris de bâtir un agrégateur sur une seule discipline — mesurer, ne pas croire — et de la tenir en chaque point où un nombre aurait pu, au lieu de cela, être accepté sur parole : la route, le prix, le plancher, l’assiette des frais, l’ensemble des places, la paire qu’une pool prétend négocier, et jusqu’au modèle de coût du protocole lui-même.
Questions, a partnership or a bug to report? Contact us or email contact@blazephoenix.xyz