Longfellow ZK Enters an IETF Adoption Call—Treat the Draft as a Moving Interface

Google’s Longfellow ZK proposal has reached a more consequential stage than a routine repository update: draft-google-cfrg-libzk-03 entered a two-week IETF Crypto Forum Research Group adoption call on September 25, with the call scheduled to close on October 9, 2026.

The proposal describes a succinct non-interactive zero-knowledge argument built by combining MPC-in-the-head techniques from Ligero with a sumcheck-based verifiable-computation protocol. The draft focuses on a model without a trusted setup and on constructions that can be instantiated from a collision-resistant hash function. Its protocol also defines transcript and serialization behavior, circuit constraints, Fiat–Shamir challenge extraction, and proof encoding—exactly the details that become integration boundaries for application developers.

The adoption message positions Longfellow for constrained devices and lists practical statements such as ECDSA, SHA-256, and ML-DSA signature verification, along with string, integer, date, and basic parsing checks. The public repository presents the implementation as a C++ library for zero-knowledge protocols around identity formats including ISO mDOC, JWT, and W3C Verifiable Credentials. That combination makes the project relevant to privacy-preserving credentials, but it does not make the draft a drop-in standard for ICP canisters.

For ICP builders, the immediate engineering takeaway is interface discipline. If a canister or off-chain service experiments with Longfellow, keep the verifier behind a versioned adapter; pin the exact draft, circuit definition, hash profile, and proof encoding; and store the statement or circuit identifier alongside each proof. Do not assume that a proof generated against draft -03 will remain compatible with a future adopted document. A canister should also treat public-input ordering and byte serialization as consensus-sensitive data, because a cryptographically valid proof can still fail at the application boundary when two implementations encode the same statement differently.

Editorial caveat: Longfellow ZK is still an individual Internet-Draft with no formal IETF standing, and the current adoption call is scheduled to close on October 9, 2026. The proposal and its interfaces may therefore change. Claims in the adoption message about existing deployments and external implementations are reported there; they should be independently assessed before production decisions.

The timely development is not standardization completed—it is standardization becoming an active compatibility risk. Builders can evaluate the design now, but production architecture should preserve room for a changing proof interface.