HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
model-checking
verify-rust-std
Rust2025–2026
model-checking / verify-rust-std

verify-rust-std

Verifying the Rust standard library

Libraries & SDKs
Explore on GitHubRead Hacker News discussions
6Distinct people
7Mentions
0Explicit recommenders
370GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Verifying the Rust standard library

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month7 dated mentions

Observed mentions: 2025-02-10 01:35:45 UTC to 2026-10-13 12:49:06 UTC.

0122025-02-01 00:00:00 UTC to 2025-03-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsFeb 20252025-03-01 00:00:00 UTC to 2025-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-04-01 00:00:00 UTC to 2025-05-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-05-01 00:00:00 UTC to 2025-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-01 00:00:00 UTC to 2025-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-07-01 00:00:00 UTC to 2025-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-08-01 00:00:00 UTC to 2025-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-09-01 00:00:00 UTC to 2025-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-10-01 00:00:00 UTC to 2025-11-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-11-01 00:00:00 UTC to 2025-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-12-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsDec 20252026-01-01 00:00:00 UTC to 2026-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-02-01 00:00:00 UTC to 2026-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-03-01 00:00:00 UTC to 2026-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-01 00:00:00 UTC to 2026-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-01 00:00:00 UTC to 2026-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-01 00:00:00 UTC to 2026-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-07-01 00:00:00 UTC to 2026-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-08-01 00:00:00 UTC to 2026-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-09-01 00:00:00 UTC to 2026-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-10-01 00:00:00 UTC to 2026-11-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsOct 2026

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Feb 20252025-02-01 00:00:00 UTC2025-03-01 00:00:00 UTC101
Mar 20252025-03-01 00:00:00 UTC2025-04-01 00:00:00 UTC000
Apr 20252025-04-01 00:00:00 UTC2025-05-01 00:00:00 UTC101
May 20252025-05-01 00:00:00 UTC2025-06-01 00:00:00 UTC000
Jun 20252025-06-01 00:00:00 UTC2025-07-01 00:00:00 UTC101
Jul 20252025-07-01 00:00:00 UTC2025-08-01 00:00:00 UTC000
Aug 20252025-08-01 00:00:00 UTC2025-09-01 00:00:00 UTC000
Sep 20252025-09-01 00:00:00 UTC2025-10-01 00:00:00 UTC000
Oct 20252025-10-01 00:00:00 UTC2025-11-01 00:00:00 UTC202
Nov 20252025-11-01 00:00:00 UTC2025-12-01 00:00:00 UTC000
Dec 20252025-12-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
Jan 20262026-01-01 00:00:00 UTC2026-02-01 00:00:00 UTC000
Feb 20262026-02-01 00:00:00 UTC2026-03-01 00:00:00 UTC000
Mar 20262026-03-01 00:00:00 UTC2026-04-01 00:00:00 UTC000
Apr 20262026-04-01 00:00:00 UTC2026-05-01 00:00:00 UTC000
May 20262026-05-01 00:00:00 UTC2026-06-01 00:00:00 UTC000
Jun 20262026-06-01 00:00:00 UTC2026-07-01 00:00:00 UTC101
Jul 20262026-07-01 00:00:00 UTC2026-08-01 00:00:00 UTC000
Aug 20262026-08-01 00:00:00 UTC2026-09-01 00:00:00 UTC000
Sep 20262026-09-01 00:00:00 UTC2026-10-01 00:00:00 UTC000
Oct 20262026-10-01 00:00:00 UTC2026-11-01 00:00:00 UTC101

What Hacker News says

7 sources
gpm·Oct 21, 2025
"Needs" is a strong word, would benefit from a bit, but in practice I think the number of vulnerabilities rust code typically has is not large enough to justify the expense of compromising the performance of every CPU ever sold (thus requiring more, consuming more energy, etc). There's also been steady progress towards creating systems to prove unsafe rust correct - at which point it wouldn't even benefit from this. For example see the work amazon has been sponsoring to prove the standard library correct: https://github.com/model-checking/verify-rust-std/
In ChkTag: x86 Memory Safety
yencabulator·Jun 3, 2025
There are so many Rust things that Prusti doesn't understand that applying it to any real world project is still extremely challenging. Kani interacts a little better with real code (see https://model-checking.github.io/kani/rust-feature-support.h...), as long as you don't accidentally need e.g. randomness for HashMap DoS protection (https://github.com/model-checking/kani/issues/2423#issuecomm...). Loops are an utter pain to prove with Kani, though: https://model-checking.github.io/kani/tutorial-loop-unwindin... -- I believe people are using Verifast for loop-heavy code instead: https://github.com/verifast/verifast (this hole patchwork of multiple tools mostly consumed as binary downloads is miserable) Here's an attempt to gradually verify the Rust stdlib: https://github.com/model-checking/verify-rust-std
In What works (and doesn't) selling formal methods
nextaccountic·Apr 22, 2025
But why? Tests can't catch everything. A single verified predicate is equivalent to a very large, potentially infinite number of tests. Right now the Rust stdlib is being verified using Kani, a model checker, https://model-checking.github.io/verify-rust-std/ In Kani, a proof looks like this https://github.com/model-checking/verify-rust-std/blob/00169... #[kani::proof_for_contract(NonNull::new_unchecked)] pub fn non_null_check_new_unchecked() { let raw_ptr = kani::any::<usize>() as *mut i32; unsafe { let _ = NonNull::new_unchecked(raw_ptr); } } It looks like a test, but actually it is testing that every possible usize, when converted to a pointer to i32 and built with NonNull::new_unchecked, will follow the contract of NonNull::new_unchecked, which is defined here https://github.com/model-ch
Read the rest
ecking/verify-rust-std/blob/00169... #[requires(!ptr.is_null())] #[ensures(|result| result.as_ptr() == ptr)] Which means: if the caller guarantees that the parameter ptr is not null, then result.as_ptr() is the same as the passed ptr That's a kind of trivial contract but Kani tests for all possible pointers (rather than some cherry picked pointers like the null pointer and something else), without actually brute-forcing them but instead recognizing when many inputs test the same thing (while still catching a bug if the code changes to handle some input differently). And this approach scales for non-trivial properties too, a lot of things in the stdlib have non-trivial invariants. You can check out other proofs here https://github.com/search?q=repo%3Amodel-checking%2Fverify-r... It's not that different from writing a regular test, it's just more powerful. And you can even use this #[requires] and #[ensures] syntax to test properties in regular tests if you use the https://crates.io/crates/contracts crate. Really if you have ever used the https://proptest-rs.github.io/proptest/intro.html or the https://crates.io/crates/quickcheck crate, software verification is like writing a property test, but rather than testing N examples generated at random, it tests all possible examples at once. And it works when the space of possible examples is infinite or prohibitively large, too.
In Verus: Verified Rust for low-level systems code
gpm·Feb 10, 2025
You tell it what you want it to prove. Or the tooling surrounding it does. The tooling surrounding it might want to prove that "this main function never invokes undefined behavior", or something more local like "for all possible inputs to the public interface to this module, no undefined behavior is invoked". Or you might want to specify constraints by hand. For examples, you might do that by writing normal tests except you can use magical variables that take on any value [1], or you might do that by annotating functions with contracts that they obey [2]. Or at a simpler level you might just annotate functions that should never panic. Ultimately once you can prove things about your code, it's a tool in the toolbox for querying how your code works. You can use that to write correct code from the start, or to debug incorrect code, or variou
Read the rest
s other things. The problem is that right now the state of the art (non-ai) can't reason about very complex code without a lot of human help - making it a fairly impractical tool. I think AI might mange to fix that. [1] This is how kani works in rust, here's an example: https://github.com/model-checking/verify-rust-std/pull/112/f... [2] Creusot takes this route, here's an example https://github.com/sarsko/CreuSAT/blob/master/CreuSAT/src/so...
In LIMO: Less Is More for Reasoning

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.