Staking-Engine Whitepaper v1.0
Die BlazePhoenix Staking-Engine ist ein Ein-Asset-Tresor und eine Kreditfazilität für BZPX ganz ohne Orakel, denn Sicherheit und Schuld sind derselbe Token. Die Meister-Erhaltungsidentität (Master Conservation Identity) wird bei jeder werttransportierenden Transaktion durch den Modifier conserves erzwungen — eine Transaktion, die das Buch mehr fordern ließe, als der Vertrag hält, wird zurückgerollt. Die Emission halbiert sich über acht Zweijahresperioden (eight two-year periods) als geschlossene Form über die Blockuhr; ein quadratischer Boost vergütet die Bindungszusage bis zu 2.75× bei sieben Jahren; zwei disjunkte Akkumulatoren zahlen Emission und Kreditnehmerzinsen ohne jede Quersubventionierung; die Wartung reist auf gewöhnlichen Transaktionen mit, gasbegrenzt; und jeder Mensch auf der Welt darf den Schutzschalter mit einem On-Chain-Beweis der Zahlungsunfähigkeit auslösen. Der Entwurf ruht auf einer Disziplin, die er mit dem BlazePhoenix-Aggregator teilt und die hier auf das eigene Kapital des Protokolls angewandt wird: rechnen, nicht vertrauen. Jede Rendite, jeder Satz und jede Solvenzprüfung wird aus dem Kettenzustand durch Arithmetik abgeleitet, die eine Leserin nachrechnen kann — kein Preis-Feed, keine Keeper-Flotte, kein Dashboard, dem man glauben müsste. Drei Grenzen werden vorab benannt, denn eine Garantie ist nur so ehrlich wie ihre Ränder. Die Engine ist im Bau — der Hinweis oben, nicht eine Fußnote. Administrative Rollen existieren, und jede wird mit der Linie aufgeführt, die sie begrenzt: ein Admin, dessen werttransportierende Befugnisse das Kapital der Staker nicht erreichen (§10.3), und ein Guardian, dessen stärkste Befugnis keinerlei Mittel bewegt (§12). Und die Bindung ist nicht bedingungslos: es gibt zwei Halte-Pfade, absichtlich einander unähnlich, jeder vollständig spezifiziert und mit dauerhaft festgehaltener Herkunft (§12). Was eine Leserin zu prüfen hat, ist nicht unsere Ehrlichkeit, sondern unsere Quelle.
Status: die Engine ist im Bau
Der BlazePhoenix-Liquiditätsaggregator ist das ausgelieferte Produkt. Die Staking-Engine ist nicht ausgeliefert: sie befindet sich in aktiver Entwicklung. Dieses Papier spezifiziert den Entwurf der Staking-Engine, wie er steht — jede Gleichung, jede Invariante, jede Konstante und jeder unten genannte Einstiegspunkt ist die Spezifikation, an der die Implementierung gemessen wird — damit eine Leserin die Engine beurteilen kann, bevor es sie gibt. Den Entwurf zuerst zu veröffentlichen ist bei unveränderlicher Software die richtige Reihenfolge: ein Vertrag, der nicht gepatcht werden kann, gehört vor der Bereitstellung beurteilt, nicht danach, und dieses Dokument ist so gebaut, dass dieses Urteil möglich wird — jede Zahl nachvollziehbar herleitbar, jede Garantie zusammen mit ihrem Durchsetzungsort und ihrer Grenze im selben Absatz genannt. Wenn die Engine ausgeliefert wird, wird der bereitgestellte Bytecode kanonisch und dieses Papier wird zu seinem Protokoll; bis dahin ist das Papier die öffentliche, falsifizierbare Behauptung der Engine darüber, was sie sein wird. Vollständiger Text, auf Englisch: https://blazephoenix.xyz/staking-whitepaper.md
§1 · Eine Disziplin, zwei Engines
BlazePhoenix ist ein vollständiges On-Chain-Finanzprotokoll aus zwei ineinandergreifenden Engines — einem Liquiditätsaggregator und einer Staking-Engine —, die eine Disziplin teilen: rechnen, nicht vertrauen. Jeder Preis, jede Rendite und jede Solvenzprüfung im Protokoll wird aus dem Kettenzustand durch Arithmetik abgeleitet, die eine Leserin nachrechnen kann. Kein Routing-Dienst, kein Preisorakel, kein Keeper, kein Upgrade-Pfad: wo die meisten Protokolle darum bitten, geglaubt zu werden, veröffentlicht dieses die Mittel, geprüft zu werden.
§2 · Die Staking-These und die Meister-Erhaltungsidentität
Ein Aggregator leitet fremde Liquidität; ein Protokoll muss auch die eigene pflegen. Die BlazePhoenix Staking-Engine verwandelt BZPX von einem statischen Guthaben in produktives Kapital — ein Renditeinstrument, eine besicherte Kreditlinie und den Ausrichtungsmechanismus, der langfristige Halter an den Erfolg des Protokolls bindet — und sie tut all das in einem einzigen Vertrag, regiert von einer einzigen Gleichung.
§3 · Der Token und der Emissionsplan
Eine Milliarde BZPX, für immer fix, als schlichter ERC-20: 18 Nachkommastellen, kein Mint-Pfad, keine Transfergebühr, kein Rebasing, keine Transfer-Hooks, keine Pause und keine Blacklist — die sechs Deploy-Invarianten, die im Staking-Repository festgehalten und beim Verdrahten gegen den Bytecode des Tokens geprüft werden. Das voll verwässerte Angebot steht seit der Genesis fest; Knappheit ist eine Eigenschaft des Vertrags, keine Politik. Die Verteilung der Milliarde auf die Allokationen des Protokolls ist ein Datensatz auf Protokollebene und steht beim Begleitpapier und beim eigenen On-Chain-Datensatz des Tokens; dieses Papier trägt den Teil, den die Engine erzwingt — das Emissionsbudget
§4 · Verpflichtendes gebundenes Staking und die Boost-Kurve
Schlicht gesagt: es gibt kein liquides Staking — jede Einzahlung bindet ihr Kapital für eine gewählte Laufzeit, und das Protokoll hält die Laufzeit schlicht ein. Genau gesagt:
§5 · Die Doktrin der zwei Akkumulatoren (Dual-Accumulator Doctrine)
Die Engine zahlt zwei verschiedene Renditen aus zwei disjunkten Quellen, und ein Staker verdient je nach dem, ob er borgt, eine davon oder beide. Das ist der feinste Teil des Entwurfs und der Grund, warum ein einziger Vertrag Sparer und Kreditnehmer bedienen kann, ohne dass einer den anderen subventioniert. Die Buchführung folgt dem im gesamten DeFi bewährten Akkumulator-Muster: ein globaler Index je Anteil schreitet fort, sowie Wert eintrifft, jede Position speichert den Index ihrer letzten Abrechnung, und die ausstehende Rendite ist die Differenz mal dem Gewicht der Position. Beide Akkumulatoren schreiten auf derselben Uhr fort — _updateGlobal läuft in jedem Einstiegspunkt zuerst,
§6 · Die Kreditfazilität
Kreditprotokolle brechen weit häufiger am Orakel als an der Mathematik: ein manipulierter Feed lässt solide Sicherheiten wertlos aussehen — oder wertlose Sicherheiten solide — und die Liquidationslogik, so korrekt sie auch sei, wird auf einer Lüge ausgeführt. BlazePhoenix härtet das Orakel nicht; es beseitigt die Kategorie. Sicherheiten-Asset und geborgtes Asset sind derselbe Token: eine Stakerin bindet BZPX und borgt BZPX dagegen, sodass der Beleihungsauslauf einer Position ein reines Verhältnis zweier Beträge eines Tokens ist — Schuld über Stake — und keinen externen Preis zur Bewertung braucht. Es gibt keinen Feed zum Manipulieren, kein TWAP-Fenster
§7 · Liquidation
Eine Position wird liquidierbar, sobald aufgelaufene Zinsen ihren Stake bis auf 5% ihrer Schuld erodiert haben — die Garantie in einem Satz: eine Position darf genau dann liquidiert werden, wenn debt × 100 ≥ stake × 95 gilt, auf dem erlaubnisfreien und dem autonomen Pfad identisch geprüft, und keinen Block früher. Die Verwertung durchläuft dann einen festen Wasserfall:
§8 · Autonome Wartung (Autonomous Maintenance)
Liquidationen müssen rechtzeitig erfolgen, Zinsen müssen auflaufen, und abgelaufene Bindungs-Boosts müssen freigegeben werden — und die übliche Antwort der Branche auf alle drei ist eine Flotte von Off-Chain-Keeper-Bots, die die Kette beobachten. Halten die Bots an, verrottet das Buch. Das ist genau die Art von Liveness-Abhängigkeit, die dieses Protokoll überall sonst verweigert, also beseitigt die Staking-Engine sie: das Buch räumt sich selbst auf, aus dem organischen Fluss gewöhnlicher Nutzung.
§9 · Die Verifikationsfläche
Ein Protokoll, das Werte verwahrt, sollte nicht darum bitten, geglaubt zu werden; es sollte die Mittel veröffentlichen, geprüft zu werden. Die Staking-Engine verwandelt ihre eigene Integrität in eine Menge öffentlicher, kostenloser On-Chain-Lesezugriffe, sodass jede Partei — eine Stakerin, eine Prüferin, ein Wettbewerber, eine Skeptikerin — in einem einzigen eth_call bestätigen kann, dass der Vertrag hält, was er zu schulden erklärt. Kein Dashboard, kein Subgraph, kein Indexer, kein Vertrauen.
§10 · Ökonomische Sicherheit
Die Sicherheit der Engine ruht auf Arithmetik, die ein Angreifer nicht biegen kann, nicht auf Annahmen, die ein Angreifer brechen kann. Ohne Orakel und ohne Off-Chain-Abhängigkeit ist das Bedrohungsmodell ungewöhnlich klein, und jede verbleibende Bedrohung wird durch eine strukturelle Eigenschaft geschlossen, die bei jeder Transaktion erzwungen wird, statt durch die Wachsamkeit eines Betreibers.
§11 · Der Lebenszyklus einer Position
Die Mechanik der vorangehenden Abschnitte versteht man am besten, indem man eine Position mit konkreten Zahlen durch ihr ganzes Leben verfolgt. Die globalen Größen in diesem Durchgang sind illustrativ — sie setzen die Nenner, gegen die der Anteil der Position berechnet wird —, aber jede Konstante und jede Formel gehört dem Vertrag selbst, und jede Zahl unten folgt aus ihnen.
§12 · Notfälle und der Schutzschalter
Die Bindung ist nicht bedingungslos, und etwas anderes zu behaupten würde die Garantie falsch darstellen. Es gibt zwei Halte-Pfade, und sie sind absichtlich einander unähnlich.
§13 · Fazit
Wir sind angetreten, Solvenz zu einer Eigenschaft des Codes zu machen statt zu einer Behauptung über ihn, und die Engine, die dieses Papier spezifiziert, ist dieser Vorsatz zu Ende gedacht. Eine Erhaltungsidentität, bei jeder werttransportierenden Transaktion als Revert-Bedingung erzwungen, macht Zahlungsunfähigkeit durch gewöhnlichen Betrieb unerreichbar; ein Ein-Asset-Entwurf beseitigt das Orakel, an dem die meisten Kreditgeber brechen, bevor es überhaupt entstehen kann; die Wartung reist auf gewöhnlicher Nutzung mit, gasbegrenzt, ganz ohne Keeper; und der Halt letzter Instanz gehört jedem, der allein aus dem Kettenzustand beweisen kann, dass er nötig ist.
Englisch (vollständiges Paper)
Questions, a partnership or a bug to report? Contact us or email contact@blazephoenix.xyz