EVE Wormhole Calculator

Overview

This site is a wormhole mass tracking tool for EVE Online. It helps you plan and execute wormhole rolling with precision by tracking every ship pass and computing tight bounds on remaining mass. Or maybe you really don't want to get rolled out, track your pvp or pve ships through wormholes.

What You Can Do

Track mass passing through wormholes — record each ship pass and the observed state change to build up a picture of how much mass remains.
Plan and execute rolling — use the draft preview to see whether your next pass will push the hole across a state boundary before you commit.
Handle uncertainty — log estimated mass ranges for passes you didn't witness (intel, previous traffic). The engine carries that uncertainty forward correctly.

Key Features

Wormhole mass variance — every wormhole has ±10 % mass variance. The engine tracks all possible true sizes simultaneously.
Uncertain ship masses — ships can have a mass range (e.g. with prop mods). The engine handles ranges, not just fixed values.
Virtual Hangar — save ship templates with named travel modes so you can quickly assign ships to either side of a wormhole.
Sessions — save up to 25 wormhole tracking sessions that persist across browser reloads. Switch between them at any time.
Draft & Calculate — draft ships to preview the mass impact, then calculate the pass to record the observed state.
Geometry chart — a live 2D chart showing the feasible region of (cumulative passed, total mass) with state boundary lines and draft overlays.

Virtual Hangar

The Virtual Hangar is your personal fleet library. It stores ship templates so you can quickly assign ships to either side of a wormhole without re-entering mass values every time. Templates persist in your browser via IndexedDB, so they survive page reloads.

There are three template types, each suited to different tracking scenarios:

Ship — A single hull with named travel modes (Entangle, Cold, Hot). Each mode has its own mass or mass range. When you draft a ship, you pick which mode it's travelling in.
Quick Mass — A simple numeric mass entry for one-off passes when you don't need a full ship template. Great for scouts or throwaway rolling ships.
Fleet — Represents a group of ships as a single mass range. Useful when an entire fleet jumps at once and you only care about the combined total.

Working with the Hangar

Click + New Ship to open the template form. Fill in a name, pick the type, and enter mass values for each mode.
Use the ◀ L and R ▶ buttons on a template card to place a copy on the left or right side of the wormhole. You can place multiple copies of the same template.
Edit or delete templates at any time — existing copies on the sides are not affected.
Hit Restore Defaults to re-add the starter ship templates if you've deleted them.

Tips

If you enter only a min value and leave max blank, the max will be set to the same value — handy when you know the exact mass.
You can use decimal places for accuracy (e.g. 301.5 Gg).
Consider replacing the default ship templates with your own fits. The defaults are a starting point — your actual ship masses may differ.

Sessions

Each wormhole you track is stored as a session. Sessions persist in your browser, so you can close the tab and come back later. You can have up to 25 saved sessions at a time.

Starting a Session

Click + New Session to open the wormhole selection screen.
Use the filters to find your wormhole — type a code directly, or filter by Appears In (where the hole spawns), Destination (where it leads), and Max Ship Size.
Star your frequently used wormholes to add them to the favourites bar at the top of the selection screen for quick access.
After selecting a wormhole, choose the current state: Stable and Fresh (you saw it spawn), Stable, Destabilized, or Critical. This tells the engine how much mass may have already passed.

Managing Sessions

Session tiles appear in the bar below the hangar. Click a tile to switch to that session.
Rename a session by clicking its name in the tile — it becomes editable inline. Press Enter or click away to save.
Delete a session using the × button on its tile.
The tile shows the wormhole code, number of passes, and when the session was created.
If you have many sessions, the bar scrolls horizontally.

Calculating Ship Passes

After ships have passed through the wormhole in EVE and you've noted the new state, you record that information here. Place ship templates on a side panel, then draft the ships that passed by clicking their mode buttons (e.g. "Cold", "Hot"). Each drafted ship highlights and its mass is added to the draft total in the Calculate Pass bar below the chart.

As you draft ships, a translucent blue overlay appears on the geometry chart showing where the cumulative mass would land — useful for planning future passes before they happen in-game.

Recording a Pass

A pass records two things together: the mass that went through and the wormhole state you observed afterwards. The solver needs both — the mass narrows the remaining range, and the observed state constrains which part of that range is actually possible. That's why the Calculate Pass bar requires drafted ships and a selected state before you can commit.

Draft the ships that passed by clicking their mode buttons on the side panels.
Select the observed state after the pass — Stable, Destabilized, Critical, or Gone — using the radio buttons in the Calculate Pass bar.
Click Calculate Pass to commit. The solver recalculates the feasible region and the chart updates with a new event polygon.
Ships that passed move to the opposite side automatically.
Use Clear to un-draft all ships without calculating, or click individual mode buttons to toggle ships on/off.

Tips

You can draft ships from both sides in the same pass — the solver treats it as one combined mass event.
Watch the draft preview overlay to see if your pass might push the wormhole past a state boundary before you commit.
Rename a ship instance by clicking its name on the side panel — it becomes editable inline. Handy for labelling which pilot is flying which ship.
If you make a mistake, you can undo events by clicking the × button next to them in the Event History panel.

Results & Graph

After each pass the constraint solver recomputes the feasible region and renders it on the geometry chart.

Reading the Axes

X axis (horizontal) — Cumulative mass passed through the wormhole so far, in Gg. This grows with every pass you send.
Y axis (vertical) — Total original mass of the wormhole, in Gg. Because the game only tells you a range (e.g. 2,700–3,300 Gg), the chart plots every possible value in that range.

Coloured Areas

Each event pass draws two overlapping polygons on the chart:

Translucent dashed outline — The possible region. This is the broadest area where the true cumulative + wormhole-mass point could lie, given everything observed so far.
Solid filled area — The certain (known) region. Mass that has definitely passed through — there is no uncertainty here. This grows as you send more passes with exact masses.

The colour of these areas reflects the wormhole state reported after that pass:

Green — Stable (more than 50 % mass remaining).
Yellow / Amber — Destabilized (between 10 % and 50 % remaining).
Red — Critical (less than 10 % remaining).
Dark grey — Gone (the wormhole has collapsed).

State Boundary Lines

Three diagonal lines cross the chart showing where state transitions happen:

Yellow line — Destabilization boundary (50 % mass remaining). Crossing this line means the hole goes from Stable to Destabilized.
Red line — Critical boundary (10 % remaining). Past this the hole is in a critical state and could collapse at any time.
Grey line — Gone boundary (0 % remaining). Reaching this line means the wormhole has fully collapsed.

Draft Preview (Blue Overlay)

When you draft ships for a pass, a translucent blue overlay appears showing where the cumulative mass would shift to if you send that pass. This lets you preview whether the pass will push the wormhole across a state boundary — helping you decide if it's safe to commit.

Example 1 — Stable Passes + Draft

A 2,700–3,300 Gg wormhole. A total of 1,300 Gg has been sent through across multiple passes (all Stable), and a 300 Gg ship is drafted.

▶ Click the event numbers below to see the chart at each step.

The first pass was a scout (0–10 Gg uncertain). The green dashed outline is very thin — almost no cumulative mass, but the full Y range is possible.
After 1,300 Gg total has passed, the solid green area shows the certain mass. The dashed outline extends ~10 Gg further to account for the scout uncertainty. Everything is still within the Stable zone (left of the yellow destab line).
The blue overlay previews a drafted 300 Gg pass. It would push cumulative mass to ~1,600–1,610 Gg — right on the yellow destab line, meaning this pass may or may not destabilize the hole.

Example 2 — Uncertainty + Destabilization

Same wormhole (2,700–3,300 Gg), but this time there's early uncertainty and the hole destabilizes.

▶ Click the event numbers below to see the chart at each step.

Intel suggests a medium T3C fleet may have passed — you can't be sure, so you log 0–200 Gg. The green dashed outline spans the full 0–200 range on the X axis with no certain region (it's all uncertain).
You push 1,200 Gg of rolling battleships through and the hole stays Stable. The solid green certain area reaches 1,200 Gg. The dashed possible region extends to ~1,400 Gg because of the 0–200 uncertainty from Pass 1. Notice the possible region clips against the destab line — the solver knows the hole can't be past that boundary while still Stable.
Another 300 Gg goes through and the hole Destabilizes. The polygons turn amber. The certain and possible regions are now irregular pentagons — constrained by both the destab boundary (must be past 50 % used) and the critical boundary (can't be past 90 % yet).
The blue draft overlay shows a 300–400 Gg range pass being considered. Because of the accumulated uncertainty, the draft envelope is wider and angled — it follows the shape of the destabilized polygon shifted right.

Rolling Guides

3000 Gg Holes (e.g. H900, B520)

Wormholes with ~3,000 Gg original mass that accept battleships. The goal: push exactly half the mass through to narrow the size by 50%, then finish the roll with the right number of ships.

This Rolling Guide assumes you have Rolling Battleships (Higgs Anchor Fitted) so that you can pass the wormhole cold (prop mod off) for ~200 Gg or hot (prop mod on) for ~300 Gg

Note: Small differences (e.g. your Rolling Battleships are not exactly 300 Gg, or the CovOps scout nudges the numbers) can occasionally produce edge cases where this procedure doesn't close the hole, or rolls you out.

Flow Overview

2 RBS out & back Hot → 1 RBS out Hot → check state:
↳ Destabilized (small hole) — 1 back hot, then 2 out & back hot
↳ Stable (large hole) — 1 back hot, then 3 out cold & back hot

Click the event numbers to see the chart at the time of that event.

Step 1 — Scout & Send Half Mass

Jump a CovOps through to see what's on the other side (1 Gg). The hole stays Stable.
Send 2 Rolling Battleships (RBS) out Hot and bring them back Hot — that's 4 × 300 = 1,200 Gg total. Still Stable.
Draft: send 1 RBS out Hot (300 Gg). The graph shows this send will clearly reveal more about the size of the hole — the blue draft line sits right on the destab boundary.

Step 2 — Read the Result

Send that RBS out Hot. The hole either Destabilizes or stays Stable. This tells you if it's a small or large hole, and determines how many more ships to send.

It Destabilized → Small Hole

The RBS pass Destabilized the hole — it's a smaller hole (≤ 3,000 Gg). The excluded band at the top confirms larger sizes are ruled out.
Bring that RBS back Hot (300 Gg). Still Destabilized.
Send 2 RBS out Hot and bring them both back Hot (4 × 300 = 1,200 Gg):
Send 2 RBS out Hot (600 Gg). Still Destabilized.
1 back Hot (300 Gg) — the hole goes Critical.
1 back Hot (300 Gg) — Gone. Hole collapsed.

Still Stable → Large Hole

The RBS pass stayed Stable — it's a larger hole (≥ 3,000 Gg). The excluded band at the bottom confirms smaller sizes are ruled out.
Bring that RBS back Hot (300 Gg). This Destabilizes the hole.
Send 3 RBS out Cold and bring them back Hot (3 × 100 + 3 × 300 = 1,200 Gg):
Send 3 RBS out Cold (600 Gg total). Still Destabilized.
1 back Hot (300 Gg). Still Destabilized.
1 back Hot (300 Gg) — Critical.
1 back Hot (300 Gg) — Gone. Hole collapsed.

The Maths Behind the Engine

A non‑EVE‑specific explanation of the geometry and constraint logic powering this site.

1 — What Problem Are We Solving?

At its heart, the engine is solving a very general kind of maths problem:

We have an unknown number. We observe things that restrict what that number could be. Over time, we combine all those restrictions to keep track of every value that is still possible.

This is a classic problem in:

Constraint propagation
Interval arithmetic
Computational geometry

The engine doesn’t try to guess the true value. It keeps a set of all possible values that remain consistent with everything observed so far. That set is represented as a polygon.

2 — Representing Uncertainty as a Shape

Instead of tracking a single number, the engine tracks a region of possible solutions.

Why a region?

Observations are imprecise (ranges, not exact values)
Each observation eliminates some possibilities but not others
The remaining possibilities form a 2D shape

Why 2D?

The engine tracks two quantities:

X — cumulative effect of all actions so far
Y — the original unknown value we’re trying to constrain

Every point (x, y) in the polygon means:

“If the true value were y, and the cumulative effect were x, this would still be consistent with all observations.”

This is a standard technique in constraint‑based modelling.

3 — Linear Constraints → Straight Lines

Every observation becomes a linear constraint. Examples:

“The true value must be at least this big” → a vertical half‑plane
“The cumulative effect must be between A and B” → a vertical strip
“If the true value were Y, then X must be less than some linear function of Y” → a slanted half‑plane

Linear constraints always produce straight lines and straight‑edged shapes. This is why the engine’s shapes are always polygons.

This is the same maths used in:

Linear programming Feasibility regions Robotics motion planning Economics optimisation Error bounds in numerical analysis

4 — Updating the Shape: Shifting & Clipping

Every new observation transforms the polygon in two steps:

Step 1 — Shift (Affine Transform)

If an action adds a range [a, b] to the cumulative value, the polygon is shifted horizontally by that amount.

A fixed shift → move the polygon by a constant
A range shift → create a band between two shifted polygons

This is an affine transformation, one of the simplest geometric operations.

Step 2 — Clip (Half‑Plane Intersection)

An observation like “the true value must now satisfy condition X” becomes a half‑plane. The polygon is clipped against that half‑plane.

Clipping a polygon against a straight line is a classic computational geometry operation, used in:

Computer graphics GIS CAD Physics engines

The result is always another polygon.

5 — Why Polygons?

Polygons are ideal because:

They are easy to shift
They are easy to clip
They remain polygons after every operation
They are cheap to compute
They are easy to draw

This is why the engine never uses curves or splines — straight edges are mathematically exact for this problem.

6 — Draft Preview: Minkowski Sums

When the user drafts a hypothetical action, the engine does not apply constraints. Instead, it computes the Minkowski sum of:

The current polygon
A horizontal line segment representing the draft range

This produces a band of possible future polygons.

Minkowski sums are used in:

Robotics (collision envelopes) Computer graphics (shape inflation) Path planning Manufacturing tolerances

It’s a very standard geometric tool.

7 — Why This Is Fast

The engine only uses:

Affine transforms O(n)

Polygon clipping O(n)

Convex hulls O(n log n)

And polygons are small (usually < 20 vertices). This makes the entire system extremely fast and deterministic.

8 — Real‑World Analogies

This same maths is used in:

📡

GPS error bounds

Representing all possible true positions given noisy signals.

🤖

Robotics motion planning

Representing all possible robot positions that avoid collisions.

🔧

Manufacturing tolerances

Representing all possible dimensions of a part given machining error ranges.

📈

Economics

Feasible regions in linear programming.

🖼️

Computer graphics

Clipping polygons to viewports.

This engine is essentially a constraint‑propagation system with a geometric representation.

Apply Maths To Wormholes

How this site applies constraint geometry to EVE Online wormhole mass tracking.

1 — EVE Wormhole Mass Rules

Every wormhole in EVE has a total mass capacity — the maximum amount of mass that can pass through before it collapses. There are a variety of wormhole mass sizes, usually abbreviated to their central point (e.g. 3,000 Gg), but the actual value for any given wormhole varies by ±10 %. It is believed there is an even probabilty distribution across this variance

A 3,000 Gg wormhole could actually have anywhere from 2,700 to 3,300 Gg of total mass. You never find out the true value — you can only observe the visual state of the wormhole, which changes at specific thresholds:

Wormhole States

Stable — More than 50 % of total mass remains
Destabilized — Between 10 % and 50 % remains
Critical — Less than 10 % remains
Gone — The wormhole has collapsed (0 % remains)

There is one additional rule: a single ship can always pass through, even if its mass exceeds the remaining capacity. The wormhole collapses after that ship completes the jump. This means you cannot lose a ship to mass collapse mid-jump — but the hole will be gone for anyone behind you.

These percentage thresholds, the ±10 % variance, and the single-ship rule are the raw inputs to the constraint engine.

2 — Two Unknowns, One Chart

From a maths perspective, tracking a wormhole involves two unknowns:

M — the wormhole's true total mass (unknown, but within ±10 % of nominal)
X — the cumulative mass that has actually passed through so far

The chart plots these with X on the horizontal axis and M on the vertical axis. Every point (x, m) on the chart represents one possible reality: “the true total mass is m, and x mass has passed through so far.”

Before any observations, every combination of M and X is possible (within the wormhole’s mass range). As ships pass and states are observed, constraints eliminate regions of the chart, and the feasible polygon shrinks.

This is the technique described in Maths Concepts §2 — representing uncertainty as a 2D shape.

3 — How Ship Passes Become Constraints

Each time you send ships through the wormhole and observe the state afterward, the engine generates linear constraints. Here is how:

Mass Range Constraint

Each ship pass has a known mass range [a, b] (from ship fitting). The cumulative mass X after this pass must increase by at least a and at most b. This produces vertical bounds (a strip) on the chart — exactly the vertical half-planes from Maths Concepts §3.

The reason for the mass range on a ship, and not an exact value is that you might see a neutral/enemy ship pass and you cannot tell if there fittings or module state, but you can work out the min and max possible for those.

State Band Constraint

The observed state after the pass tells us what fraction of M remains. For example, “Stable” means more than 50 % remains, so the cumulative passed mass X must be less than 0.5 × M. This is a diagonal half-plane: x < 0.5 · m.

Each state creates two diagonal boundaries (an upper and lower bound), forming a band between two lines through the origin. Clipping the polygon against these lines is identical to the half-plane intersection described in Maths Concepts §4.

Prior-Event Constraints

Every previous state observation still applies. If Pass 2 was Stable, then the cumulative mass at that point was below 50 % of M. The engine translates these into offset diagonal lines — the same slope as the state boundaries, but shifted right by the mass of later passes. The polygon is clipped against each of these, tightening bounds further with every event.

4 — The Solver Pipeline

When you send a pass, the engine runs through a pipeline that brings together several operations from Maths Concepts:

Step 1 — Build the Rectangle

Sum the input mass ranges of all passes so far to get the broadest possible cumulative range. Combined with the wormhole's M range, this forms a bounding rectangle in (X, M) space — the starting shape before any state constraints are applied.

Step 2 — Clip Against State Bands

The rectangle is clipped against the current event's state band (two diagonal lines through the origin). This is the Sutherland-Hodgman polygon clipping from Maths Concepts §4. The result is typically a pentagon or hexagon.

Step 3 — Clip Against Prior Events

For each earlier event, two more offset diagonal constraints are applied. Each clip is the same algorithm, and each produces a tighter polygon. After all clips, the result is the feasible polygon for this event.

Step 4 — Derive Summary Data

From the feasible polygon, the engine reads off tight bounds: the X-range (cumulative mass passed), the M-range (possible wormhole sizes still consistent), and the remaining mass until each future state transition. These are the numbers displayed in the results panel.

5 — Narrowing the Wormhole Size

The ±10 % mass variance means you start with a wide range of possible M values. But each state observation constrains M algebraically.

The engine checks every pair of constraints for compatibility: if one says x ≥ 0.5 · m (Destabilized lower bound) and another says x ≤ 0.5 · m (previous Stable upper bound), these two lines intersect at a specific M value. This intersection eliminates wormhole sizes that cannot satisfy both constraints simultaneously.

On the chart, this appears as excluded mass bands — horizontal grey stripes at the top or bottom of the Y-axis showing M values that have been ruled out. A Destabilized observation rules out larger holes; a Stable observation rules out smaller ones.

6 — Draft Preview: What If?

Before you commit a pass, the draft overlay shows where the feasible region would shift. This uses the Minkowski sum from Maths Concepts §6.

The engine takes the current feasible polygon and the drafted mass range [d_min, d_max], then:

Shifts the polygon right by d_min (minimum mass scenario)
Shifts the polygon right by d_max (maximum mass scenario)
Computes the convex hull of both shifted polygons

The result is the blue translucent envelope on the chart. It shows the full range of where you might land after the pass — without actually applying state constraints (since you haven't observed the result yet). This lets you gauge whether the pass will cross a state boundary.

7 — Remaining Mass Analysis

After each event, the engine computes how much more mass can pass before each future state transition. This is an affine transform of the feasible polygon.

For each state boundary (e.g. the gone line at x = m), every vertex (x, m) of the feasible polygon is mapped to:

remaining = (passedFraction × m) − x

This transforms the polygon from (cumPassed, M) space into (remaining, M) space. The X-extent of the resulting polygon gives you the tight bound on remaining mass until that state.

On the chart, this is visualised as the gap polygon — the region between the feasible polygon's right edge and the state boundary line. The width of that gap at any Y value tells you exactly how much more mass can pass for that particular wormhole size.

8 — Why Geometry Beats Arithmetic

A simpler approach would be to track cumulative mass as a single interval [min, max] and subtract it from the wormhole range. But this loses correlation between M and X.

Consider: if the wormhole is large (M near max), more mass has likely passed. If it's small (M near min), less has passed. A 1D interval treats these as independent — the polygon captures their relationship.

The polygon's shape encodes this correlation. A slanted edge means “for larger holes, the cumulative mass can be higher.” Simple interval arithmetic would produce a rectangle (ignoring the slope), giving strictly looser bounds.

This is why the engine uses computational geometry for everything: it is mathematically exact for this problem, as noted in Maths Concepts §5.

Bonus

Thanks for exploring this site — I hope it has been useful to you.

Sorry for the little trick with the title. The “bonus” actually refers to a nice little bonus for me.

If you’re benefitting from the site and feel like thanking the creator, open the game, search then right-click

Mr Wormhole

hit Give Money to send a tip — small or outrageously generous, both are welcome.

Still undecided? Consider the following

You’re a wormholer — therefore you are already, or are well on your way to becoming, space rich. Live a little.
There are no ads on this site. I don’t like them — they’re ugly. (Also it’s a static page, so hosting is practically free… but let’s not dwell on that.)
I could have used an attractive avatar as a fake portrait, but that’s lame. This is me — a broken old capsuleer, reflexes gone, so far past my prime I don’t remember if I even had one. Help an old man out.
Wigs and hair dye aren’t cheap, you know.

Contact

Feel free to EVEmail Mr Wormhole in-game with any thoughts, ideas, or suggestions to improve this site.

Virtual Hangar

Add Ship Template

Event History

Overview

What You Can Do

Key Features

Virtual Hangar

Working with the Hangar

Tips

Sessions

Starting a Session

Managing Sessions

Calculating Ship Passes

Recording a Pass

Tips

Results & Graph

Reading the Axes

Coloured Areas

State Boundary Lines

Draft Preview (Blue Overlay)

Example 1 — Stable Passes + Draft

Example 2 — Uncertainty + Destabilization

Rolling Guides

3000 Gg Holes (e.g. H900, B520)

Flow Overview

Step 1 — Scout & Send Half Mass

Step 2 — Read the Result

It Destabilized → Small Hole

Still Stable → Large Hole

The Maths Behind the Engine

1 — What Problem Are We Solving?

2 — Representing Uncertainty as a Shape

3 — Linear Constraints → Straight Lines

4 — Updating the Shape: Shifting & Clipping

5 — Why Polygons?

6 — Draft Preview: Minkowski Sums

7 — Why This Is Fast

8 — Real‑World Analogies

Apply Maths To Wormholes

1 — EVE Wormhole Mass Rules

2 — Two Unknowns, One Chart

3 — How Ship Passes Become Constraints

4 — The Solver Pipeline

5 — Narrowing the Wormhole Size

6 — Draft Preview: What If?

7 — Remaining Mass Analysis

8 — Why Geometry Beats Arithmetic

Bonus

Still undecided? Consider the following

Contact