What happened
The GitHub repository describes an elaborated Cerberus Core for a program that runs a complete two-peer WireGuard Noise_IKpsk2 handshake through WireGuard’s own kernel code. The resulting program is represented as readable Lean modules and runs in Cerberus-Lean. The repository says the run reaches Defined with output identical to an independent reference implementation of the protocol. The Lean Core contains one module per WireGuard C file, with one definition per C function in source order; each definition quotes the corresponding C declaration and its file-and-line location.
The executable scenario is a test program in scenario/handshake.c. It sets up two peers with fixed keys using a small environment interface, then calls the API in noise.c directly. The recorded run covers initiation creation and consumption, response creation and consumption, and wg_noise_handshake_begin_session on both sides. It also exercises rejected, replayed and out-of-order messages, followed by key rotation. The program prints messages, chaining keys, hashes and transport keys, and checks that each peer’s sending key equals the other peer’s receiving key.
The repository says the expected output, excluding harness and debug-level printk lines, matches an independent Python implementation using pyca/cryptography across 42 observations. It also records execution results, timings and resource use. The C source included in the repository is identified as Linux revision 24a19b953e2a. The repository documents differences between that source and the executed program, including two lines associated with reported undefined behaviour, as well as several representation and access adjustments. A diff against upstream is included.
The execution models kernel services for memory, time, randomness, synchronization and printk sequentially. The repository reports undefined behaviour found in the C under a C semantics, and separately categorizes Cerberus and Cerberus-Lean limitations with reproducers. It provides the Core, runner, expected output and independent oracle in separate directories. The remaining files are released under GPL-2.0; files under linux/ retain their Linux kernel SPDX identifiers.
What the archive adds
New Runtime’s earlier coverage of EasyProver, on 2026-10-31, described a Lean proving system that reported results on PutnamBench and introduced a Rust-to-Lean benchmark. That note concerns model-driven theorem proving, while this is an executable elaboration of existing kernel code: a new fact on the broader Lean-and-verification thread, not a continuation of the same result. New Runtime also covered Linux kernel work on 2026-10-13, emphasizing inspectable patch-and-review processes. That note is related by the kernel context, not by this artifact’s formal-methods claim.
Trend signal
This does not yet fit a pattern New Runtime tracks. The repository is a specific formal-methods artifact, not evidence that agent systems are routinely producing inspectable scientific evidence, that agent protocols are converging, or that a general engineering bottleneck has shifted. Its explicit output comparison and scope description are useful qualities to watch for in future verification work, but one narrow release cannot establish a broader trend.
Why it matters
For a team responsible for protocol or kernel code, this repository makes the boundary of an executable model unusually visible: the source-derived functions, the deterministic path exercised, the observations emitted, the independent comparison, and the omitted behavior are all identified. That makes it a more useful reference than a bare claim that code has been “formally verified.” It can help teams ask what their own assurance case actually covers and what evidence would make a result reproducible.
The distinction matters operationally. Matching outputs across 42 observations supports confidence in this scenario; it does not establish correctness for every WireGuard execution or for the surrounding Linux networking stack. The work can inform how to structure a verification effort, but adopting the repository does not by itself verify a downstream build, configuration, concurrency behavior or deployment. Builders should treat the artifact as a bounded method demonstration and evaluate whether its assumptions match the code and risks they own.
Limits and uncertainty
The repository explicitly limits the result to one deterministic scenario. Cookies, rate limiting, transport data packets, timers, the network device and netlink configuration are not included. Kernel-service models are sequential and do not model kernel concurrency, although they retain data effects for allocation, reference counting, RCU publication and callbacks. The repository reports undefined behaviour and tool limitations, but the result does not establish the severity or security impact of those findings beyond what the artifact documents. The run is not an independent audit of all WireGuard code, nor does the repository claim a complete machine-checked correctness proof of the protocol or kernel implementation.
Reader takeaway
The useful signal is not simply that a kernel handshake can be represented in Lean. It is that the artifact reports a runnable scenario, a separate reference comparison, and concrete exclusions alongside the result. If you evaluate formal verification for production code, ask for those boundaries before treating a successful run as a whole-system guarantee.