Formal methods for dependency upgrades

Upgrade dependencies without breaking your product.

Olympix checks every upgrade using formal methods against the rules your product must always follow.

Bump jsonwebtoken from 8.5.1 to 9.0.0
Pull request #1482
✓BuildPassing
✓Tests412 passed
!
Olympix: 1 invariant violated
Invariant: a valid user can always sign in

Every dependency upgrade either breaks your product or slows you down.

Dependency vulnerabilities doubled in a year.

How far behind the median dependency is
215 days
278 days
Last year
This year
63 days worse in one year. Two reasons it keeps growing:
More dependencies every year
Each one is another upgrade waiting to be checked.
A broken upgrade costs more
So teams hold upgrades until someone can check them.
An upgrade is available
A security fix for the image library
›
It can't ship until a person checks it
Shipping a break costs more than waiting
›
So it joins the QA backlog
214 open
Image library security fix
today
Date library update
2 weeks
Payments library security fix
6 weeks
And bugs still reach production.
Even large QA teams miss breaks that no test covers. Customers find them first.
It happened to us: a Chromium security patch also deprecated a flag our PDF generation depended on. We found out when the PDFs failed.

Every upgrade checked with formal methods before it merges.

Know which upgrades are safe to push, and get the exact input that breaks the ones that aren't.

1Define

We find the rules your product relies on; you confirm them.

2Check

Every upgrade PR, in CI.

3Prove

Every violation comes with the exact input that breaks it.

We call these rules invariants.

Review only what’s flagged

Upgrades that don’t change how your product works merge without necessitating manual review.

Catch breaks before customers do

Upgrades that do change how your product works are flagged before merge, even when tests pass.

Close vulnerabilities sooner

Security patches ship once they’re checked, instead of waiting weeks in the review queue.

Works withGitHub ActionsDependabotRenovateSnykClaude CodeCursor

Runs in your environment. Coding agents read approved invariants via MCP.

Building since 2022

Four years of proving code correctness where one bug costs millions.

Formal methods, proven in web3 where bugs can't be undone.

Proven where bugs can’t be undone

Four years running formal methods on smart contracts, where one bug is permanent and costs millions.

The same engine, on your stack

The formal methods engine that checks smart contracts now checks every dependency upgrade in your CI, against rules your team confirms.

Proof, not a prediction

Every flag comes with the exact input that breaks it, so your team can rerun it instead of trusting a model’s opinion.

$155B+

Protected across Olympix customers

$680M

Exploit losses our engine would have prevented

Preventable Hacks →

AI reasons. Olympix proves.

Olympix
AI code reviewer
Rules
Confirmed by you
Inferred from your tests
Verdict
Evidence you can rerun
An opinion
Agent edits a failing test
Invariants are locked
Check passes
Blind spots
Named in every report
Unstated
Example

A security fix that ships the same day.

One security fix, two ways to ship it.

Your upgrade bot opened this
Security fix: update the image library from 3.2.0 to 3.2.1
✓ Build and tests pass
Today
Send it to the QA backlog
Waits in line behind 213 other upgrades
Someone reviews and tests it by hand
The vulnerability stays open the whole time
Ships in about 6 weeks
With Olympix
Check it with formal methods first
A customer can only see their own filesHolds
Every invoice downloads with its contentsHolds
A valid user can always sign inHolds
15 more rules your product relies onHold
✓ All 18 rules hold. Safe to push today.

Every upgrade you hold is backlog. Every one you rush is a risk.

Clear your upgrade backlog without the risk. Talk to the formal methods team building it.