Creusot Devlog

Creusot 0.11.0: VerifyThis winner

2026-04-20T00:00:00+00:00

Welcome back to the devlog of Creusot, a tool for proving Rust programs correct.

New website</h1>

If you are curious to know what this project is about, check out Creusot's new website! creusot.rs</a>

It presents what Creusot is, its main features, and links to resources. Also new is a list of publications related to Creusot.

Last week, the Creusot team went to the ETAPS conference in Turin. The main two events we attended were the VerifyThis challenge and the RustVerify workshop. This release was delayed to prepare for the RustVerify talk.

VerifyThis 2026</h1>

VerifyThis</a> is a program verification competition. It's similar to a programming competition but instead of passing test cases, the goal is to prove that programs satisfy given specifications using your favorite verification tool.

Solutions will be judged for correctness, completeness, and elegance. </blockquote>

Jacques-Henri Jourdan and Li-yao Xia participated to this year's VerifyThis as a team (The Steelmakers) using Creusot.

We are happy to report that we got the Best Overall Team award!

It was a nice opportunity to see what it's like to use the tool we've been working on. Our tooling didn't cause issues—except for one isolated bug in #[bitwise_mode]</code>—so we could quickly focus on the challenge. The concurrency problem (Challenge 2) was the perfect use case for ghost permissions, a feature presented in Creusot earlier this year (CPP 2026</a>) and originally in Verus (OOPSLA 2023</a>).

VerifyThis challenges are designed to be especially difficult, and participants are allowed to adapt the problem to fit tool limitations or time constraints—problem statements may even explicitly suggest possible simplifications. We are proud that Creusot enabled us to make a total of zero simplifications: we (tried to) verify the programs as written in the problem statements, for better or for worse.

Our solutions are available in the creusot-examples repository</a>.

RustVerify 2026</h1> The RustVerify workshop</a> included two talks directly connected to Creusot: Verifying the Rust standard library with Creusot, by Li-yao Xia et al., presented our ongoing effort at verifying slice functions in the standard library</a>. It uses a new "proof modes" feature which is work-in-progress and not part of the present release.</li> Supporting weak memory in Creusot and Verus, by Natalie Neamtu et al., presented new primitives for release-acquire and relaxed atomic accesses. On Creusot's side, they are available in this release. A proper write-up of how to reason about concurrency in Creusot is future work.</li> </ul> What's new in Creusot?</h1> No major new features this release; see the Changelog</a> for details. But big things are already lining up for next month. Stay tuned! Explicit binder for results</h2> It is now possible to name the result variable in postconditions: #[ensures(result@ == 0)] // default name `result` (old, still supported) #[ensures(|my_result| my_result@ == 0)] // explicitly named `my_result` (new) fn zero() -> usize { 0 }</code></pre> You can also destructure the result using patterns: #[ensures(|(_, b)| b@ == 42)] fn forty_two() -> (usize, usize) { (0, 42) }</code></pre>Collections should not be iterators</h2> A little something we learned about iterators in Rust. A collection type, like Vec</code>, typically comes with three iterators: an "owning" iterator (often named IntoIter</code> or Iter</code>), a "shared" iterator (Iter</code>), and a "mutable" iterator (IterMut</code>). Each of these iterator types is associated with the collection type via an IntoIterator</code> impl. My "genius" idea was that Seq<T></code>, Creusot's type of sequences of T</code>, could play the role of all three iterators for itself. I thought it would trivialize implementations of IntoIterator</code> for Seq<T></code>. This turned out to be a bad idea. Can you guess the problem in the following snippet? /* A bad idea in the making */ impl<T> Iterator for Seq<T> { type Item = T; fn next(&mut self) -> Option<T> { /* ghost code */ } } // Blanket impl from std impl<I: Iterator> IntoIterator for I { type IntoIter = Self; fn into_iter(self) -> Self::IntoIter { self } } impl<T> IntoIterator for &Seq<T> { type IntoIter = Seq<&T>; fn into_iter(self) -> Self::IntoIter { /* ghost code */ } } impl<T> IntoIterator for &mut Seq<T> { type IntoIter = Seq<&mut T>; fn into_iter(self) -> Self::IntoIter { /* ghost code */ } }</code></pre> If this were a regular type like Vec<T></code>, a simple reason against making Vec<T></code> into its own iterator is that it would be extremely inefficient: next</code> would remove the first element then shift all of the remaining elements over it in linear time. And the other "obvious" choice of defining next</code> as pop</code> would yield iteration in reverse order. Moreover, for borrowing iterators (Iter</code>, IterMut</code>), you don't want to allocate a whole Vec</code> of borrows, instead you want next</code> to return borrows on the fly without allocating anything. However, Seq<T></code> is a logic type: it is only present in ghost code to help verification (a key feature is that the length of Seq<T></code> is finite but unbounded, unlike Vec</code> which cannot contain more than usize::MAX</code> elements). Ghost code does not actually exist at run time so performance is of no concern. So what else went wrong? Simply put, the above code does not compile. The Rust compiler rejects the IntoIterator for &mut Seq<T></code> because it overlaps with the blanket implementation</a>: impl<I: Iterator> IntoIterator for I</code></pre> Indeed, since Seq<T>: Iterator</code>, we also have &mut Seq<T>: Iterator</code> via this impl</a>: impl<I: Iterator> Iterator for &mut I</code></pre> Furthermore, if you decided to stick with that blanket implementation, you would end up with a very confusing behavior: if you write a for</code> loop over &mut s</code>, you would expect to iterate over mutably borrowed elements &mut T</code>, but instead you would be consuming s</code> to yield fully owned T</code>! let s: Seq<T> = ...; for x in &mut s { ... } /* Here `s` would be empty! */</code></pre> Since this error was caught by the compiler and such code is intended for formal proof anyway, it wouldn't be so bad... if I hadn't already started doing exactly the same thing for FMap</code>, another of Creusot's logic types, in the previous release. I just happened to temporarily omit the IntoIterator for &mut FMap<K, V></code> which would have revealed this issue. Oops. I hurried to revert it</a> as soon as I realized the mistake. Thus Seq<T></code> (and other "logic types") now has distinct iterator types (IntoIter</code>, Iter</code>, IterMut</code>), which are mere newtype wrappers around Seq<T></code>, Seq<&T></code>, Seq<&mut T></code>. That was this month's (not so) hard-earned lesson: collections should not be iterators.

Creusot 0.10.0: February update 2026-02-24T00:00:00+00:00 What's new in Creusot?</h2> This February's release brings a couple of QOL improvements. For the rest, see the Changelog</a>. Assume (trusted asserts)</h3> The proof_assert!</code> macro now supports the #[trusted]</code> attribute. #[trusted] proof_assert! { answer == 42 };</code></pre> It removes the proof obligation that would come from the assertion, so it effectively becomes an assumption available to the rest of the program after it. We could have called it assume!</code> or proof_assume!</code>, but reusing #[trusted]</code> makes it convenient to grep for all assumptions in a project. This is useful as a placeholder à la todo!()</code>, letting you stub out parts of a proof while you're focusing on other aspects of it. Wildcard patterns on integers</h3> In match</code> expressions with integer patterns, the wildcard branch now remembers the values that the integer does not equal. match n { 42 => proof_assert! { n == 42 }, _ => proof_assert! { n != 42 }, // FIXED }</code></pre> Thanks to Eric Jackson for the contribution</a>! Multi-package workspaces</h3> We added options to select packages in workspaces. The command line option -p</code> (or --package</code>) selects a package to build with cargo creusot</code> and to run provers on with cargo creusot prove</code>. This is basically the same option as in cargo build</code>, but to call why3find</code> and run provers, we must additionally find the output Coma files corresponding to these packages. As the Creusot compiler is basically a modified rustc</code>, the unit of compilation is a crate. A package defines multiple crates, and cargo</code> does not build all of them by default: only libraries and binaries, excluding tests, examples, and benches. Creusot only supports that default target selection for now (that is libraries and binaries), until the need for others arises. You can also choose a default set of packages to build with cargo creusot</code>, using the default-member</code> field in the [workspace.metadata.creusot]</code> section of your workspace Cargo.toml</code>: [workspace.metadata.creusot] default-members = ["PKG1", "PKG2"]</code></pre> This falls back to the existing default-member</code> field in [workspace]</code> for regular cargo build</code>. Having a separate field for Creusot lets you designate packages specifically as targets for formal verification, next to other buildable but unverified packages. Story of a toolchain update</h3> Creusot depends on a nightly Rust toolchain. With this release, we upgraded our toolchain from nightly-2025-11-13 to nightly-2026-01-29. We do toolchain upgrades regularly to keep up with the fast-moving rustc</code> API. Ideally we do this at the beginning of each release cycle to give time to potentially subtle issues to surface by the next release. This time, there was one change that required a bit of thinking to deal with: the orphan check now panics when it encounters an unnameable type (typically, a function type). The orphan check and unnameable types</h4> The orphan check is what enforces "trait coherence" in Rust: that there is at most one implementation of a trait for any given type. The orphan check basically answers the question "might another crate implement this trait Tr</code> for this type Ty</code>?" In rustc</code>, this check is performed whenever you implement a trait. Since you must spell out the type for the impl</code> block, there is normally no way to encounter an unnameable type there (unnameable types are types of functions, closures, and coroutines). However rustc</code> did have an experimental feature "typeof</code>" which could cause the orphan check to encounter unnameable types, allegedly (I'm not familiar with the details). That feature was removed</a> in late November, and the now unreachable code in the orphan check that dealt with unnameable types was replaced with panics. In Creusot, we use the orphan check in the implementation of type invariants. This feature lets you specify a property that should be satisfied by all values of a type. For example, you can define a type of integers bounded by 42 as a struct</code> with an Invariant</code> impl: struct Bounded42(usize); impl Invariant for Bounded42 { #[logic] fn invariant(self) -> bool { pearlite! { self.0 <= 42usize } } }</code></pre> All functions that take a Bounded42</code> argument can assume the type invariant, and all functions that return a Bounded42</code> must prove the type invariant. Any type Ty</code> has a type invariant, which we determine as follows: if there is an instance Ty: Invariant</code>, that is a user-provided type invariant;</li> if there is definitely no such instance, then we fall back to a structural type invariant derived from the type definition (it basically says that all fields satisfy their type invariant);</li> if there is no instance Ty: Invariant</code> in this context, but we cannot rule it out definitely (an instance may appear after instantiating some type variables, possibly using implementations provided by an unknown crate), then the type invariant is an undefined predicate.</li> </ul> The orphan check is what distinguishes between the last two cases. Furthermore, because type invariants apply to all types, this also concerns unnameable types: for example if you pass a closure as an argument to a function, then Creusot will look for its type invariant, involving an orphan check. The update to the orphan check caused it to panic in this case. The fix is simple in hindsight: we replace unnameable types (function types) with the unit type ()</code> before invoking the orphan check. Indeed, these types should behave the same as far as the orphan check is concerned: both the unit type and function types from the current crate or its dependencies are "external types" from the point of view of a sibling or descendant crate. It is also possible to fix the orphan check in rustc</code> itself to not panic in those cases even though they don't happen within rustc</code>. But our workaround works and we just don't have an incentive to tinker with it further, at least until that becomes a bigger issue. Creusot 0.9.0: Launching the Creusot Devlog 2026-01-19T00:00:00+00:00 Begin Devlog</h2> Welcome to the Creusot Devlog, where we blog about the development of Creusot project, a deductive verifier for Rust. Creusot helps you verify that your code is safe from panics, overflows, and assertion failures, and also that it correctly implements its formal specification (pre- and post-conditions). The plan is to have posts accompany our monthly releases, highlighting key features and writing about happenings in and around Creusot. Creusot at POPL</h2> Last week, the Creusot Team went to POPL 2026, a major academic PL conference. We presented a tutorial on Creusot. More details below.</a> </li> Arnaud Golfouse gave a talk at the CPP workshop (Certified Programs and Proofs): Using Ghost Ownership to Verify Union-Find and Persistent Arrays in Rust, by Arnaud Golfouse, Armaël Guéneau, Jacques-Henri Jourdan (paper on HAL</a>, talk on Youtube (at 8h03m)</a>).</li> </ul> </li> </ul> Upcoming events</h3> One more Creusot paper will appear in JFLA 2026, a French-speaking academic conference taking place next week. This paper is about verifying an implementation of a tricky tree traversal algorithm</a> (see also Threaded binary tree on Wikipedia</a>) using Creusot: Boucler la boucle du parcours de Morris, by Arnaud Golfouse and Paul Patault (paper on HAL</a>, code on Zenodo</a>).</li> </ul> Also next week, Li-yao Xia will give another presentation of Creusot at the RFMIG meeting (Rust Formal Methods Interest Group)</a>, online, on Monday, January 26 at 18:00 GMT (19:00 in France). It will focus on a work-in-progress case study: verifying slice methods in Rust's core library. What's new in Creusot?</h2> Creusot 0.9.0 was released earlier this month, right before the start of POPL. Creusot Tutorial</h3> The Creusot tutorial walks you through the process of verifying a Rust program with Creusot. The tutorial is available in the creusot-rs/tutorial</code> repository</a>. You don't even need to install anything: you can try Creusot online in your browser! See the README</a> for more details. This uses a DevContainer, made possible by recently added support for installing Creusot with Nix. Contents of the tutorial</h4> A gallery of small examples</a> illustrating Creusot's main features.</li> Exercise 1: Gnome sort (exercise</a>, code</a>)</li> Exercise 2: Linked lists (exercise</a>, code</a>)</li> </ul> Infer trivial loop invariants</h3> This is a convenience enhancement for type invariants. A type invariant is a property that all values of a type should satisfy. This is a natural way to encode well-formedness conditions of many data structures. For example, below is a type of "ordered pairs", OPair</code>, with the type invariant that its fields are indeed ordered. // Ordered pairs pub struct OPair(pub u64, pub u64); impl Invariant for OPair { #[logic] fn invariant(self) -> bool { pearlite! { self.0 <= self.1 } } }</code></pre> By equipping a type with a type invariant, every function whose interface involves that type will implicitly assert its type invariant in the function's preconditions and postconditions. #[requires(self.0 < self.1)] // Implicit: // #[requires(inv(*self))] // #[ensures(inv(^self))] pub fn bump(&mut self) { self.0 += 1; }</code></pre> The problem arises when we use such a type in a loop. For example: pub fn bump_loop(&mut self) { while self.0 < self.1 { self.bump() } }</code></pre> In that loop, we call self.bump</code>, which requires self</code> to satisfy its type invariant. Previously, we had to explicitly state the loop invariant, that the type invariant is preserved by each iteration of the loop body: pub fn bump_loop(&mut self) { #[invariant(inv(*self))] while self.0 < self.1 { self.bump() } }</code></pre> This kind of condition easy to forget for newcomers, and becomes quite cumbersome as more type invariants are involved. Now this invariant is automatically inserted by Creusot. That's not all. It may still be desirable to write loops that don't preserve the type invariant—for example, in the initialization of a complex data structure. Although one might imagine a flag to toggle this behavior, we propose an automatic but conservative solution that guesses right in most cases: a type invariant is inserted in a loop invariant only if the last write to a given variable before (re)entering the loop comes from a function boundary. For the example above, self</code> is written to by the caller of the function first, and then by the bump</code> method in the loop, both of which involve a type invariant assertion, so we can safely insert that type invariant as a loop invariant. For a counterexample, below we replaced the bump</code> call with a direct assignment to a field of self</code>. Such assignments are not required to preserve the type invariant of self</code> in general (even though in this case it does). Indeed, we expect field assignments to occur as part of the implementation of a data structure, temporarily breaking type invariants. Consequently, Creusot does not insert the type invariant implicitly in this case. The user can still provide it if necessary. pub fn bump_loop_raw(&mut self) { #[invariant(inv(*self))] // Must be explicit while self.0 < self.1 { self.0 += 1; } }</code></pre> Creusot decides whether to insert such type invariants by performing a little static analysis, a standard exercise in compiler writing. This analysis also detects mutable variables that are not actually written to, so that Creusot can also insert invariants that say "this value hasn't changed since the beginning of the loop". Renamed creusot_std</code></h3> Creusot's standard library has been renamed from creusot_contracts</code> to creusot_std</code>. This library provides macros to enable writing contracts (requires</code>, etc.), and it also contains contracts for the Rust standard library, hence the old name creusot_contracts</code>. The new name creusot_std</code> better conveys the idea that it's a fundamental library to be imported by all Creusot users. Compatibility with no_std</code></h3> The creusot_std</code> library now features a flag std</code> which can be disabled for no_std</code> projects. This is part of ongoing work to support the verification of low-level embedded code. Disabling std</code> reduces the dependencies of creusot_std</code> to core</code> and alloc</code>. This removes contracts for a few data structures such as hashmaps. In the future, it may be possible to avoid the dependency on alloc</code> as well, but it seems that most no_std</code> projects also depend on alloc</code> anyway. Concurrency: atomic invariants</h3> Creusot takes its first step in the formal verification of concurrent programs. Our first working example is parallel_add</code></a> (for comparison, here is the equivalent Rust code</a> without ghost annotations). This builds on top of the aforementioned work on ghost ownership presented at CPP 2026. For concurrency, this release makes two key additions to the creusot_std</code> library: the AtomicI32</code></a> type—a ghost-aware wrapper around std::sync::atomic::AtomicI32</code></a>—and a notion of AtomicInvariant</code></a> inspired by Iris</a>, a separation logic framework in Rocq. For now, this only supports sequential consistency. There is ongoing work to also provide support for relaxed memory models. Stay tuned for future updates on Creusot!

What's new in Creusot?</h2>
This February's release brings a couple of QOL improvements. For the rest, see the Changelog</a>.</p>

Creusot Devlog

Creusot 0.11.0: VerifyThis winner

What's new in Creusot?</h1>
No major new features this release; see the Changelog</a> for details. But big things are already lining up for next month. Stay tuned!</p>

Creusot 0.10.0: February update

Creusot 0.9.0: Launching the Creusot Devlog