Sieben Contracts. Eine Mathematik.

Das gesamte Protokoll besteht aus sieben Contracts, und beide Engines sind nach demselben Prinzip aufgebaut: eine Bibliothek reiner Mathematik als Basis, importiert von den operativen Contracts, sodass keine Zahl je neu definiert wird und nichts einem Wert vertraut, den es nicht selbst berechnet hat. Fünf bilden den Aggregator; zwei bilden die Staking-Engine. Jede Adresse unten ist das reale, verifizierte Deployment auf Base; derselbe Bytecode läuft auf Ethereum, Optimism, Arbitrum und Robinhood Chain (vollständige Matrix unter /verify).

Die Aggregator-Pentade

„Fünf Contracts, von denen einer reine Mathematik ist, importiert von den anderen vier.“ Der Core berechnet; der Hub erinnert sich; der Solver entscheidet; der Router settelt; der Quoter zeigt eine Vorschau. Jeder legt einen einzigen kompakten Fehlerpfad offen, sodass die Revert-Oberfläche ebenso lesbar bleibt wie der Erfolgspfad.

BlazePhoenixCorepure library · inlined, no separate address

Ω · 𝒟 · Φ · Ψ — reine Mathematikbibliothek, stateless. Ohne Storage, ohne Owner, ohne Upgrade-Pfad — nur Funktionen. Der Eightfold Dispatcher Ω, die Deterministic Derivation 𝒟, das Iron Law Φ und das Vitality Field Ψ existieren hier als reine Berechnungen. Von den anderen vier importiert; keine Mathematik wird irgendwo sonst neu definiert.

Hub0x428554DEe93A1B8B5Bc6Fd19adDAfe55106fc04C

Ψ · registry — Venue-Register und Vitalitätsfeld. Enthält das Kandidatenpool-Register (16 gepackte Slots pro Paar), das Vitalitätsfeld und die Bridge-Token-Menge, unter ERC-7201-Namespacing, sodass sein Storage niemals mit den Slots eines Consumers kollidieren kann.

Solver0xB1902990260975dD4C89ad74B1f317bc100CB830

𝒰(route) — Read-Path-Optimierer. Ein reiner Read-Path-Optimierer, der die Meta-Gleichung über alle Routen maximiert und keinen Zustand berührt, den er nicht selbst herleiten kann. Er entscheidet; er settelt nie.

Router0x2a779f9Be49aac57495A8B6467Cc325a8a47Eb9f

Φ · execute — atomare Ausführung, der einzige Bewegungsträger von Geldern. Der einzige Contract, der Werte bewegt, und er bewegt sie atomar unter der Mindest-Output-Grenze des Aufrufers — indem er die Untergrenze des Iron Law Φ on-chain neu herleitet, sodass ein kompromittiertes Frontend sie niemals senken kann. Hält nichts im Ruhezustand.

Quoter0x4cEF0615614B212895F45Aa1D4833B16666E18d3

previewPlan — Off-Chain-Vorschauspiegel. Spiegelt den Solver für die Off-Chain-Vorschau über previewPlan und erzeugt konstruktionsbedingt dieselbe Zahl, die der Router realisieren wird. Das Quote IST die Ausführungslogik.

5 Contracts.

Die Staking-Dyade

Dieselbe Disziplin, angewandt auf das eigene Kapital des Protokolls: eine reine Mathematikbibliothek und die Engine, die sie importiert. Da Sicherheit und geliehenes Asset dasselbe Token sind (BZPX), existiert nirgendwo ein Preisorakel — eine ganze Angriffsfläche fehlt konstruktionsbedingt.

BlazePhoenixMathLibpure library · inlined, no separate address

mulDiv · rawBalanceOf — reine Mathematikbibliothek, inlined. Die vollständige 512-Bit-Multiply-then-Divide-Operation, durch die jede Proportion läuft, plus rawBalanceOf, der staticcall, der dem Contract erlaubt, seine EIGENE Besicherung zu lesen. Vollständig intern, daher in den Bytecode der Engine inlined (keine eigene Adresse) — genau wie der Core es für den Aggregator ist.

BlazePhoenixStaking0x3f60C7aa0c36a78D200405feBE143d2Cf3fA0c77

conserves — die Engine mit erzwungener Solvenz. Ein einzelner Contract, der leistet, was die meisten Protokolle auf drei aufteilen — Vault, Kreditmarkt und Lock-Boost —, abgeglichen über einen einzigen UserInfo-Datensatz und zwei Akkumulatoren, wobei jeder wertbewegende Pfad von der conserves-Guard umschlossen wird. 180M BZPX auf einer zweijährlichen Halving-Kurve über sechzehn Jahre; Solvenz ist eine Revert-Bedingung, keine Dashboard-Anzeige.

2 Contracts.

Die eine Gleichung, auf der jede Engine ruht

Der Aggregator maximiert ein einziges Ziel über alle Kandidatenrouten — den Netto-Output nehmen, aber nur von Routen, die die Untergrenze des Iron Law Φ erfüllen, gewichtet nach der Vitalität jedes Pools:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mrow><mi>𝒰</mi><mo>(</mo><mi>route</mi><mo>)</mo><mo>=</mo><mi>𝟙</mi><mo>[</mo><msub><mi>y</mi><mtext>net</mtext></msub><mo>≥</mo><mi>Φ</mi><mo>·</mo><msub><mi>y</mi><mtext>quote</mtext></msub><mo>]</mo><mo>·</mo><msub><mi>y</mi><mtext>net</mtext></msub><mo>·</mo><munder><mo>∏</mo><mi>i</mi></munder><msubsup><mi>Ψ</mi><mi>i</mi><msub><mi>w</mi><mi>i</mi></msub></msubsup></mrow></math>

Die Staking-Engine ruht auf der Master Conservation Identity — das physische Guthaben entspricht dem, was das Ledger schuldet, durchgesetzt pro Transaktion durch die conserves-Guard, sodass ein insolventer Zustand unerreichbar ist, nicht nur beobachtbar:

balanceOf(this) + totalBadDebt
  == (totalStaked − totalDebt) + rewardReserve + protocolReserve
     + (totalRewardDistributed − totalRewardsPaid)

Live und kostenlos direkt von der Chain nachlesen: /solvency (oder isSolvent() · solvency() · auditInvariants()).

Verifizieren Sie alles selbst

Nichts hier verlangt Vertrauen. Die Staking-Engine ist jetzt live und solvent:

cast call 0x3f60C7aa0c36a78D200405feBE143d2Cf3fA0c77 "isSolvent()(bool)" --rpc-url https://mainnet.base.org

Code-Lizenz: Die Contracts stehen bis 2030 unter BUSL-1.1 — frei lesen, auditieren und verifizieren; für den Produktiveinsatz ist eine Lizenz erforderlich. Partner werden, nicht klonen ›

Englisch (vollständige Architekturseite)