# Antithesis and the Quiet Comeback of Deterministic Simulation Testing

Antithesis runs your whole system inside a deterministic hypervisor so every bug reproduces perfectly. Here's how it works, who uses it, and the FoundationDB lineage behind it.

Author: J.A. Watte
Published: June 26, 2026
Source: https://jwatte.com/blog/blog-antithesis-deterministic-testing/

---

You ship a fix for a race condition that crashed production at 3 a.m. The customer's gone, the logs are thin, and you can't make it happen again on your laptop. So you add some logging, deploy, and wait for it to bite someone else. That's the whole loop for a certain class of bug: rare, timing-dependent, and impossible to reproduce on demand. Distributed systems are full of them.

The frustrating part is that the bug *did* happen. There was an exact sequence of inputs, faults, and thread interleavings that produced it. You just don't have a button that replays that sequence. Most testing tools don't either, because the environment underneath them is full of non-determinism: the system clock, the OS scheduler, network timing, random number generators. Run the same test twice and you get two different execution histories.

A company called Antithesis is built around removing that excuse. Its pitch is that you should be able to rewind any failure to the exact moment it happened and replay it as many times as you want. The idea isn't new. What's interesting is that the approach finally has real money and real customers behind it, and the lineage traces straight back to one of the more respected pieces of database engineering of the last fifteen years.

## What deterministic simulation testing actually is

The core idea is called deterministic simulation testing, or DST. You take the software under test and run it inside a simulated environment where every source of randomness is controlled. As Antithesis's own docs put it, "some or all layers of the testing stack are made deterministic, including sources of non-determinism like clocks, thread interleaving, and system-provided sources of randomness." Once those are pinned down, a bug that surfaces during a run can be reproduced exactly. Same seed, same schedule, same failure, every time.

Antithesis runs this inside a custom piece of infrastructure it calls The Determinator, described as "our deterministic hypervisor, where all bugs are perfectly reproducible." The whole system under test runs in there, not just a single process with mocks around it. That's the end-to-end part. The company's framing is blunt about the goal: it "automates end-to-end system testing and finds the unknown unknowns that traditional testing methods miss."

DST rarely travels alone. The docs note it's "often paired with property-based testing/fuzzing and fault injection." Property-based testing means you assert general truths about your system instead of hand-writing specific input-output cases, then let the tool generate inputs trying to break those truths. Fault injection means the tool actively breaks things while the system runs.

## Fault injection and the "multiverse" of execution histories

Here's where it stops looking like a normal test runner. While your system is running inside the simulation, Antithesis "introduces simulated faults" and "travels through a multiverse of your system's possible execution histories." The faults are the kind of thing that actually takes down distributed systems in production. The docs list "network retries, thread hangs, or node restarts." The stealth-launch release adds "network degradation, server/service outages, race conditions, and memory issues" to that menu.

The branching is the clever part. When the bug finder "notices interesting or rare behavior, it makes a copy of the system state and explores many possible futures from that point." Instead of running one timeline to the end and starting over, it snapshots a promising moment and forks it, exploring multiple continuations from the same state. Because "the Antithesis simulation environment is fully deterministic (meaning any state in a test run can always be reached again)," none of that exploration is throwaway. Every branch is reachable again later.

That property pays off most at debug time. The company describes "the ability to arbitrarily rewind time from the moment of an incident, change inputs, examine system state, or enable additional logging." This is the part that fixes the 3 a.m. problem. You don't redeploy with more logging and wait. You rewind to the incident and turn logging on right there, after the fact.

## Sometimes assertions, or coverage turned inside out

One concept worth stealing even if you never touch Antithesis is the "sometimes assertion." A normal assertion says something is *always* true. A sometimes assertion says something is *at least sometimes* true. The docs put it plainly: "Just as an *always* assertion asserts that something is always true, a *Sometimes* Assertion asserts that something is *sometimes* true."

It sounds backwards until you connect it to test coverage. If you assert that a particular branch *sometimes* executes and it never does across a huge state-space search, that's a signal your test setup never reached an important case. The docs make the relationship explicit: "Coverage tools, which tell you which lines of code in your program are reached, are just a more restrictive kind of sometimes assertion." Line coverage tells you a line ran. A sometimes assertion can tell you a *meaningful condition* held at least once, which is a stronger and more flexible claim.

```python
# Sketch of the idea, in pseudocode
sometimes("a write conflict was retried successfully", retry_count > 0)
sometimes("the leader changed mid-transaction", leader_changed)
always("balances never go negative", balance >= 0)
```

If the search runs for hours and a `sometimes` line never fires, you've learned your harness can't even produce that situation. That's a bug in your testing, surfaced automatically.

## The FoundationDB lineage

None of this came out of nowhere. FoundationDB was an ACID-compliant distributed database whose testing was, frankly, the stuff of engineering folklore. Per Antithesis's backstory page, the team "began to create testing technology that could deterministically simulate FoundationDB clusters of varying sizes and configurations, engage them with multiple types of workloads, inject a variety of hardware and network faults, and check the results at the end of each run to see if any of the system's guarantees were violated."

FoundationDB was started in 2009 by Dave Rosenthal, Dave Scherer, and Nick Lavezzo, and Apple acquired it in 2015. Two of the people closest to that testing work, Will Wilson and Dave Scherer, went on to found Antithesis in 2018. The docs say it directly: FoundationDB's simulation-first framework "became the backbone of the technology at Antithesis." The founders, by their own account, "were shocked to find that even in the most sophisticated organizations, nothing like FoundationDB's deterministic testing existed." So they built a company to sell it.

## The Ethereum Merge: a concrete result

The most detailed public case study is the 2022 Ethereum Merge, the transition from Proof-of-Work to Proof-of-Stake. A year before the Merge, the Ethereum Foundation began working with Antithesis to test the Merge codebase "under very demanding conditions." Antithesis "stress-tested this simulation by injecting a variety of faults (network issues, hardware failures, frozen processes, etc.)" and handed back perfect reproductions, including log and core dumps.

The numbers are specific. Antithesis "identified thirteen bugs within the category of 'Panics, Crashes, or Denials of Service'" plus twenty-two more bugs affecting overall blockchain performance. The fixes are traceable to real pull requests: PR11024 was a missing nil check affecting execution and consensus client communication, PR10994 fixed an error-handling oversight that trapped invalid blocks in the pending queue, and PR3813 addressed a failure to create attestations for upcoming blocks in the early attester cache. For a network now securing a large chunk of the crypto economy, finding those before the transition was not a small thing.

## Who's paying for it, and what it cost to get here

Antithesis spent six years in stealth before going public. The funding timeline tells you who takes this seriously.

| Funding event | Date | Amount | Lead / key investors | Valuation |
|---|---|---|---|---|
| Seed (stealth exit) | Feb 13, 2024 | $47M | Amplify Partners, Tamarack Global, First In Ventures; angels Michael Walrath, Howard Lerman | $215M (per TechCrunch; not disclosed by company) |
| Growth round | Feb 2025 | $30M | Amplify Partners (lead), Spark Capital | Not disclosed |
| Series A | Dec 3, 2025 | $105M | Jane Street (lead); Amplify, Spark Capital, Tamarack Global, First In Ventures, Teamworthy, Hyperion; angels Patrick Collison, Dwarkesh Patel, Sholto Douglas | Not disclosed |

Add those three rounds and you get roughly $182 million raised, though that total is arithmetic from the individual announcements rather than a figure Antithesis itself publishes. The only valuation the company's investors put on record is the $215 million from the seed, and that came from TechCrunch's reporting, not the company. I've seen a much larger valuation floated around. I couldn't find a source for it, so I'm not going to print it.

The customer list is the more persuasive signal. The December 2025 Series A release names Jane Street, the Ethereum Foundation, and MongoDB. Jane Street, which also led the Series A, had an engineer go on record that "Antithesis has helped us uncover issues that no other testing method could find." MongoDB "uses Antithesis to rigorously test core components of its database platform." Going back to the February 2024 stealth-exit release, Palantir was named as a customer too, though it doesn't appear in the 2025 announcement. When a proprietary trading firm, a blockchain foundation, and a database company all reach for the same testing approach, the pattern is that it earns its keep on systems where a rare bug is genuinely expensive.

## Is this for you?

Probably not, if you're running a CRUD app with a single database and a couple of background jobs. DST shines on systems with real concurrency, multiple nodes, and failure modes that only appear under specific timing. The setup cost is real, and Antithesis is a commercial platform, not a `pip install`. But the *ideas* are portable. Sometimes assertions, deterministic seeds, and treating fault injection as a first-class part of testing are things you can adopt in pieces without buying anything. If you build systems where reliability is the product, that's a map worth having, and it's the same territory I cover in my book *The $97 Launch* for operators who'd rather understand the machinery than rent it blind.

The honest trade-off: deterministic testing buys you reproducibility, but only for the layers you actually made deterministic. Anything you mock out, you're not testing. Anything outside the simulation boundary, you're trusting. That's not a knock on the approach. It's the thing to be clear-eyed about before you assume a green test run means the real world won't surprise you.

## Fact-check notes and sources

- Antithesis "automates end-to-end system testing and finds the unknown unknowns that traditional testing methods miss". Source: [Antithesis, What is Antithesis](https://antithesis.com/product/what_is_antithesis/).
- The Determinator deterministic hypervisor, the "multiverse" of execution histories, state snapshotting, full determinism, time-travel rewind, and fault injection (network retries, thread hangs, node restarts). Source: [Antithesis, How Antithesis Works](https://antithesis.com/product/how_antithesis_works/).
- DST definition (clocks, thread interleaving, randomness made deterministic), the FoundationDB lineage, and pairing with property-based testing and fault injection. Source: [Antithesis Docs, Deterministic Simulation Testing](https://antithesis.com/docs/resources/deterministic_simulation_testing/).
- Sometimes assertions and the coverage-tools relationship. Source: [Antithesis Docs, Sometimes Assertions](https://antithesis.com/docs/best_practices/sometimes_assertions/).
- Founders Will Wilson and Dave Scherer came from FoundationDB; the deterministic-simulation backstory. Source: [Antithesis, Our backstory](https://antithesis.com/company/backstory/).
- FoundationDB started in 2009 by Dave Rosenthal, Dave Scherer, and Nick Lavezzo; acquired by Apple in 2015. Source: [Wikipedia, FoundationDB](https://en.wikipedia.org/wiki/FoundationDB).
- Ethereum Merge testing: a year of pre-Merge work, fault injection, perfect reproductions, thirteen "Panics, Crashes, or Denials of Service" bugs plus twenty-two performance bugs, and PRs 11024, 10994, and 3813. Source: [Antithesis, Case study: Testing the Ethereum merge](https://antithesis.com/case_studies/ethereum_merge/).
- $47M seed and stealth exit on Feb 13, 2024 (Amplify Partners, Tamarack Global, First In Ventures; angels Michael Walrath and Howard Lerman); chaos-testing fault list; Palantir named as a customer. Source: [PR Newswire, Antithesis Launches Out Of Stealth](https://www.prnewswire.com/news-releases/antithesis-launches-out-of-stealth-to-revolutionize-software-reliability-302060173.html).
- The $215M seed valuation, attributed to TechCrunch and not disclosed by the company. The much-larger valuation figure circulating elsewhere could not be verified against any source, so it is omitted. Source: [TechCrunch, Antithesis raises $47M](https://techcrunch.com/2024/02/13/antithesis-raises-47m-to-launch-an-automated-testing-platform-for-software/).
- The $30M February 2025 round led by Amplify Partners with Spark Capital participating. Source: [FINSMES, Antithesis Raises $30M In Funding](https://www.finsmes.com/2025/02/antithesis-raises-30m-in-funding.html).
- $105M Series A led by Jane Street announced Dec 3, 2025; company founded 2018; HQ Tysons Corner / Northern Virginia; full Series A investor list; named customers Jane Street, Ethereum Foundation, and MongoDB; Jane Street and MongoDB quotes. Source: [PR Newswire, Jane Street Leads Antithesis's $105M Series A](https://www.prnewswire.com/news-releases/jane-street-leads-antithesiss-105m-series-a-to-make-deterministic-simulation-testing-the-new-standard-302631076.html).
- The ~$182M cumulative total is the arithmetic sum of the three rounds above, not a figure published by Antithesis.

## Related reading

- [The pre-deploy check that catches the obvious stuff](/blog/blog-tool-predeploy-check/)
- [Hosting and indexing health checks](/blog/blog-hosting-indexing-health-checker/)
- [Security headers as a trust bundle](/blog/blog-security-headers-trust-bundle/)
- [Find and fix broken links before users do](/blog/blog-tool-broken-link-fix-generator/)


*This post is informational, not engineering or investment advice. Mentions of Antithesis, FoundationDB, Apple, Jane Street, MongoDB, Palantir, and the Ethereum Foundation are nominative fair use. No affiliation is implied.*


---

Canonical HTML: https://jwatte.com/blog/blog-antithesis-deterministic-testing/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/blog-antithesis-deterministic-testing.webp