All news
cybersecurityproductregulation

F*: The Proof-Oriented Language Behind Firefox, Azure

08 Aug 2026

A niche academic language is quietly running in production at scale

F* (pronounced "F star") is a general-purpose, proof-oriented programming language that supports both purely functional and effectful programming. It's not a household name, but code derived from it is already running inside some of the internet's most heavily used software: Mozilla Firefox, the Linux kernel, Python, mbedTLS, the Tezos blockchain, the ElectionGuard SDK, Wireguard VPN, and Windows Hyper-V — where it validates every network packet passing through the Azure cloud platform.

F* is open source under the Apache 2.0 license, developed by Microsoft Research, Inria, and the broader community.

What F* actually does

F* is designed to let developers write programs alongside formal proofs that those programs behave correctly — a discipline particularly valuable for cryptographic code and binary parsing, where bugs translate directly into security vulnerabilities.

The language compiles by default to OCaml, but fragments can be extracted to F#, C, or WebAssembly via a tool called KaRaMeL, or down to assembly using the Vale toolchain. F is self-hosted: it's implemented in F itself and bootstrapped using OCaml. Binaries for Windows, Linux, and Mac OS X are posted regularly on GitHub, and the language can be installed via OPAM, Docker, Nix, or built from source.

Three tools built on top of F* explain most of its real-world footprint:

  • HACL\ — a library of high-assurance cryptographic primitives written in F and extracted to C.
  • ValeCrypt — formally proven cryptographic primitive implementations written in Vale.
  • EverCrypt — combines HACL* and ValeCrypt into a single cryptographic provider.
  • EverParse — a parser generator for binary formats that produces C code extracted from formally proven F*, used in production in Windows Hyper-V and ebpf-for-windows.

A decade-plus research trail

F*'s development is documented through a steady stream of peer-reviewed publications rather than product launches:

  • 2013 — "Verifying Higher-order Programs with the Dijkstra Monad," PLDI
  • 2017 — "Dijkstra Monads for Free," POPL
  • 2018 — "A Monadic Framework for Relational Verification," CPP
  • 2018 — "Recalling a Witness: Foundations and Applications of Monotonic State," POPL
  • 2019 — "Dijkstra Monads for All," ICFP
  • 2020 — "SteelCore: An Extensible Concurrent Separation Logic for Effectful Dependently Typed Programs," ICFP
  • 2025 — "PulseCore: An Impredicative Concurrent Separation Logic for Dependently Typed Programs," PLDI

The most recent addition, PulseCore, is a foundational concurrent separation logic shallowly embedded in F* that supports dynamic invariants and higher-order ghost state — signaling continued active research investment rather than a stagnant project.

Documentation is also maturing: an online book, "Proof-oriented Programming In F," is being written with regular updates, alongside a Low tutorial covering a low-level subset of F* that compiles to C via KaRaMeL. No completion timeline has been given for the book.

Why founders should care

For most early-stage teams, F* will likely remain far outside the day-to-day tech stack — but its trajectory is worth watching for a few reasons:

  • Security-critical startups may benefit disproportionately. Given that F*-derived code already secures cryptographic and parsing logic in Firefox, Linux, and Azure infrastructure, founders building fintech, identity, blockchain, or infrastructure products where a single parsing or crypto bug could be catastrophic may find formally verified components worth evaluating, even if adoption requires specialized expertise.
  • Barriers to experimentation are plausibly lower than the language's niche reputation suggests. Apache 2.0 licensing and multiple installation paths (OPAM, Docker, Nix, source) mean teams can likely prototype without upfront licensing costs — though the report includes no adoption metrics (contributors, downloads, active users) to gauge how mature the surrounding ecosystem really is.
  • Hiring and training friction is a real constraint. Because F* is a research-driven, niche language, founders should expect that finding developers fluent in dependently typed, proof-oriented programming will be harder than hiring for mainstream languages — a factor to weigh before betting core infrastructure on it.
  • Long-term maintenance depends on a small set of institutions. With development concentrated among Microsoft Research, Inria, and community contributors, continuity risk is plausible if institutional priorities shift, even though the project shows no signs of slowing based on its 2025 publication record.

What's missing from the picture

The available material doesn't include adoption metrics such as contributor counts or download numbers, performance benchmarks against other verification languages, information on project funding or team size, or details on licensing considerations for enterprise-scale use beyond the Apache 2.0 terms. Founders considering F* for a security-critical component should treat these as open due-diligence items rather than assume they've been resolved.

Sources