What was actually proved
Formal verification is a narrower claim than it sounds like in a headline. It does not mean a program has no bugs. It means a mathematical proof shows the program satisfies a written specification, and a checker confirms the proof follows.
On that definition, the scope here is substantial. The properties are the ones designed to limit damage when keys are exposed: forward secrecy, authentication, post-compromise security and handshake secrecy, including the handshake's post-quantum component. They are proved about the compiled code under the paper's stated assumptions; the underlying primitives are assumed secure in one proof model and idealized in the other, not proved. The proofs are stated over the compiled machine code rather than over a model of the protocol drawn on paper, the level at which the earlier work the paper surveys operated.
That distinction is the real news. A protocol design can be sound while the code that ships it is not, and the gap between the two is where implementation bugs live. Proving properties of the unmodified implementation, as compiled by the standard Rust compiler, closes more of that gap than another proof about an abstract model would.
What the proof still requires readers to trust
A Lean-checked proof cannot be faked by a confident model. If a step does not follow, the kernel rejects it. Kernel acceptance establishes that the proof is valid for the statement as written, which is why the statement itself carries the weight, and why the reliability of the result does not depend on trusting the agents that wrote the proof. DeepMind's paper is direct about where trust moves instead.
It moves to the specification. The roughly 26,000 lines of statements, definitions and machine-code semantics define what security means for this code, and the paper states plainly that this part must be trusted and cannot be automatically checked. A specification that models a weaker attacker than intended, or states a property slightly different from the one users care about, would produce a valid proof of the wrong thing. The same applies to the assumptions underneath: the cryptographic primitives are treated as secure by assumption in one model and idealized in the other, some external routines are covered by contracts rather than proofs, and the AArch64 semantics the proofs reason over cannot itself be proved sound. The team kept that layer small and tested it extensively, which is the right mitigation. It is still a mitigation, not a removal.
DeepMind did test whether its specifications catch real mistakes. Reintroducing two previously fixed bugs produced binaries that provably violate the security theorems. The team also reports mutation testing, adding faults such as skipping the ciphertext MAC verification and showing the theorem fails, and vacuity checks, proving the theorems' hypotheses are jointly satisfiable and met by concrete executions. That is evidence the specification has teeth. It is not evidence that the specification says everything a user would want it to say.
One accounting note for readers comparing coverage: DeepMind's blog post gives two different totals in the same article, over six million lines of Lean in the body and over three million lines of machine-checked proof in its summary box. The technical paper's figure is about 6.5 million lines of machine-checked Lean proof code. This article uses the paper.
What this does not cover
The verified artifact is libsignal, Signal's reference implementation, compiled for AArch64 Linux and run inside a small harness the team built for the proofs. That is the right target for a first result of this kind, and it is also a specific one. The Signal app on a phone, and the other messaging apps that deploy variants of the protocol, involve more code, other platforms and layers this proof does not reach.
The four-week figure needs the same care. It is the elapsed time DeepMind reports for this verification process, with human experts guiding the specifications throughout; it is not a person-hour or cost figure. The paper argues that earlier tools would have required years of expert labor, and contrasts the result with famous verification projects that took years, including twenty person-years for the seL4 microkernel, but those projects verified different systems to different specifications, and the article provides no like-for-like cost or labor comparison. Specification writing, review and judgment remain human work, and the paper says so.
Why it is worth watching anyway
If this approach reduces total verification effort on other systems, the set of systems that can afford formal verification gets larger. Cryptographic libraries are the obvious first candidates: important enough to justify the effort, and unforgiving when an implementation detail is wrong. Medical device firmware and grid software are the examples DeepMind names next, and both sit in the same category.
The artifacts are public, so other researchers can inspect the specifications, rerun the checks and argue with the assumptions. That is the correct way for a claim of this size to enter the record, and it gives readers something better than a benchmark chart to judge it by.
Sources
- [1] Google DeepMind, "Formal Verification of Signal's Protocol with Gemini," November 10, 2026Read source
- [2] Google DeepMind, "AlphaProof Code: Verifying Signal's Security at the Machine-Code Level," technical paper and open artifacts, November 10, 2026Read source
- [3] Google DeepMind, "Gemini 4 Carbon is now available," November 10, 2026 (AlphaProof Code described as a Carbon use case)Read source