Bend 2 vs. Lean 4 and Formal Proof Frameworks: Executable Test Engine, Differential Reference Oracle, and Proof Speed Compared

Why teams use Lean 4 for foundational metatheory and independent kernel receipts, while deploying Bend 2 for 0.38 s AI-agent proof loops, parallel execution, and dual-target (native + JS) differential test oracles.

Executive Summary

Bend 2 and Lean 4 have a symbiotic relationship. Bend 2’s affine dependent type theory (BendTT) is mechanically verified in 20,981 lines of Lean 4 (bend2/bendtt.lean) with zero sorry or admit tactics (bendtt.lean repository). That mechanization proves Church-Rosser confluence, subject reduction, progress, normalization, and logical consistency. Bend 2’s --verdict flag also exports proof obligations directly to the Lean 4 kernel (Tripartite Verification Stack).

When engineering teams verify application state machines or enforce invariant laws on AI coding agents, choosing between Lean 4 and Bend 2 has major consequences. That same choice governs how teams build differential test oracles for TypeScript, Rust, or Go services:

1. 50.5x Faster Proof-Checking Feedback Loop: On 3,200 generic proof instantiations measured on an Apple M4 Max, bend PROOF.bend completes in 0.38 s, compared to 6.0 s in Rocq and 19.2 s in Lean 4 (Kevin Ngo benchmark).
2. Multi-Core CPU and GPU Execution: Across all 16 Apple M4 Max runtime workloads in our ecosystem benchmark dataset, Bend 2 (PAR-CPU 16-core and PAR-GPU Metal) outperforms Lean 4’s compiled C backend by 6.4x to 219.8x.
3. Dual-Target Differential Test Engine (native + bun JS): A single proved .bend specification compiles to both a multi-core native binary (bend SMOKE.bend -o smoke) and a zero-dependency JavaScript module (bend SMOKE.bend -o smoke.js). Teams run differential conformance checks directly inside TypeScript/Bun/Node test suites without maintaining a separate model translator (Bend 2 Decision Guide).

1. Proof-Checking Speed and AI Coding Agent Ergonomics

When human engineers or AI coding agents synthesize code under formal constraints, verification latency determines whether formal methods can run inside the inner TDD loop.

Empirical Proof-Checking Benchmark (3,200 Generic Instantiations, Apple M4 Max)

Why Is Bend 2’s Proof Checker 50x Faster on Equational Laws?

Lean 4’s elaborator and tactic framework (simp, omega, rw, typeclass resolution over Mathlib hierarchies) solve classical mathematics, Quotient types, typeclasses, and arbitrary metaprogramming.

Bend 2 restricts its surface to structural induction, pattern matching, and beta-equality normalization ({==} and rewrite) over total, affine-typed terms (Proof-Blocked AI study):

# 1. Domain implementation (settlement.bend)
type Ratio is Data:
  FourToOne{}
  ThreeToOne{}
  TwoToOne{}

def required_input(ratio: Ratio) -> Nat:
  match ratio:
    case FourToOne{}: 4n
    case ThreeToOne{}: 3n
    case TwoToOne{}: 2n

# 2. Human-locked invariant law (LAWS.bend)
def Law_PositiveRate(r: Ratio) -> Type:
  all r: Ratio, Nat.is_ge(required_input(r), 2n) == True{}

# 3. Machine-checked inductive proof (PROOF.bend)
def proof_positive_rate(r: Ratio) -> Nat.is_ge(required_input(r), 2n) == True{}:
  match r:
    case FourToOne{}: {==}
    case ThreeToOne{}: {==}
    case TwoToOne{}: {==}

Splitting r with match reduces every branch by pure computation to True{} == True{}. The {==} reflexivity primitive discharges each branch in microseconds without tactic search or typeclass backtracking.

2. Using Bend 2 as a Formal Test Engine Instead of (or Alongside) Lean 4

Many engineering teams assume that using a formal proof language requires rewriting their production backend in that language. In practice, one of the most effective architectures uses Bend 2 purely as a formal test engine and differential reference oracle for an existing TypeScript, Rust, or Python application.

How the Bend 2 Test Engine Architecture Works

Consider a complex state-machine domain such as a multi-phase strategy rules engine, an order-book settlement kernel (pareto-frontier), or an OAuth2/PKCE state machine (oauth2-fsm in bend2-packages):

1. Keep the Production Service in TypeScript or Rust: Your existing WebSocket server, database handlers, and UI clients remain in TypeScript or Rust.

2. Author the Normative Rules and Laws in Bend 2:

   • actions.bend, lifecycle.bend, and topology.bend encode the pure transition rules.
   • LAWS.bend pins invariant contracts (conservation of resources, turn-phase admission, and explicit rejection of underflow/overflow).
   • PROOF.bend discharges every law in 0.38 s via bend PROOF.bend (benchmark).

3. Compile SMOKE.bend to Both Native CPU and JavaScript (.js):

   # Verify all inductive proofs first
   bend formal/bend2/domain/PROOF.bend
   
   # Compile the smoke & oracle suite to both native binary and JS
   bend formal/bend2/domain/SMOKE.bend -o "$OUT/smoke"
   bend formal/bend2/domain/SMOKE.bend -o "$OUT/smoke.js"
   
   # Verify deterministic parity across 1-thread CPU, 4-thread CPU, and Bun JS
   "$OUT/smoke" +RTS --gpu off --threads 1 -RTS > "$OUT/cpu-1.txt"
   "$OUT/smoke" +RTS --gpu off --threads 4 -RTS > "$OUT/cpu-4.txt"
   bun "$OUT/smoke.js" > "$OUT/js.txt"
   diff -u formal/bend2/domain/SMOKE.expected "$OUT/cpu-4.txt"
   diff -u formal/bend2/domain/SMOKE.expected "$OUT/js.txt"

4. Run Differential Trace Comparison (compare.bend) Against Production: The Bend 2 oracle ingests state-transition rows emitted by the production TypeScript/Rust test suite (before_state, action, observed_decision, observed_after_state) and outputs a machine-readable JSON verdict:

   • {"version":1,"verdict":"conformant","modelDecision":"granted"}
   • {"version":1,"verdict":"divergent","modelDecision":"denied","cause":"decision"}
   • {"version":1,"verdict":"divergent","modelDecision":"granted","cause":"state"}

Why Teams Prefer This Over a Standalone Lean 4, Goose, or TLA+ Test Harness

Open-source projects in our ecosystem directory already use this exact pattern, including Dicklesworthstone/beads_bend and Dicklesworthstone/toon_bend (368 machine-checked laws verified across 4 parallel lanes). Bend 2 lets you maintain one executable specification that serves as both your formal proof artifact and your differential test runner.

3. Lessons from Anthropic’s 13-Million-Line Lean Formalization, 180-Million-Line Rocq Study, and Proof-Blocked AI

In late August and September 2026, Anthropic announced that Claude had completed the first machine-checked formalization of Fermat’s Last Theorem (FLT) in Lean 4 (anthropics/fermats-last-theorem). The repository spans 13 million lines of Lean 4 and mechanically verifies 29,500 intermediate lemmas on top of Mathlib 4 (Anthropic FLT research). On October 22, 2026, Anthropic and Theorem also published “LLMs are making formal software verification feasible at a much larger scale”, verifying 239 OSS-Fuzz targets in 180 million lines of Rocq. Read our standalone analysis in Anthropic’s 180-Million-Line Formal Verification Milestone: Why Bend 2 Was Invented for Exactly This.

Our verification series on gerryburde.com (Part 1: Machine-Checked Proofs and Part 3: Bend 2 and Proof-Blocked AI) analyzed Anthropic’s Lean milestone. It revealed both the breakthrough and the operational bottleneck of using Lean 4 with AI coding agents:

1. The Breakthrough (The Micro-Kernel Loop): Frontier LLMs hallucinate subtle edge cases when prompted in natural language, but excel when paired with a deterministic proof kernel that rejects invalid steps.
2. The Bottleneck (13 Million Lines of Verbosity & 19.2 s Tactic Latency): Anthropic’s 13 million lines of Lean 4 reflect machine tactic verbosity and deep Mathlib dependency chains. When an AI coding agent edits ordinary application code (such as a state machine, parser, or ledger), waiting 19.2 s per lake build check and debugging fragile stateful tactic scripts (simp, omega, rw) breaks inner-loop velocity (Kevin Ngo benchmark).
3. Specification Risk Relocated (Why Laws Must Bind): Both Anthropic’s FLT documentation and our Bend 2 Proof-Blocked AI experiments demonstrate the foundational rule of formal methods. A formal proof guarantees only that the encoded conclusion follows from the encoded assumptions. In our Bend 2 sort experiment, a law stating only is_sorted(sort(xs)) == True{} allowed an AI agent to return an empty list [] and pass "All terms check." Teams must write the law pair (is_sorted and is_permutation). They must also guard LAWS.bend with fail-closed CI checks that reject @unsafe and mutation-test laws against known-bad code (Proof-Blocked AI field guide).

4. Bend 2 vs. MIT PDOS Goose, Verus, Kani, and Dafny

How does Bend 2 compare against other code-verification frameworks like MIT PDOS Goose (github.com/tchajed/goose), Verus, Kani, and Dafny?

• MIT PDOS Goose (Go to GooseLang in Rocq/Perennial/Iris or Lean 4): Goose translates a restricted subset of Go (structs, pointers, locks, fork) into GooseLang models (MIT PDOS Goose). Researchers use it to prove crash safety and concurrent separation logic invariants in Rocq (Perennial/Iris) or Lean 4. Goose is purpose-built for verifying stateful POSIX filesystems, write-ahead logs, and lock-based storage servers in Go. However, Goose proofs require heavy interactive separation-logic engineering (6.0 s to minutes per build) and cannot compile algorithms to GPUs.
• Verus & Dafny (SMT-Backed Verification): Offload proof obligations to external Z3/cvc5 SMT solvers. When an SMT query hits quantifier instantiation limits (“spurious timeout”), AI coding agents get stuck without a constructive counterexample.
• Bend 2 (LAWS.bend + PROOF.bend): Eliminates the translation gap because you prove the exact .bend file you compile. Unlike Dafny or Verus, proofs check deterministically by beta-reduction in 0.38 s with zero SMT solver timeouts (benchmark dataset).

5. Runtime Performance: All 16 Apple M4 Max Benchmarks (Bend 2 vs. Lean 4)

Lean 4 includes a functional-to-C compiler with reference-counting reuse (FBIP, Functional But In-Place). On purely sequential, single-core recursive code (SEQ-CPU), Lean 4 and sequential Bend 2 are often within 1.1x to 2x of each other (ecosystem benchmark dataset).

However, Lean 4 does not automatically parallelize recursive tree reductions across CPU cores or compile functional code to GPU warps. Across all 16 benchmarks in our ecosystem benchmark dataset on an Apple M4 Max:

Notice the two honest nuances in the table above (ecosystem benchmark dataset): 1. On 1-core sequential execution (SEQ-CPU), Lean 4’s FBIP allocator beats sequential Bend 2 on pointer-heavy hashmap (1.526 s vs 2.741 s), symreg (2.457 s vs 3.014 s), and nbody (5.387 s vs 5.758 s). 2. Once Bend 2 enables 16-core PAR-CPU or PAR-GPU, it beats Lean 4 across all 16 benchmarks. Speedups range from 6.4x to 47.7x on multi-core CPU and up to 219.8x on GPU (dataset).

6. Where Lean 4 Still Wins (and Why We Use Both)

Bend 2 does not replace Lean 4 in every domain. Choose Lean 4 directly when:

1. You Need Classical Mathematics or Mathlib: Bend 2 is built for constructive, structural induction over algebraic data types and finite machine integers/trees. If your proof requires real analysis, measure theory, algebraic geometry, or number-theoretic lemmas from Mathlib (like Anthropic’s 13-million-line Fermat’s Last Theorem formalization), Lean 4 is unmatched (Anthropic FLT repository).
2. You Are Proving Programming Language Metatheory: HigherOrderCO proved Bend 2’s own type soundness and Church-Rosser confluence (bend2/bendtt.lean) in Lean 4 (bendtt.lean formalization).
3. You Require an Independent Kernel Audit Receipt: In high-assurance release gates, we run bend PROOF.bend for fast 0.38 s developer/agent feedback during implementation. At release closeout, we invoke bend --verdict (or standalone Lean 4 receipt verification checking #print axioms) in CI so the final proof obligation is certified by the Lean 4 kernel (Tripartite Verification Stack).

7. Decision Matrix: When to Choose Bend 2 vs. Lean 4, Goose, or Cedar