Engineering, from the bytecode
These articles are the whitepaper unlocked: how the deployed contracts actually quote, route, clamp and prove — including the measured failure cases that shaped the design. No claim without a command: every article ends with a way to reproduce it against the chain yourself.
- On-chain quoting: why the price you see is the price the contract computedHow BlazePhoenix computes DEX-aggregator quotes fully on-chain via previewPlan and revert-extraction, why that removes the trusted-API problem, and what exact-mode requoting means for execution guarantees.6 min · updated 2026-07-17
- Phantom liquidity: when pools advertise depth they do not holdThe capital-anchor doctrine: how BlazePhoenix filters quote-manipulation by anchoring route selection on real token balances, with a measured case where two dead pools outvoted a $401k pool.7 min · updated 2026-07-17
- The two-tier capacity clamp: refusing trades a pool cannot absorbWhy BlazePhoenix caps per-pool trade size against real holdings — with the measured case of a 117x phantom quote and a 27% loss that the clamp turns into a refusal.6 min · updated 2026-07-17
- The iron floor: a minimum output the contract re-derives for itselfHow BlazePhoenix computes minOut on-chain at execution time — callers can tighten it but never relax it — and why per-leg floors stop sandwich decomposition.6 min · updated 2026-07-17
- The surplus doctrine: when execution beats the quote, the user keeps the differenceBlazePhoenix returns positive slippage to the trader, fee-exempt, enforced in Router bytecode — not a marketing promise. How it works and how to verify it per fill.5 min · updated 2026-07-17
- Provable staking solvency: an invariant anyone can check, any blockThe 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 · updated 2026-07-17
- The Hub: a self-curating pool registry with fitness evictionHow BlazePhoenix keeps its candidate-pool set honest on-chain: a packed 256-bit slot registry capped at 16 slots, where a challenger must beat the incumbent by a 25% fitness margin to evict it.6 min · updated 2026-07-17
- EIP-1153 transient storage: route context that cannot outlive the transactionWhere BlazePhoenix uses transient storage (TSTORE/TLOAD): reentrancy locks and fee-on-transfer flags that reset to zero at transaction end by protocol law — cheaper than SSTORE and immune to stale-state bugs.5 min · updated 2026-07-17
- Renouncing power without abandoning the protocol: the control/curator splitBlazePhoenix separates CONTROL (parameters, upgrades, funds — renounceable) from CURATION (candidate maintenance — operational), so decentralization does not have to mean neglect. Plus EIP-7702 as a first-class entry path.6 min · updated 2026-07-17
- One on-chain call for a thousand clients: quote coalescing at the edgeHow the BlazePhoenix public API absorbs traffic spikes without hammering RPCs: request coalescing (singleflight), one-block edge caching, and a meta.cache field that tells every client exactly what happened.6 min · updated 2026-07-17
- Any ticker, one honest answer: resolving symbols by deepest real liquidityHow the BlazePhoenix API turns an arbitrary token symbol into an address: choose the candidate with the deepest verified liquidity, echo the resolution back, and let addresses stay the precision path.5 min · updated 2026-07-17
- CREATE2 discovery: verifying a pool is who it claims to beHow the BlazePhoenix Hub uses deterministic CREATE2 addresses (EIP-1014) to derive where a pool MUST live before trusting it — impersonation becomes an address mismatch instead of an exploit.5 min · updated 2026-07-17
- Pool vitality: liveness as a measured property, not an assumptionRegistries rot: pools die, liquidity migrates, incentives dry up. BlazePhoenix treats a pool's right to receive order flow as something continuously re-earned through measured vitality — real depth, real quoting, real recency.5 min · updated 2026-07-17
- The Master Conservation Identity: making insolvency unreachable, not just observableOne equation the whole staking book obeys — balance + badDebt = net principal + reserves + accrued-unpaid — enforced per-transaction by a conserves guard. A tx that would leak value reverts itself.7 min · updated 2026-07-17
- The self-cleaning book: keeper-free maintenance carried by ordinary transactionsBlazePhoenix staking has no keeper requirement: every user transaction sweeps a rotating, gas-bounded window of borrowers, liquidates anything underwater and pays the surplus to whoever carried the gas.6 min · updated 2026-07-17
- Lending without a price oracle: deleting an attack surface instead of defending itIn BlazePhoenix staking the collateral IS the borrowed asset (BZPX both sides), so no price oracle exists anywhere — oracle manipulation, the cause of hundreds of millions in DeFi losses, has nothing to attack.6 min · updated 2026-07-17
Formal treatment with proofs and diagrams: whitepaper (PDF) · quick overview: litepaper (PDF).