The 512-bit multiply: why every BlazePhoenix number is exact to the last wei

Known formally as Full-Precision Multiply in the BlazePhoenix whitepaper.

BlazePhoenix Engineering · updated 2026-07-21 · 7 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 — Every proportion in BlazePhoenix — reward shares, collateral ratios, interest slices — runs through one full 512-bit multiply-then-divide (mulDiv), so the intermediate a·b product never overflows and no figure drifts by a single wei; dividing by an odd number uses a Newton-Raphson modular inverse that doubles its correct bits each step, 4 → 256.

Português — Cada proporção no BlazePhoenix — quotas de recompensa, rácios de colateral, fatias de juro — passa por um único multiplicar-e-dividir de 512 bits (mulDiv), para que o produto intermédio a·b nunca transborde e nenhum número desvie um só wei; dividir por um ímpar usa um inverso modular de Newton-Raphson que duplica os bits corretos a cada passo, 4 → 256.

Español — Cada proporción en BlazePhoenix — cuotas de recompensa, ratios de colateral, tramos de interés — pasa por una única multiplicación-y-división de 512 bits (mulDiv), para que el producto intermedio a·b nunca desborde y ningún número se desvíe ni un wei; dividir por un impar usa un inverso modular de Newton-Raphson que duplica sus bits correctos en cada paso, 4 → 256.

Français — Chaque proportion dans BlazePhoenix — parts de récompense, ratios de collatéral, tranches d’intérêt — passe par une seule multiplication-puis-division sur 512 bits (mulDiv), de sorte que le produit intermédiaire a·b ne déborde jamais et qu’aucun nombre ne dérive d’un seul wei ; diviser par un impair emploie un inverse modulaire de Newton-Raphson qui double ses bits corrects à chaque étape, 4 → 256.

Deutsch — Jede Proportion in BlazePhoenix — Belohnungsanteile, Beleihungsquoten, Zinsscheiben — läuft durch eine einzige 512-Bit-Multiplikation-dann-Division (mulDiv), sodass das Zwischenprodukt a·b nie überläuft und keine Zahl um ein einziges Wei driftet; die Division durch eine ungerade Zahl nutzt ein Newton-Raphson-Modularinverses, das seine korrekten Bits pro Schritt verdoppelt, 4 → 256.

Русский — Каждая пропорция в BlazePhoenix — доли награды, коэффициенты залога, части процента — проходит через одно полное 512-битное умножение-затем-деление (mulDiv), поэтому промежуточное произведение a·b никогда не переполняется и ни одно число не смещается ни на вей; деление на нечётное использует модулярно-обратное Ньютона-Рафсона, удваивающее верные биты на каждом шаге, 4 → 256.

Türkçe — BlazePhoenix’teki her oran — ödül payları, teminat oranları, faiz dilimleri — tek bir tam 512-bit çarp-sonra-böl (mulDiv) işleminden geçer; böylece ara çarpım a·b asla taşmaz ve hiçbir sayı tek bir wei bile kaymaz; tek sayıya bölme, doğru bitlerini her adımda ikiye katlayan bir Newton-Raphson modüler tersini kullanır, 4 → 256.

العربية — كل نسبة في BlazePhoenix — حصص المكافأة، نسب الضمان، شرائح الفائدة — تمر عبر عملية ضرب-ثم-قسمة واحدة بدقة 512 بت (mulDiv)، فلا يفيض حاصل الضرب الوسيط a·b أبداً ولا ينحرف أي رقم ولو بِوَي واحد؛ والقسمة على عدد فردي تستخدم معكوساً نمطياً بطريقة نيوتن-رافسون يضاعف بتاته الصحيحة في كل خطوة، من 4 إلى 256.

हिन्दी — BlazePhoenix में हर अनुपात — रिवॉर्ड हिस्से, कोलैटरल अनुपात, ब्याज के टुकड़े — एक ही पूर्ण 512-बिट गुणा-फिर-भाग (mulDiv) से गुज़रता है, ताकि बीच का गुणनफल a·b कभी ओवरफ़्लो न हो और कोई संख्या एक भी wei न खिसके; विषम से भाग एक Newton-Raphson मॉड्यूलर व्युत्क्रम से होता है जो हर चरण में अपने सही बिट दोगुने करता है, 4 → 256।

日本語 — BlazePhoenix のあらゆる比率 — 報酬シェア、担保比率、利息の分配 — はただ一つの完全な512ビット乗算後除算（mulDiv）を通るため、中間積 a·b は決してオーバーフローせず、どの数値も1weiたりともずれません。奇数での除算は、正しいビット数を各ステップで倍増させるニュートン・ラフソン法のモジュラ逆数を用います（4 → 256）。

中文 — BlazePhoenix 中的每个比例——奖励份额、抵押率、利息切片——都经过唯一一次完整的 512 位先乘后除（mulDiv），因此中间乘积 a·b 永不溢出，任何数字都不会偏移哪怕一个 wei；对奇数的除法采用牛顿-拉夫森模逆，每一步都使其正确位数翻倍，4 → 256。

한국어 — BlazePhoenix의 모든 비율 — 보상 지분, 담보 비율, 이자 조각 — 은 단 하나의 완전한 512비트 곱셈-후-나눗셈(mulDiv)을 거치므로 중간 곱 a·b는 결코 넘치지 않고 어떤 숫자도 단 1wei도 어긋나지 않습니다. 홀수로 나눌 때는 매 단계마다 올바른 비트 수를 두 배로 늘리는 뉴턴-랩슨 모듈러 역원을 사용합니다(4 → 256).

Bahasa Indonesia — Setiap proporsi di BlazePhoenix — bagian imbalan, rasio agunan, potongan bunga — melewati satu kali kalikan-lalu-bagi 512-bit penuh (mulDiv), sehingga hasil kali antara a·b tak pernah meluap dan tak ada angka bergeser satu wei pun; pembagian oleh bilangan ganjil memakai invers modular Newton-Raphson yang menggandakan bit benarnya tiap langkah, 4 → 256.

বাংলা — BlazePhoenix-এর প্রতিটি অনুপাত — পুরস্কারের ভাগ, জামানত অনুপাত, সুদের অংশ — একটিমাত্র পূর্ণ ৫১২-বিট গুণ-তারপর-ভাগ (mulDiv)-এর মধ্য দিয়ে যায়, তাই মধ্যবর্তী গুণফল a·b কখনো ওভারফ্লো করে না এবং কোনো সংখ্যা এক wei-ও সরে না; বিজোড় দিয়ে ভাগ করতে Newton-Raphson মডুলার বিপরীত ব্যবহৃত হয় যা প্রতি ধাপে সঠিক বিট দ্বিগুণ করে, ৪ → ২৫৬।

Filipino — Bawat proporsyon sa BlazePhoenix — bahagi ng gantimpala, ratio ng kolateral, hati ng interes — ay dumadaan sa iisang buong 512-bit na multiply-tapos-divide (mulDiv), kaya ang panggitnang produktong a·b ay hindi kailanman umaapaw at walang numerong gumagalaw kahit isang wei; ang paghahati sa gansal ay gumagamit ng Newton-Raphson modular inverse na dinodoble ang tamang bits kada hakbang, 4 → 256.

A reward share, a collateral ratio, an interest slice — every one is a multiplication followed by a division: a·b/d. The trap is the middle. On the EVM a and b are each up to 256 bits, so their product a·b can be up to 512 bits — and a naive `a * b / d` silently discards everything above bit 256. The number you get back is not rounded; it is corrupt. Most contracts dodge this by keeping values small and hoping. BlazePhoenix does not hope: every proportion in both engines flows through one function, BlazePhoenixMathLib.mulDiv, which keeps the full 512-bit product and returns the exact floor of a·b/d.

This is the same full-precision multiply popularised by Remco Bloemen and Solady, reproduced here as the arithmetic floor the whole protocol stands on. The Master Conservation Identity, the boost weights, the dual accumulators, the liquidation math — none of them can drift by a single wei from a silent overflow, because the multiply underneath them cannot overflow.

Splitting the product into 512 bits

The routine first computes the product as a 512-bit number held in two words, hi:lo, using the classic mulmod identity — the full product modulo 2^256 minus the low word, borrow-corrected:

let mm := mulmod(a, b, not(0))   // a·b mod (2^256 − 1)
let lo := mul(a, b)              // low 256 bits
let hi := sub(sub(mm, lo), lt(mm, lo))  // high 256 bits, borrow-corrected

The Newton-Raphson modular inverse

When the high word is zero the product fits in 256 bits and a plain division is exact. Otherwise the routine does a true 512-by-256 division: it removes the remainder, factors out the powers of two, then needs to divide by an odd number d — which on a two’s-complement machine means multiplying by the modular inverse of d mod 2^256. That inverse is found by Newton-Raphson. A seed correct to 4 bits, then each step DOUBLES the number of correct bits:

invk+1=invk·(2−d·invk)4→8→16→32→64→128→256
Quadratic convergence: the same doubling of correct digits as real-number Newton’s method. Six iterations from a 4-bit seed reach a full 256-bit inverse — exactly the six `inv := mul(inv, sub(2, mul(d, inv)))` lines in the source.

The safe sibling, and why it exists

Alongside mulDiv sits mulDivSafe, which returns 0 rather than reverting when an input is zero or the result would overflow. The two are not interchangeable: mulDiv guards places where a wrong number must halt the transaction (a share that cannot be represented is a bug); mulDivSafe guards places where zero is the correct, safe answer (no stake, no interest). Choosing the right one at each call site is itself part of the safety argument.

And one detail that ties the multiply to solvency: rawBalanceOf, in the same library, reads the contract’s own BZPX balance by staticcall and returns 0 on any malformed response — which the conservation guard treats as a (safe-fail) breach. The contract measures its own backing with the same rigor it multiplies with.

Do not trust this page — reproduce it

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

read the exactness yourself: cast call 0x3f60C7aa0c36a78D200405feBE143d2Cf3fA0c77 "collateralRatio()(uint256)" --rpc-url https://mainnet.base.org, then call backing() and owed() and check backing·1e18/owed equals it to the wei — that ratio is a mulDiv

Contracts are verified on every chain we deploy to — addresses in the protocol manifest. Deeper formal treatment: the whitepaper (PDF).

Share this article · join the discussion

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

Related engineering