Data & Methodology — How Orbitraz Computes Conjunctions

Engineers should never have to trust a number they can't check. This page explains every step behind the Live Conjunction Watch and the Orbital Congestion Index, in plain terms — including what our current data

Methodology v1 · public-catalog stage · testnet

Plain words: we use the same free, public "where is everything" data that the whole space community uses as a baseline.

Element sets are propagated forward with

Its honest limitation: SGP4 on public TLEs is accurate to roughly the

For every active-vs-debris pair we run a

Today's output is a screening signal. Operational decisions need higher-precision ephemerides and covariance.

We don't yet ingest operator-shared or commercial tracking data, which are far more precise.

One altitude band, active-vs-debris pairs, one top event per day. Expanding this is engineering, not invention.

The on-chain layer runs on Base Sepolia; tokens have no value. Nothing here is audited.

Each step below replaces a limitation above. In order:

Operator-shared ephemerides with covariance

Covariance-based collision probability

The day's top conjunction gets a stable ID (e.g.

Plain words: the moment we detect a risk, a public, tamper-proof record and a reward pool are created automatically — no human in the loop.

Note the split: all the time-critical maths above runs off-chain in milliseconds; only the record, the reward and the rules go on-chain.

See the off-chain / on-chain architecture →

Alongside live screening, Orbitraz publishes research built on two frameworks. Both are