Bankai

Bankai is building the light client infrastructure layer it believes cross-chain interoperability has been missing: a stateless, proof-based system that makes any blockchain's finalized state verifiable anywhere, without requiring custom contracts, ongoing maintenance, or chain-specific deployments. The project's design philosophy is stated plainly on its homepage — "We don't create consensus, we compress it" — and that compression is the core technical bet.

The Problem with Existing Light Clients

Light clients have long been positioned as the trust-minimized alternative to relying on centralized bridges or honest validators. Earlier ZK-powered approaches, such as Plumo and Telepathy, meaningfully reduced the on-chain computation needed to verify consensus, but they did not eliminate on-chain state. Teams using those systems still had to deploy a smart contract on every destination chain they wanted to support, then continuously submit sync transactions to keep each contract's view of the source chain current. The cost scaled with the number of destinations, not with actual usage. Every new chain meant another deployment, another state silo, and another perpetual update stream.

Bankai's answer is to remove on-chain state entirely from the equation. Rather than storing a validator committee or beacon chain header in contract storage, Bankai accumulates that trust inside a chain of recursive proofs. Each proof certifies four things: that the previous proof was valid, that the previous trusted state was sound, that the next finalized transition is valid under the source chain's rules, and that the resulting trusted state is now the proof's public output. There is nothing to store. Verification is on demand.

How the Stateless Model Works

The research paper published by Bankai's founder, Paul Etscheit, formalizes the design. The system is initialized once from a trusted checkpoint — a weak-subjectivity assumption standard in Ethereum light client design — and then carries trust forward cryptographically. New verifiers do not need to replay history; they verify the current recursive proof, which already encompasses all prior finalized transitions.

The ZK circuits are written in Cairo and proof generation runs through the Atlantic Prover (StarkWare's SHARP infrastructure). BLS signature verification — the most expensive component of any Ethereum beacon chain light client — is handled via the Garaga library, accounting for roughly 5 percent of total circuit steps. A standard epoch proof currently requires approximately 4.3 million Cairo steps and takes around 9.6 minutes to generate on SHARP production infrastructure. Sync committee update epochs, which occur every 256 Ethereum epochs and require hashing 512 public keys, spike to about 8.8 million steps and 23 minutes.

That proving latency is the acknowledged gap: Ethereum's epoch time is 6.4 minutes, so Bankai cannot yet maintain a real-time one-to-one cadence. The mitigations are sequential proving every k-th epoch rather than every epoch, and migration to the next-generation S-Two prover. Benchmark data in the paper shows S-Two on an M4 Max laptop generating a non-recursive epoch proof in 13 seconds versus 266 seconds on SHARP — a roughly 20x acceleration — though recursive S-Two is not yet available due to an immature in-circuit verifier.

Bankai Blocks: the Proof Structure

The verified state is organized into a data structure called a Bankai block. These are not blocks in any conventional blockchain sense — there is no consensus, no mempool, no gas. A Bankai block is a sealed snapshot of everything the system has verified up to a given point, committed by a ZK proof.

Each Bankai block links to its predecessor via a hash and contains four commitment sections. The Bankai MMR (Merkle Mountain Range) accumulates all prior Bankai blocks into an append-only structure, available in both Keccak-256 (EVM-compatible) and Cairo Poseidon2 (ZK-friendly) variants. The beacon client section captures Ethereum beacon state: slot, header root, state root, justified and finalized heights, sync committee signer counts, and validator roots. The execution client section captures the Ethereum execution layer: block number, header hash, and finality data, along with per-block MMRs that enable MPT proofs over accounts, storage, transactions, and receipts. The OP chains section commits to multiple OP Stack chains under a single Merkle root, each with their chain ID, block number, header hash, and a link back to the L1 submission block that anchors OP finality.

To verify specific data, a consumer walks the tree: verify the Bankai block proof to get a trusted block hash plus all commitments, select the appropriate MMR root, prove header inclusion via the MMR, then verify account or storage data against that trusted header via a Merkle Patricia Trie proof.

Developer Interface

The Bankai SDK provides two Rust crates: one for querying the Bankai API and constructing proof bundles, one for verifying results. A proof bundle packages a block proof, a header proof, and a data proof into a single verifiable object. Bundles can be verified on-chain, client-side, or inside a zkVM — in the latter case, Bankai verification runs inside the zkVM to produce a Groth16 proof over the trustless data, enabling composition with other ZK applications. An API client allows direct HTTP access to raw proofs and chain data for builders who want lower-level access.

Roadmap and Solana

Bankai's public roadmap runs in four phases. Phase 01, currently in progress, targets Ethereum mainnet in Q2 2026: a live v1 deployment providing stateless access to both the execution and beacon layers. Phase 02, in planning for Q3 2026, adds Ethereum L2 light clients to extend the proof surface to OP Stack chains already partially supported in the block structure. Phase 03, in exploration for Q4 2026, brings Tendermint-based L1 chains into the same proof interface. Phase 04, also in exploration and targeted for Q2 2027, is Solana integration via the Alpenglow consensus mechanism.

Solana's Alpenglow protocol introduces Rotor and Votor, a two-layer consensus design built for low-latency finality. From Bankai's perspective, a PoS chain with deterministic finality and verifiable committee selection maps onto the same stateless recursive proof model already proven on Ethereum. The Solana integration is the furthest milestone on the roadmap and the least defined technically, but the architecture is intentionally general — the paper explicitly positions the design as applicable to any PoS chain with those two properties.

Team and Backing

The project is led by Paul Etscheit, the sole named author on the research paper ([email protected], GitHub: petscheit). Acknowledged support comes from Herodotus, which provided research access and prover infrastructure; the Garaga team, who built the Cairo elliptic curve libraries central to Bankai's BLS verification; Filip Krawczyk, who contributed recursion complexity modeling; and StarkWare. No formal funding rounds have been announced.

The GitHub repository — github.com/petscheit/bankai — contains the Cairo circuits, Rust client, and Starknet smart contract. It is an early-stage public presence with roughly 300 commits, consistent with the project's founding date of May 2025 and a roadmap that still has its first mainnet deployment upcoming.

Bankai is building toward a world where verifying finalized state on any supported chain is reduced to a single proof check — no bridge trust assumptions, no infrastructure overhead, no per-chain deployment tax.