Ultrasteller is a live satellite fleet tracking and ground-station pass prediction platform built on real orbital data, with on-chain prediction markets on Stellar/Soroban. It answers two operational questions — where is every satellite in the fleet right now? and exactly when can a given ground station talk to each of them? — and then turns those pass predictions into verifiable on-chain markets.

Nothing is simulated. TLEs (two-line element sets) are fetched live from CelesTrak and propagated with SGP4, the same model used by NORAD for orbit prediction. Positions on the dashboard refresh every 5 seconds; pass predictions look up to 72 hours out.

The product is three repositories, one per layer:

CelesTrak (live TLEs, cached 2h)
        │
        ▼
ultrasteller-backend (Rust/axum, SGP4 propagation)
   │            │                     │
   │ /api/fleet │ /api/passes         │ market loop (every 5 min)
   ▼            ▼                     ▼
ultrasteller-frontend          stellar CLI ──▶ prediction-market
(globe + pass dashboard)                       contract (Soroban testnet)

1. Ingest. The backend fetches TLEs for the tracked fleet from CelesTrak and caches them for 2 hours. On a fetch failure it serves stale data rather than erroring, so the dashboard never goes dark because CelesTrak hiccuped.

2. Propagate. Every request runs real SGP4 propagation (via the Rust sgp4crate). GMST and ECI/ECF/geodetic conversions are a direct port of satellite.js's algorithms, matching the original TypeScript implementation to sub-100m accuracy.

3. Predict.For a ground station's coordinates, the backend computes look-angles over the requested window and reports every pass where the satellite rises above 10° elevation: rise time, set time, max elevation, and duration.

4. Bet & resolve. A background loop turns upcoming passes into binary on-chain markets — “will this pass exceed 45° max elevation?” — and resolves them after the pass using the same SGP4 engine as the oracle. See Prediction Markets.

Run the whole stack locally. Backend first (Rust 1.75+):

git clone https://github.com/UltraStellar-HQ/ultrasteller-backend
cd ultrasteller-backend
cargo run
# listens on :3001 by default; override with PORT=

Then the frontend (Node 20+):

git clone https://github.com/UltraStellar-HQ/ultrasteller-frontend
cd ultrasteller-frontend
npm install
cp .env.example .env.local   # NEXT_PUBLIC_API_URL, defaults to http://localhost:3001
npm run dev

The prediction-market loop is optional and needs the stellar CLI on PATH plus a funded testnet admin identity:

stellar keys generate ultrasteller-admin --network testnet --fund

If the CLI isn't available the loop logs and skips a cycle — /api/fleet and /api/passes keep working regardless.

Base URL: your backend deployment (locally http://localhost:3001). All endpoints are public, read-only GET, unauthenticated, and CORS-open (Access-Control-Allow-Origin: *).

GET /api/fleet

Current position of every tracked satellite.

curl http://localhost:3001/api/fleet

{
  "generatedAt": "2026-07-11T09:30:00.000Z",
  "satellites": [
    {
      "name": "ISS (ZARYA)",
      "lat": 12.47,
      "lng": -101.3,
      "altKm": 417.2,
      "velocityKmS": 7.66
    }
  ]
}

GET /api/passes

Upcoming passes over a ground station. All parameters optional:

A pass is reported when the satellite rises above 10° elevation.

curl "http://localhost:3001/api/passes?lat=28.3922&lng=-80.6077&altKm=0.003&hours=24"

{
  "generatedAt": "2026-07-11T09:30:00.000Z",
  "passes": [
    {
      "satelliteName": "ISS (ZARYA)",
      "riseTime": "2026-07-11T11:02:13.000Z",
      "setTime": "2026-07-11T11:12:45.000Z",
      "maxElevationDeg": 63.4,
      "maxElevationTime": "2026-07-11T11:07:30.000Z",
      "durationSec": 632
    }
  ]
}

GET /api/markets

Open and resolved prediction markets.

curl http://localhost:3001/api/markets

{
  "generatedAt": "2026-07-11T09:30:00.000Z",
  "markets": [
    {
      "marketId": "iss-zarya:cape-canaveral:2026-07-11T11:02Z",
      "satellite": "ISS (ZARYA)",
      "station": "Cape Canaveral, USA",
      "thresholdCentideg": 4500,
      "closeTime": "2026-07-11T11:02:13.000Z",
      "yesPool": 250000000,
      "noPool": 100000000,
      "resolved": false,
      "outcome": null
    }
  ]
}

GET /health

Liveness check, returns 200 OK.

Every 5 minutes a background loop in the backend turns upcoming passes into binary markets on the Soroban prediction-market contract, then resolves them once the pass has happened. The question is always the same shape: “will this satellite's pass over this station exceed 45° max elevation?”

Market creation and resolution are admin-only by design, signed by a server-held identity (STELLAR_ADMIN_IDENTITY) — the whole point is that the backend's own orbital-mechanics output is the source of truth, not user input. Backend configuration (all optional): PREDICTION_MARKET_CONTRACT_ID, STELLAR_NETWORK (default testnet), STELLAR_ADMIN_IDENTITY (default ultrasteller-admin).

A Cargo workspace of two Soroban contracts, deployed on Stellar testnet.

pass-anchor

Anchors pass events on-chain as immutable, timestamped proofs. The pass_hash is computed off-chain (e.g. sha256 over satellite name, rise/set/max-elevation times, and station) — the contract only attests that a pass happened and when.

prediction-market

Known v1 limitation: if a market resolves with zero stake on the winning side, the losing pool stays locked in the contract (rare; recoverable via an admin sweep, not built yet).

# build & test
cargo test --workspace
stellar contract build
stellar contract build -p prediction-market   # or just one

Six real launch/tracking sites are built into the dashboard — pass prediction works for any coordinates via the API.