Akita Moves Post-Quantum ZK Verification Work Off the Critical Path

A new ZK primitive is targeting one of the least visible costs in post-quantum proving: verification. On September 9, LayerZero introduced Akita, a lattice-based polynomial commitment scheme designed for zero-knowledge systems that need quantum-resistant assumptions without accepting very large proofs.

Polynomial commitments sit below many proving systems. They let a prover commit to a computation-related polynomial and later prove evaluations of that polynomial. Akita’s paper argues that existing lattice-based approaches often achieve only two of three deployment goals: compact proofs, fast verification, and security based on standard assumptions such as Module-SIS. Akita is designed to address all three.

Its main architectural idea is setup offloading. Instead of making the verifier process all public setup matrices directly, Akita commits to those matrices ahead of time and proves the relevant setup computation against the commitments. The paper describes this as a way to reduce verifier work while preserving logarithmic proof size. Akita also includes batched openings, distributed-proving support, and an offline planner for selecting parameters under configurable cost objectives.

The published benchmark numbers are notable but should be read as research results, not guarantees. The paper reports proofs of 61–70 KB and verification that is 10× to 94× faster than the compared lattice-based system, Greyhound, at the same stated security level. In an integration with Jolt, the authors report a 1.3× to 2.2× prover speedup and a 2.2× to 7.4× verifier speedup over Jolt using Dory, with proofs remaining below 100 KB in the evaluated programs.

For ICP and other application developers, the important point is not that Akita is ready to drop into a canister. It is that proof-system choices increasingly expose a separate verifier budget. A design that improves proving throughput but leaves verification expensive can still constrain on-chain verification, browser verification, or cross-service proof checking. A compact proof is useful, but the cost of preparing and checking the commitment structure can determine whether a proof fits a real application’s latency and compute envelope.

There is also a maturity boundary. Akita is presented as an open-source primitive whose first major deployment is intended for Jolt, but the Jolt repository currently describes Jolt as alpha and not suitable for production use. The announcement does not establish an ICP integration, an independent security audit, or production readiness. Those are separate questions that builders must verify before treating the implementation as infrastructure.

The actionable takeaway is to benchmark the whole verification path, not just proof generation. For any proposed ICP-facing ZK workflow, record proof size, verifier time, memory, parameter assumptions, setup handling, and the exact implementation version. Akita’s contribution is a reminder that post-quantum ZK engineering is not only a cryptographic-assumption migration. It is also a systems problem in which the verifier’s workload must be designed, measured, and bounded.