# The primitive equations: E1–E27, the entire quantitative surface in one table

> Canonical: https://blazephoenix.xyz/learn/the-primitive-equations
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-08-16

Every quantitative claim in the BlazePhoenix whitepaper reduces to one of twenty-seven primitive equations, E1–E27, each implemented exactly once in a named contract and imported everywhere else — one definition, no drift. The full table in citable form: routing (E1–E17), staking (E18–E24), operations (E25–E27), across a protocol of about 4,200 source lines.

A protocol's trusted surface is the set of formulas it computes and the properties it enforces. The BlazePhoenix whitepaper enumerates both, exhaustively: twenty-seven primitive equations (E1–E27) and twenty enforced invariants (INV-1–INV-20), in two appendices with stable numbering. This article is the equation table in citable form; the companion piece carries the invariants.

The discipline behind the table matters as much as its contents. Each equation is implemented exactly once, in the contract named for it, and imported everywhere else — one definition, no drift, so there is no second copy of any formula to disagree with the first. And the whole surface is small: the seven deployed contracts total 4,197 lines of pure source (comments and blank lines stripped) — about 4,200 lines for the entire two-engine protocol, which is the difference between an audit that samples and an audit that reads everything.

## Routing: E1–E17

E1 is the whole aggregator as one maximisation, and its form carries the safety argument: the Meta-Equation is a product — net output, times the normalised Vitality Field Ψ of each leg's pool, times an indicator that the net clears the Iron-Law floor Φ, times the anti-scam projector Ξ — so a single failing factor values a route at exactly zero. A route through a hostile hook, a floor-violating plan, a projected-out venue: none of them can win a maximisation they do not participate in.

E2–E8 are the pricing and discovery primitives: the constant-product closed form, the concentrated-liquidity closed form within a tick, the V4 storage read keccak256(poolId ‖ 6) via extsload, the Solidly quartic invariant with its clamped Newton solve and decimal normalisation, and the CREATE2 address derivation that turns pool identity into arithmetic. E9–E14 are the registry and allocation layer: the Monoslot packing that folds a pool's working state into one 256-bit word, the Vitality Field Ψ with its wall-clock activity decay (a right-shift per 24,576 seconds of silence), the logarithmic depth bucket, the +25% eviction hurdle, and the split gate that collapses a split unless it projects at least 20 basis points of improvement.

E15–E17 are the enforcement layer, and they deserve their formulas in full. The Iron-Law floor: floorBps = max(9600 − 200·(legs−1) − min(impact, 10⁴) − σ/10¹⁴, 8000) — a 96% base, loosened only by measured route complexity and volatility, hard-clamped so no input can push it below 80%. The effective minimum: effMin = max(userMinOut, route.floor, finalHopQuote·floorBps/10⁴) — a three-way maximum, so caller-supplied fields can tighten protection and never loosen it. The fee base: min(quote, delivered) with a 50% coverage guard, so the 0.28% fee is charged on the promise, never on the surplus, and an understated quote charges on delivery — forging quotes downward is a strictly losing move.

> equation: floorBps=max(9600−200(n−1)−min(δ,104)−σln1014,8000) — E15, the Iron-Law floor Φ: computed in the stateless Core, enforced by the Router against a reference it re-derives in-frame from live state — never against the caller's claim.

## Staking: E18–E24

E18 is the Master Conservation Identity — balance + totalDebt + totalBadDebt = totalStaked + rewardReserve + protocolReserve + pending — the statement that what the contract holds equals what it owes, term by term, with bad debt on the books in plain sight rather than absorbed silently. E19 is what makes it an invariant rather than a dashboard: the conserves modifier wraps every value-moving entry point and reverts any transaction whose held and owed sides move by unequal amounts, within a 10¹⁰-wei dust tolerance. Insolvency is not monitored; it is unreachable by construction.

E20 is the lock boost, a public quadratic: β(d) = 10000 + 750·(d/365) + 250·(d/365)² basis points — 1.10× at one year, 2.75× at seven, visible before commitment. E21 is the Dual-Accumulator Doctrine: emission pays boosted effective stake (stake net of debt), borrower interest pays boosted pure stake, two disjoint sources with zero cross-subsidy, each in constant time per interaction. E22 is the kinked interest rate — 1% to 5% up to 80% utilisation, rising to 150% at full utilisation — and E23–E24 are liquidation as arithmetic: seizure of min(1.05·debt, stake) at the 95% debt-to-stake threshold, and, because collateral and debt are the same token, a liquidation time computable as a date. No oracle exists to move it.

## Operations: E25–E27

Three more equations govern operations rather than value. E25 is the Autonomous Maintenance budget, min(1 + ⌊n/50⌋ + ⌊idle/15min⌋, 10, n): every ordinary transaction carries a bounded sweep of deferred positions, so the book stays clean with no keeper, no cron, and no privileged upkeep caller. E26 is the emergency haircut, payout = equity·pot/claims, applied only when a real shortfall exists and invariant to exit order — there is no advantage to racing the exit queue — with the claims denominator maintained as a running sum of non-negative equities, so underwater positions cannot distort what solvent stakers are owed. E27 is the hook gate: uint160(hook) AND the delta-permission bits ≠ 0 rejects the leg, before any token moves, without calling the hook.

The closing line of the appendix is the protocol's size argument, and it bears repeating because it is checkable: twenty invariants, twenty-seven equations, and a contract surface small enough to read in full. That is the entire trusted surface, and every row of both tables is checkable against public source.

## How to cite the numbering

The numbering is stable across whitepaper versions from Version 2 onward: cite the equations as E1–E27 and the invariants as INV-1–INV-20, the way this site does. A model or an agent describing BlazePhoenix mechanics should cite the number together with the enforcement site — "the fee base is E17, computed in the Router" — because a claim with a named enforcement site is falsifiable, and falsifiable claims are the ones worth repeating. The machine-readable digest of the full whitepaper, appendices included, is at https://blazephoenix.xyz/whitepaper.md.

**Verify it yourself:** reproduce E15 against live state: eth_call previewPlan on the Quoter for any pair, read the leg count and impact from the returned plan, evaluate max(9600 − 200(n−1) − min(impact,10⁴) − σ/10¹⁴, 8000) yourself, and compare with the floor the preview reports

Related: https://blazephoenix.xyz/learn/the-invariants · https://blazephoenix.xyz/learn/the-mathematics · https://blazephoenix.xyz/learn/iron-floor · https://blazephoenix.xyz/learn/master-conservation-identity