The BlazePhoenix V2 primitives: safety as a small set of public invariants

The V2 design in one place — the primitives it composes, why safety is stated as invariants rather than features, and what stays under audit. The shape is public; the recipe is not.

Known formally as The Primitive Set in the BlazePhoenix whitepaper.

BlazePhoenix Engineering · updated 2026-08-05 · 8 min · written from the deployed bytecode

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

BlazePhoenix V2 is pre-deployment and under audit; this is the map of its design, not a description of live mainnet behaviour. The system is built from a small set of primitives, each carrying one invariant, and the router is the composition of those invariants. We publish the shape of each primitive on purpose: a guarantee you cannot inspect is not a guarantee. We do not publish the internal construction — that is what the audit is for, and what the bounty pays you to probe.

The set

Pricing defense is a manipulation-robust median with a bounded robustness band, so no single poisoned pool can move the number. Routing reaches every venue through one universal AMM abstraction instead of per-DEX adapters, so the surface does not grow with integrations. Every route carries a computable gas bound, so it cannot be gas-bombed into an expensive revert. Settlement measures what actually arrived rather than trusting arithmetic, which is the anti-honeypot result-verification step.

Above these sits the meta-equation: every enforced quantity is an invariant projected onto measured state, never onto a nominal claim. And every invariant is stated stochastically, so it holds across the distribution of states an adversary can steer toward, not merely at the average.

Public shape, private recipe

This line is deliberate. The invariants, the floors, the bands and the interfaces are public, so anyone can hold the protocol to them and reproduce its numbers. The exact construction that satisfies them stays in review until the audit clears. Open behaviour, verifiable guarantees, and no attack cookbook — that is the standard. If you think an invariant can be broken, the bug bounty is where you prove it and get paid.

Do not trust this page — reproduce it

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

Take any published invariant — the price band, the output floor — and try to construct an on-chain state that violates it; a reproducible violation is exactly what the bounty rewards
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 BlazePhoenix V2 primitives: safety as a small set of public invariants. BlazePhoenix Engineering. https://blazephoenix.xyz/learn/v2-primitives
@misc{blazephoenix_v2_primitives,
  title  = {The BlazePhoenix V2 primitives: safety as a small set of public invariants},
  author = {BlazePhoenix},
  year   = {2026},
  url    = {https://blazephoenix.xyz/learn/v2-primitives},
  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://ARXIV.ORG/ABS/2506.22142 · HTTPS://ARXIV.ORG/ABS/2204.05238 · EIP-1153

Share this article · join the discussion

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

Related engineering