Connect ›
Cover: The iron floor: a minimum output the contract re-derives for itself

The iron floor: a minimum output the contract re-derives for itself

How BlazePhoenix computes minOut on-chain at execution time — callers can tighten it but never relax it — and why per-leg floors stop sandwich decomposition.

Known formally as The Iron Law Φ in the BlazePhoenix whitepaper.

BlazePhoenix Engineering · updated 2026-07-17 · data through 2026-10-11 · 6 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 — The Router re-derives the minimum output ON-CHAIN at execution: callers may tighten it, never relax it, and every route leg must deliver at least 80% of plan or the whole trade reverts.

Português — O Router re-deriva o output mínimo ON-CHAIN na execução: quem chama pode apertar, nunca alargar, e cada leg da rota tem de entregar pelo menos 80% do plano ou o trade inteiro reverte.

Español — El Router re-deriva el mínimo de salida EN CADENA al ejecutar: el llamante puede endurecerlo, nunca relajarlo, y cada tramo debe entregar al menos el 80% del plan o toda la operación revierte.

Français — Le Router re-dérive le minimum de sortie ON-CHAIN à l'exécution : l'appelant peut le durcir, jamais l'assouplir, et chaque segment doit livrer au moins 75 % du plan sous peine de revert intégral.

Deutsch — Der Router leitet das Mindest-Output ON-CHAIN bei Ausführung neu ab: Aufrufer dürfen es verschärfen, nie lockern, und jedes Routenbein muss mindestens 75 % des Plans liefern, sonst revertiert alles.

Русский — Роутер заново выводит минимальный выход ОН-ЧЕЙН при исполнении: вызывающий может ужесточить его, но не ослабить, и каждое плечо маршрута обязано дать не менее 80% плана, иначе вся сделка откатывается.

Türkçe — Router asgari çıktıyı yürütme anında ZİNCİR ÜSTÜNDE yeniden türetir: çağıran sıkılaştırabilir ama asla gevşetemez; her rota bacağı planın en az %80'ini vermek zorundadır, yoksa işlem tümüyle geri döner.

العربية — يعيد الموجّه اشتقاق الحد الأدنى للمخرجات على السلسلة عند التنفيذ: يمكن للمستدعي تشديده لا تخفيفه، وعلى كل ساق في المسار تسليم 80% من الخطة على الأقل وإلا ارتدت الصفقة كاملة.

हिन्दी — Router निष्पादन के समय न्यूनतम आउटपुट ऑन-चेन फिर से निकालता है: कॉलर उसे कड़ा कर सकता है, ढीला कभी नहीं, और रूट के हर लेग को योजना का कम से कम 80% देना होगा वरना पूरा ट्रेड रिवर्ट हो जाता है।

日本語 — Routerは実行時に最低出力をオンチェーンで再導出します。呼び出し側は厳しくはできても緩めることはできず、各レッグは計画の80%以上を届けなければ取引全体がrevertします。

中文 — Router 在执行时于链上重新推导最低输出：调用者只能收紧、不能放宽，且每条路径腿必须交付计划的至少 80%，否则整笔交易回滚。

한국어 — Router는 실행 시점에 최소 산출량을 온체인에서 재산출합니다. 호출자는 더 조일 수만 있고 늦출 수 없으며, 각 경로 레그는 계획의 80% 이상을 내야 하고 아니면 거래 전체가 revert됩니다.

Bahasa Indonesia — Router menurunkan ulang output minimum ON-CHAIN saat eksekusi: pemanggil boleh memperketat, tak pernah melonggarkan, dan tiap kaki rute wajib menyerahkan minimal 80% rencana atau seluruh transaksi revert.

বাংলা — Router সম্পাদনের সময় ন্যূনতম আউটপুট অন-চেইনে পুনরায় নির্ণয় করে: কলার তা কঠোর করতে পারে, শিথিল কখনো নয়, এবং রুটের প্রতিটি লেগকে পরিকল্পনার অন্তত ৮০% দিতে হবে নইলে পুরো ট্রেড রিভার্ট হয়।

Filipino — Muling kinukuwenta ng Router ang minimum output ON-CHAIN sa mismong execution: maaaring higpitan ng caller, hindi kailanman paluwagin, at bawat leg ng ruta ay dapat maghatid ng hindi bababa sa 80% ng plano o kaya'y babalik ang buong trade.

Slippage protection usually means: the frontend computes minOut, the user signs it, the contract obeys it. Two failure modes follow — a compromised frontend supplies minOut = 1, or MEV moves the market inside the block and the stale floor lets the sandwich through.

The BlazePhoenix Router re-derives the floor ON-CHAIN at execution time from the same quoting machinery (the iron floor). The caller-supplied minOut is honoured only if it is TIGHTER than the contract's own floor: you can demand more protection than the contract computes, never less. A poisoned frontend cannot lower the floor below what the chain itself considers honest execution.

The floor formula, from the deployed bytecode

The floor is not a constant — it adapts. It starts at 96% for a clean single-leg swap and loosens with route impact, how the trade is split across legs, and volatility, but is clamped so it can never fall below a 80% hard cap regardless of inputs:

floor=max(9600−200·(Neff−1)−impact−σ1014,8000)bps
Core.ironFloorBpsShv: base 9600, −200 bps per effective extra leg (N_eff = (Σa)²/Σa² per hop, so a split earns its shave from how the amounts divide, not from a count), −1 bps per bps of impact, minus a volatility term, hard-clamped at 8000 (20% max loss). The caller's minOut may only tighten this.

Per-leg floors

A route-level floor alone can be gamed by decomposition: pass the total check while one leg inside the route is sandwiched to death and another overperforms. The Router therefore also enforces a per-leg floor — each leg must deliver at least 80% (LEG_FLOOR_BPS = 8000) of its planned output, or the whole transaction reverts. An attacker must now beat every leg simultaneously, not just the average.

The floor is a backstop — set minOut anyway

Read the direction carefully, because it is the whole safety design: the iron floor is the WORST outcome the Router will ever allow, not the protection you should rely on day to day. It is the seatbelt that catches a catastrophe (a poisoned frontend, an MEV spike) — a 20% hard cap is a bad day you survived, not a good fill. Your everyday protection is minOut: the minimum output you personally demand, which the contract honours whenever it is TIGHTER than its own floor.

So set a real slippage limit — a minOut you would genuinely accept: around half a percent on deep pairs, a few percent only on genuinely thin tokens, knowing the cost. You can always ask for more protection than the contract computes; you can never be tricked into less. Two independent invariants, both enforced on-chain, neither trusting a server: the floor you cannot lower, and the minOut you choose to raise. The floor does not negotiate: it counts, and then it refuses.

Do not trust this page — reproduce it

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

Read the verified source of the Router on Basescan (/verify lists the address): LEG_FLOOR_BPS = 8_000 is a compile-time constant of BlazePhoenixCore, inlined into the Router bytecode, so no transaction can change it. It has no getter; the source is the proof.
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 iron floor: a minimum output the contract re-derives for itself. BlazePhoenix Engineering. https://blazephoenix.xyz/learn/iron-floor
@misc{blazephoenix_iron_floor,
  title  = {The iron floor: a minimum output the contract re-derives for itself},
  author = {BlazePhoenix},
  year   = {2026},
  url    = {https://blazephoenix.xyz/learn/iron-floor},
  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).

Related engineering

Share𝕏FarcasterLinkedInDiscuss on Telegram
Next in Invariants & security · 11 / 17
Provable staking solvency: an invariant anyone can check, any block ›The BlazePhoenix staking engine exposes isSolvent() and a 13-field solvency() report on-chain. What the invariant covers, how the live report works, and how to reproduce it.6 min