The enforced invariants: INV-1 to INV-20, properties that hold in every reachable state

Twenty properties hold in every reachable state of the BlazePhoenix contracts — not monitored, enforced: a transaction that would violate one does not execute. The full enumeration with enforcement sites, the boundaries stated with the guarantees, and three you can spot-check from a terminal in a minute.

Known formally as INV-1–INV-20 in the BlazePhoenix whitepaper.

BlazePhoenix Engineering · updated 2026-08-16 · 10 min · written from the deployed bytecode

By Mitra (@Sigmacrit) — anonymous developer of the BlazePhoenix protocol. The code is the résumé.

Abstract in 15 languages · resumo · resumen · 摘要 · 要旨 · ملخص

English — Twenty properties, INV-1 to INV-20, hold in every reachable state of the BlazePhoenix contracts — not monitored, enforced: a transaction that would violate one does not execute. The full enumeration with enforcement sites and boundaries, plus three invariants you can spot-check from a terminal in one minute.

Português — Vinte propriedades, INV-1 a INV-20, valem em todo estado alcançável dos contratos BlazePhoenix — não monitorizadas, impostas: uma transação que violasse uma delas não executa. A enumeração completa com os locais de imposição e os limites, mais três invariantes verificáveis de um terminal num minuto.

Español — Veinte propiedades, INV-1 a INV-20, se cumplen en todo estado alcanzable de los contratos BlazePhoenix — no monitorizadas, impuestas: una transacción que violara una no se ejecuta. La enumeración completa con los sitios de imposición y los límites, más tres invariantes comprobables desde una terminal en un minuto.

Français — Vingt propriétés, INV-1 à INV-20, tiennent dans chaque état atteignable des contrats BlazePhoenix — non surveillées, imposées : une transaction qui en violerait une ne s'exécute pas. L'énumération complète avec les sites d'application et les limites, plus trois invariants vérifiables depuis un terminal en une minute.

Deutsch — Zwanzig Eigenschaften, INV-1 bis INV-20, gelten in jedem erreichbaren Zustand der BlazePhoenix-Verträge — nicht überwacht, erzwungen: Eine Transaktion, die eine verletzen würde, wird nicht ausgeführt. Die vollständige Aufzählung mit Durchsetzungsstellen und Grenzen, plus drei Invarianten, die man in einer Minute vom Terminal prüft.

Русский — Двадцать свойств, INV-1–INV-20, выполняются в каждом достижимом состоянии контрактов BlazePhoenix — не отслеживаются, а принуждаются: транзакция, нарушающая одно из них, не исполняется. Полное перечисление с местами принуждения и границами, плюс три инварианта, проверяемых из терминала за минуту.

Türkçe — Yirmi özellik, INV-1'den INV-20'ye, BlazePhoenix sözleşmelerinin ulaşılabilir her durumunda geçerlidir — izlenmez, dayatılır: birini ihlal edecek işlem yürütülmez. Dayatma noktaları ve sınırlarıyla tam liste, artı bir dakikada terminalden doğrulanabilecek üç değişmez.

العربية — عشرون خاصية، من INV-1 إلى INV-20، تصح في كل حالة قابلة للبلوغ في عقود BlazePhoenix — لا تُراقَب بل تُفرَض: المعاملة التي تنتهك إحداها لا تُنفَّذ. الجرد الكامل مع مواضع الفرض والحدود، إضافةً إلى ثلاث لامتغيرات يمكن التحقق منها من الطرفية في دقيقة.

हिन्दी — बीस गुणधर्म, INV-1 से INV-20, BlazePhoenix कॉन्ट्रैक्ट्स की हर पहुँच-योग्य अवस्था में कायम रहते हैं — निगरानी नहीं, प्रवर्तन: जो लेनदेन किसी एक का उल्लंघन करे, वह निष्पादित ही नहीं होता। प्रवर्तन-स्थलों और सीमाओं के साथ पूरी सूची, और तीन अपरिवर्तनीय जिन्हें आप टर्मिनल से एक मिनट में जाँच सकते हैं।

日本語 — 二十の性質INV-1〜INV-20は、BlazePhoenixコントラクトの到達可能なすべての状態で成り立ちます。監視ではなく強制です。どれかに違反する取引は実行されません。強制地点と境界を添えた全列挙に加え、ターミナルから一分で確かめられる三つの不変量も示します。

中文 — 二十条性质（INV-1 至 INV-20）在 BlazePhoenix 合约的每个可达状态中都成立——不是被监控，而是被强制：会违反其中任何一条的交易不会执行。完整清单附带强制执行点与边界，另有三条不变量可在终端里一分钟内亲自抽查。

한국어 — 스무 가지 속성 INV-1부터 INV-20까지는 BlazePhoenix 컨트랙트의 도달 가능한 모든 상태에서 성립합니다 — 모니터링이 아니라 강제입니다: 이를 위반할 트랜잭션은 실행되지 않습니다. 강제 지점과 경계를 담은 전체 목록과 함께, 터미널에서 1분 안에 직접 점검할 수 있는 세 가지 불변식을 소개합니다.

Bahasa Indonesia — Dua puluh sifat, INV-1 sampai INV-20, berlaku di setiap keadaan terjangkau kontrak BlazePhoenix — bukan dipantau, melainkan dipaksakan: transaksi yang akan melanggar salah satunya tidak dieksekusi. Enumerasi lengkap dengan titik pemaksaan dan batasnya, plus tiga invarian yang bisa Anda periksa sendiri dari terminal dalam satu menit.

বাংলা — বিশটি বৈশিষ্ট্য, INV-1 থেকে INV-20, BlazePhoenix কন্ট্রাক্টের প্রতিটি পৌঁছানো-যোগ্য অবস্থায় বজায় থাকে — নজরদারি নয়, বলবৎ: যে লেনদেন এর একটিও লঙ্ঘন করবে, তা নির্বাহই হয় না। বলবৎকরণের স্থান ও সীমাসহ পূর্ণ তালিকা, সঙ্গে তিনটি ইনভ্যারিয়েন্ট যা আপনি টার্মিনাল থেকে এক মিনিটে যাচাই করতে পারেন।

Filipino — Dalawampung katangian, INV-1 hanggang INV-20, ang tumitibay sa bawat maaabot na estado ng mga kontrata ng BlazePhoenix — hindi minomonitor, ipinapatupad: ang transaksyong lalabag sa isa ay hindi maipapatupad. Ang buong enumerasyon na may mga lugar ng pagpapatupad at hangganan, dagdag pa ang tatlong invariant na masusuri mo mula sa terminal sa loob ng isang minuto.

An invariant, in this protocol's usage, is not a goal and not a monitoring target. It is a property that holds in every reachable state because the shape of the code enforces it at a named site, and a transaction that would violate it does not execute. The whitepaper enumerates all twenty in an appendix with stable numbering — cite them as INV-1 through INV-20 — and each row carries the same three-part form this site uses everywhere: the claim, the enforcement site, and the boundary.

The list is worth reading as a design in itself. Fifteen govern the aggregator, five the staking engine, and between them they cover custody, atomicity, pricing honesty, fee honesty, adaptive-state quarantine, and solvency. Nothing on the list is aspirational: every one is checkable against the verified source, and several are checkable against the live chain with one command.

The aggregator: INV-1 to INV-15

Custody and atomicity first. INV-1: the Router holds no funds between transactions — its balance at rest is zero, because settlement sweeps every balance out. INV-2: every swap is atomic; no state exists in which part of a trade settled. INV-3: no oracle — no external price feed is an input to admission, ordering, splitting, flooring or fees, in either engine. INV-4: the fee rate, the fee split, the floor constants and the emission schedule have no setters in the deployed bytecode; they are compile-time constants, and immutability means there is no owner who could quietly move them later.

Protection next. INV-5: caller-supplied route fields can tighten protection, never loosen it — the effective minimum is a three-way maximum computed from in-frame measurements. INV-6: a swap with a zero minimum output does not execute, rejected at every entry point. INV-7 is the adaptive-state quarantine: the Vitality Field Ψ ranks and truncates candidates, but no quote, floor or allocation reads it — a score can hide a venue, never misprice a fill. INV-8 bounds the registry at sixteen pools per pair with a +25% eviction hurdle; INV-9 admits no address without runtime bytecode; INV-10 confines the universal callback to paying only the committed pool, only mid-leg, never above the leg's recorded budget, via transient storage.

Then the hard-won ones. INV-11: a V4 hook whose address declares delta-altering permissions is rejected before any token moves, without being called — the screen is an AND-mask over immutable address bits. INV-12 and INV-13 are the arithmetic discipline: every dangerous multiplication is factored through 512-bit mulDiv so no pricing product can overflow, and every division floors — accumulated rounding can only leave the contracts holding more than they owe. INV-14 is the posture in one line: where a bound cannot be proven, the computation returns zero and the venue is surrendered — never a guess. INV-15 closes the fee: the base never exceeds the smaller of quote and delivery, and an understated quote charges on delivery, so forging quotes downward loses money.

The staking engine: INV-16 to INV-20

INV-16 is the one the others lean on: every value-moving staking entry point conserves — held and owed move by equal amounts within 10⁻⁸ BZPX, or the transaction reverts. That is the Master Conservation Identity enforced per transaction by the conserves modifier, and it is why an insolvent state is unreachable rather than merely unlikely. INV-17 is the single-writer rule: exactly one function writes the global boosted denominators, re-deriving both contributions atomically — the discipline that closed an entire class of disclosed findings and now also carries the emergency accounting's non-negative-equity accumulator. INV-18 pins time: a lapsed lock is paid at 1.00× from the instant of expiry, because every boost derives through effective lock time.

INV-19 bounds credit: debt is fixed at origination, interest is deducted from the borrower's own stake and never compounds, per-position debt stays at or below a third of stake, and aggregate utilisation at or below 75%. INV-20 is the Permissionless Breaker: anyone on earth may halt the contract, if and only if they can prove it insolvent — the trip condition is an objective on-chain fact (balance plus dust below owed()) that no caller can assert into existence, the breaker cannot be cancelled while the breach holds, and renunciation through the One-Way Door is written true at one site and false at none.

balance+totalDebt+totalBadDebt=totalStaked+rewardReserve+protocolReserve+pending
The Master Conservation Identity (E18), enforced per transaction by the conserves modifier (INV-16): a transaction that would unbalance it reverts, which is why insolvency is unreachable rather than monitored.

Spot-check three of them right now

INV-6, from any RPC: submit an eth_call to any Router entry point with minOut = 0 and watch it revert — the mandatory-minimum check runs before anything moves. INV-16's public face: cast call 0x3f60C7aa0c36a78D200405feBE143d2Cf3fA0c77 "isSolvent()(bool)" against Base returns the live verdict free, at any block, and auditInvariants() exposes every term of the identity for independent summation. INV-4: pull the verified source from any explorer and grep for setter functions on the fee, the floor constants or the emission schedule — there are none to find.

That is what the list is for. A protocol description made of enforced invariants is falsifiable line by line, which is precisely what makes it safe to cite: not that the claims are modest, but that every one of them names the code that would have to be wrong for the claim to fail.

Do not trust this page — reproduce it

Every claim above is checkable against the chain. Start here:

INV-6 in one step: eth_call any Router entry point with minOut = 0 and observe the revert; then cast call 0x3f60C7aa0c36a78D200405feBE143d2Cf3fA0c77 "isSolvent()(bool)" --rpc-url https://mainnet.base.org for the live face of INV-16
Cite this article

Licensed CC BY 4.0 — quote, translate and reuse freely, including commercially, with attribution and a link. Copy a ready-made citation:

BlazePhoenix (2026). The enforced invariants: INV-1 to INV-20, properties that hold in every reachable state. BlazePhoenix Engineering. https://blazephoenix.xyz/learn/the-invariants
@misc{blazephoenix_the_invariants,
  title  = {The enforced invariants: INV-1 to INV-20, properties that hold in every reachable state},
  author = {BlazePhoenix},
  year   = {2026},
  url    = {https://blazephoenix.xyz/learn/the-invariants},
  note   = {Accessed: reproduce the claim with the command above}
}

Writing an answer, a wiki entry or a paper? The claim above is reproducible against the chain before you quote it — which is the only sound basis for citing a technical source at all.

Contracts are verified on every chain we deploy to — addresses in the protocol manifest. Deeper formal treatment: the whitepaper (PDF). Standards cited: HTTPS://BLAZEPHOENIX.XYZ/DOCS/BLAZEPHOENIX_WHITEPAPER.PDF · HTTPS://GITHUB.COM/BLAZEPHOENIXXYZ-CRYPTO/BLAZE-PHOENIX-DEX · HTTPS://GITHUB.COM/BLAZEPHOENIXXYZ-CRYPTO/BLAZE-PHOENIX-STAKING

Share this article · join the discussion

Share on X ↗Telegram ↗WhatsApp ↗Farcaster ↗💬 Discuss on Telegram

Related engineering