Technisches Whitepaper v2.3
BlazePhoenix-Dex ist ein On-Chain-Liquiditätsaggregator, der auf einer einzigen Behauptung ruht: Eine Preisangabe (quote) und ihre Ausführung sind dieselbe Berechnung. Die Route wird innerhalb der Transaktion abgeleitet, die sie ausführt, aus dem öffentlichen Zustand der Pools, durch eine zustandslose Bibliothek, die jeder Leser erneut ausführen kann; die Zahl, die bei der Abwicklung bindet, wird vom selben Dispatcher im ausführenden Frame erneut abgeleitet. Es gibt keinen Routing-Dienst, kein Preisorakel, keinen Keeper und keinen Upgrade-Pfad. Dieses Papier spezifiziert die fünf Verträge — Core, Hub, Solver, Router, Quoter — und die Operatoren der Meta-Gleichung (Meta-Equation): den Achtfachen Dispatcher Ω (Eightfold Dispatcher Ω), die Deterministische Ableitung 𝒟 (Deterministic Derivation 𝒟), den Boden des Ehernen Gesetzes Φ (Iron-Law floor Φ), das Vitalitätsfeld Ψ (Vitality Field Ψ) und den Anti-Scam-Projektor Ξ (anti-scam projector Ξ). Hinter ihnen steht eine Disziplin, das Metrologische Design (Metrological Design): jede messbare Koordinate messen und den Rest monoton machen, damit eine falsche Eingabe nur ihrem Lieferanten schadet. Jede Garantie wird mit ihrem Durchsetzungsort und ihrer Grenze genannt. Der Prüfapparat wird mit seinen Nennern gedruckt: 1,319 von 1,320 Tests grün im Release-Profil, 268 von 268 kuratierten Mutanten getötet, 14 von 15 Mutanten, die auf 43 zustandsbehaftete Invarianten zielten, bemerkt, Covering Arrays der Stärke 2 (63 Zeilen, 258 Paare) und 3 (168 Zeilen, 1,636 Tripel), 14 + 5 metamorphe Relationen, drei übereinstimmende Optimierer-Builds und eine Studie mit 240 Stichproben dazu, wie eine Preisangabe altert. Was nichts davon belegt, wird ebenso sorgfältig genannt. Der beschriebene Code ist V2 und ist nicht deployt; die deployte Generation ist V1, per Codehash fixiert, damit beide nie verwechselt werden.
Status: was dieses Papier beschreibt und was deployt ist
Der Version-2-Baum, den dieses Papier beschreibt, liegt im Repository und ist nicht deployt; die deployte Generation ist Version 1, in jedem Netz per Codehash fixiert, damit beide nie verwechselt werden. Jede Zahl im Papier ist auf main 8949a9d gemessen und steht neben ihrem Nenner; der vollständige Text auf Englisch unter https://blazephoenix.xyz/whitepaper.md.
§1 Das Problem: eine Preisangabe ist ein Versprechen, das jemand anderes berechnet hat
Stellen Sie sich vor, Sie verkaufen ein Auto in einer Stadt mit zwanzig Händlern. Ein guter Makler besucht alle zwanzig, findet den besten Preis und teilt den Verkauf vielleicht auf zwei von ihnen auf. Die meisten On-Chain-„Makler“ prüfen Preise in ihrer eigenen Datenbank — womöglich veraltet — und zeigen Ihnen ein Ergebnis. Sie können nicht überprüfen, dass sie alle zwanzig angesehen haben, und auch nicht, dass sie Ihnen den besten gezeigt haben. Sie können nur überprüfen, dass sie bisher ehrlich waren.
§2 Die Antwort und die Disziplin
BlazePhoenix-Dex hat einen Einstiegspunkt, der sechs Werte entgegennimmt — die beiden Token, den Betrag, Ihr Minimum, einen Empfänger, eine Frist — und die Route innerhalb der Transaktion ermittelt, die sie ausführt, aus Pool-Reserven, die öffentlicher Zustand sind: welche Handelsplätze, wie viel an jeden, in welcher Reihenfolge. Weil die Route aus öffentlichem Zustand durch öffentlichen Code abgeleitet wurde, kann jeder sie erneut ableiten.
§3 Die Meta-Gleichung und das Abhängigkeitsbudget
Der gesamte Aggregator lässt sich als Maximierung eines einzigen Ausdrucks lesen. Gegeben ein Eingabetoken t_in, ein Ausgabetoken t_out und ein Betrag x, sucht der Solver unter den zulässigen Routen jene, die den netto erhaltenen Wert maximiert, unter einem Machbarkeitsboden und einem Anti-Scam-Gatter.
§4 Der Achtfache Dispatcher Ω (Eightfold Dispatcher Ω)
Schlicht gesagt: eine Funktion, die jede Art von Pool bepreisen kann. Genau gesagt: universalQuote(QuoteCtx, amountIn) im Core ist der Preisangaben-Dispatcher für den Solver und für die Vorschau des Quoter; er liefert die erwartete Ausgabe und eine in Token bemessene Tiefe für den Aufteilungs-Allokator (Split Allocator), und eine Pool, die er nicht bepreisen kann, liefert null und wird verworfen, bevor irgendetwas gesendet wird.
§5 Uniswap V4 von Anfang bis Ende
Uniswap V4 ist kein neuer Pool-Vertrag; es ist eine neue Form von Handelsplatz, und es entwertet vier Annahmen, auf denen jeder zwischen 2020 und 2024 gebaute Router ruht. Pools haben keine Adressen — sie sind Einträge im Speicher eines Singletons, adressiert über einen Hash. Innerhalb des Swaps läuft beliebiger Code — ein Hook wird an definierten Punkten der Abwicklung ausgeführt, die der Router gerade vornimmt. Gebühren müssen nicht konstant sein. Und Pools dürfen die native Währung der Kette halten, die kein balanceOf hat. Dieser Abschnitt beantwortet alle vier strukturell, damit ein V4-Bein — für den Solver, für die Böden und für den Händler — von jedem anderen Bein ununterscheidbar ist.
§6 Der Solidly-Solver
Manche Invarianten haben keine geschlossene Form, die einfach genug wäre, um sie gefahrlos nachzubilden, und sie nachzubilden ist genau das Replikationsrisiko, das das Protokoll anderswo ablehnt. Für solche Handelsplätze fragt der Dispatcher die Pool selbst, über den engsten ehrlichen Kanal, den der Handelsplatz anbietet — und hält ein Replikat in Reserve für Forks, die nicht antworten.
§7 Deterministische Ableitung 𝒟 (Deterministic Derivation 𝒟)
Bevor eine Pool bepreist werden kann, muss sie gefunden werden. Die Antwort der Branche lautet: fragen. Ein Aufruf an die Factory des Handelsplatzes liest ein Speicher-Mapping und gibt eine Adresse zurück, und der Aufrufer glaubt der Factory aufs Wort. BlazePhoenix unterstützt diese Antwort — vier Factory-Aufrufmodi decken die Handelsplätze ab, deren Deployments nicht reproduzierbar sind — und bevorzugt überall dort, wo die Arithmetik es zulässt, eine stärkere: die Adresse berechnen, ohne externen Aufruf. Eine berechnete Adresse kann jeder mit denselben drei Eingaben nachprüfen; einer geholten Adresse kann man nur glauben.
§8 Der Monoslot
Speicher ist der beherrschende Kostenfaktor für alles auf der EVM: ein kalter SLOAD kostet 2,100 gas, und ein Register, das die Attribute einer Pool über getrennte Slots streute, würde ihn erneut zahlen — für jedes Attribut, für jede Pool, auf jeder bewerteten Route. BlazePhoenix packt den gesamten Routing-Zustand einer Pool in ein einziges 256-Bit-Wort — den Monoslot — einmal gelesen und durch reine Arithmetik dekodiert.
§9 Das Selbstheilende Register (Self-Healing Registry) und das Vitalitätsfeld Ψ (Vitality Field Ψ)
Die meisten Aggregatoren kennen ihre Handelsplätze, weil ein Keeper Pools off-chain indiziert und Listen on-chain schiebt — ein vertrauenswürdig zu unterstellender Prozess, ein Veraltungsfenster und eine operative Abhängigkeit, drei Dinge, die ein Protokoll, das Routen on-chain löst, nicht hinnehmen kann. BlazePhoenix bezieht die Gegenposition: das Register lernt Liquidität, indem es sie handelt.
§10 Routing und der Aufteilungs-Allokator (Split Allocator)
Eine Constant-Product-Pool bepreist nach einer Regel: ihre beiden Reserven, multipliziert, dürfen nie schrumpfen. Gießen Sie Δ hinein mit Gebührenrückbehalt γ (eine Handelsplatzgebühr von 0.30 % bedeutet γ = 0.997), so erhalten Sie yγΔ / (x + γΔ), mit Ihrer eigenen Eingabe im Nenner: je mehr Sie durch eine Pool drücken, desto schlechter zahlt jeder weitere Token. Slippage ist Arithmetik, und ihr Gegenmittel ebenso: dieselbe Order über Pools desselben Paares aufzuteilen bewegt jede Pool weniger.
§11 Die Ausführungsschicht und der Boden des Ehernen Gesetzes Φ (Iron-Law floor Φ)
Der Solver schlägt vor; der Router verfügt — atomar oder gar nicht. Der Router ist der einzige Vertrag, der Mittel bewegt, hält zwischen Transaktionen keine und ruht auf einem Prinzip: ein Mechanismus je Belang, universell angewandt. Er nimmt nichts an, was er messen kann.
§12 Die Flächen der Preisangabe, und wie eine Preisangabe altert
Eine Zahl, die „Ihre Preisangabe“ heißt, kann aus zwei Stellen kommen, und es sind verschiedene Codepfade: der Quoter, ein rein lesender Vorschauvertrag, den eine Oberfläche aufruft, bevor Sie signieren, und der Pfad im Frame, wo Solver und Router die Preisangaben innerhalb der ausführenden Transaktion berechnen. §4.4 gab die Wahrheit je Art; dieser Abschnitt gibt die Flächen und misst den Abstand zwischen ihnen.
§13 Gebührenpolitik: die zwei Regime und die Überschussregel (Surplus Rule)
Schlicht gesagt: das Protokoll nimmt 0.28 % einmal, von einem gemessenen Betrag, in einer Münze, die die Treasury halten will, und verbucht, dass es das getan hat. Genau gesagt: PROTOCOL_FEE_BPS = 28 ist eine Compile-Zeit-Konstante im Core ohne jeden Setter im deployten Bytecode; die Gebühr ist mulDivUp(base, 28, 10,000) — aufgerundet, sodass eine Nullgebühr für jede Basis ungleich null unerreichbar ist — aufgeteilt mit TREASURY1_SHARE = 3,000 bps an die erste Treasury und dem Rest an die zweite (berechnet als fee − t1, sodass beide stets ohne Staub die Gebühr ergeben), wobei die Treasuries bei der Konstruktion festgelegt und durch die Einbahntür (One-Way Door) für immer einfrierbar sind.
§14 Sicherheitsmodell
Schlicht gesagt: der Router hält zwischen Transaktionen nichts, jeder Swap ist alles oder nichts, und jede Angriffsklasse, die dieses Repository betrachtet hat, wird von einer benannten Prüfung beantwortet oder ausdrücklich als außerhalb des Rahmens benannt. Genau gesagt: der Bedrohungskatalog ist docs/assurance/threats.json, 23 Klassen aus der öffentlichen Chronik der Exploits; jede benennt das Wächtersymbol, das sie abweist, und ein CI-Skript lässt den Build scheitern, wenn das Symbol src/ oder der benannte Test test/ verlässt. Die Abdeckung eines Katalogs ist ein Boden dafür, was betrachtet wurde, nie eine Decke dafür, was existiert.
§15 Der Prüfapparat, gemessen
Schlicht gesagt: jede Zahl hier steht neben dem Nenner, gegen den sie gemessen wurde, wird aus einem sauberen Checkout durch ein Skript oder einen benannten forge-Befehl neu berechnet (Anhang C), und ihr folgt, was sie nicht belegt. Genau gesagt: der gemessene Baum ist main auf 8949a9d und der Branch, der dazu wurde, im Release-Profil (optimizer_runs = 300, via_ir), 2026-09-05.
§16 Architektur und Größen
Schlicht gesagt: fünf Verträge, von denen einer reine Mathematik ist, die die anderen vier importieren, und kein Stück Mathematik ist zweimal definiert. Genau gesagt: der Core ist eine zustandslose Bibliothek ohne Speicher, ohne Eigentümer und ohne Upgrade-Pfad; Hub, Solver, Router und Quoter importieren ihn und keiner definiert ein Primitiv neu, sodass ein Audit der Mathematik jeden Konsumenten abdeckt.
§17 Gemessene Leistung
Schlicht gesagt: alles in diesem Abschnitt wurde auf Forks echter Ketten gemessen — echte Handelsplätze, echte von Fremden eingezahlte Reserven, ein Bytecode — und ist genau so ausgewiesen. Genau gesagt: eine Zahl erscheint hier nur, wenn ein öffentliches Harness im Repository sie reproduziert; Harness, Kette und Datum stehen daneben. Eine Fork-Messung ist Evidenz über Verhalten, kein Deployment-Nachweis; der Deployment-Nachweis ist §19. Die Messungen von §12 und §15 stammen vom 2026-09-05; die Kampagne dieses Abschnitts lief im August 2026, und ihre Harnesses liegen in test/fork/.
§18 Der DEX, bis auf die Knochen
Siebzehn Abschnitte Mechanik, auf eine Seite reduziert. Eine Aufgabe: zwei Token, einen Betrag, Ihr Minimum, einen Empfänger und eine Frist nehmen und den höchsten Ertrag liefern, den die öffentliche Liquidität der Chain hergibt — oder mit einem Code ablehnen, der den Grund nennt. Fünf Verträge teilen eine Mathematik (Core, Hub, Solver, Router, Quoter); sechs Venue-Arten werden von einem Dispatcher bepreist; vier Türen führen zu einem Executor; drei Untergrenzen und Ihr eigenes Minimum stehen unter jedem Trade; eine Gebühr von 0,28 % ist einkompiliert, und niemand kann sie ändern.
§19 Deployment-Status
Dieses Papier dokumentiert das Repository, und das Repository ist kanonisch: wo dieser Text und die Quelle sich widersprechen, gewinnt die Quelle. Es existieren zwei Generationen, und sie werden nie verwechselt.
§20 Token — BZPX
Eine Milliarde BZPX, für immer fest, als schlichter ERC-20: 18 Dezimalstellen, kein Mint-Pfad, keine Transfergebühr, kein Rebasing, keine Transfer-Hooks, keine Pause, keine Blacklist. Verteilung in Version 2.3: Marktliquidität 520,000,000 (52%), Staking-Emission 180,000,000 (18%), Airdrop & Bounties 130,000,000 (13% — der frühere Airdrop von 50,000,000, der frühere Forschungspool von 50,000,000 und 30,000,000 aus der Marktliquidität), Team 103,000,000 (10.3%), Partner 60,000,000 (6%), Marketing 7,000,000 (0.7%).
§21 Forschungsprogramm und Sicherheitsakte
Bevor dieses Projekt ein Forschungsprogramm hatte, das den Namen verdiente, lasen unabhängige Forscher die Quelle feindlich — ungefragt, ohne Zusage — und legten privat offen, was sie sahen. Der Code, den dieses Papier beschreibt, ist der Code, der ihre Lektüre überstanden hat. Was jeder von ihnen meldete und was daraus wurde, liegt dort, wohin solche Aufzeichnungen gehören: in SECURITY.md und SECURITY_HALL_OF_FAME.md des Repositorys, neben dem Code, wo jeder Eintrag in beide Richtungen prüfbar ist. Dieser Abschnitt hält fest, wer sie sind, was feindliche Lektüre zahlt, und die Gestalt dessen, was sie fand.
§22 Was Sie vertrauen müssen und was nicht
Jedes Protokoll nennt sich vertrauensfrei; fast keines kann seine Ausnahmen aufzählen. Hier ist die vollständige Liste, jede Befugnis genannt mit der Zeile, die sie begrenzt.
§23 Verwandte Arbeiten
Routing. Angeris, Evans, Chitra und Boyd fassen das Routing über Constant-Function-Market-Maker als konvexes Programm, dessen Optimum die Grenzpreise über die Handelsplätze hinweg angleicht; Diamandis, Resnick, Chitra und Angeris geben dafür einen effizienten Algorithmus der dualen Zerlegung.
§24 Fazit
Wir haben uns vorgenommen, einen Aggregator auf einer Disziplin zu bauen — messen, nicht glauben — und sie an jedem Punkt zu halten, an dem eine Zahl stattdessen auf jemandes Wort hätte genommen werden können: die Route, der Preis, der Boden, die Gebührenbasis, die Menge der Handelsplätze, das Paar, das eine Pool zu handeln behauptet, und selbst das Kostenmodell des Protokolls.
Englisch (vollständiges Paper)
Questions, a partnership or a bug to report? Contact us or email contact@blazephoenix.xyz