What Connect is

The shared engine behind Prophecy prediction markets. It ingests the chain once, projects it per venue, and serves reads, realtime and gasless trading — so a venue is a frontend, not an infrastructure project.

Prophecy Connect is the shared, multi-tenant derivation and serving engine behind Prophecy. It ingests the chain once, projects it per venue, and serves reads, realtime updates and gasless trading to everything built on top.

prophecy.social is one of those venues. So is a venue generated by Prophecy Studio. So is yours — all three are the same kind of consumer, calling the same API.

The practical consequence for you: you don’t index anything, run a database, or derive a number. No cron pipeline, no chain access, no price maths. You call hooks.

Markets are global objects; venues are views

This is the idea the whole architecture is built on, and it’s a protocol-level fact rather than a convention:

A market is a single global on-chain object. The venue you trade through is a routing and fee tag on the trade, not a location — the trade hits the same market either way.

So liquidity is never siloed in a venue. It isn’t synced between venues, because it was never split in the first place. Two venues surfacing the same market are two windows onto the same liquidity, and both are better off for it — which is why everyone is incentivised to surface a shared catalogue rather than hoard one.

What a venue actually owns is its skin and its local content: branding, layout, copy, which markets it surfaces, its own forum or news. Markets, liquidity, positions, identity and scores are shared, and they live here.

Markets have a structure — branch on it, never on a version

Today every market is a CPMM: a pooled automated market maker, where the price is derived from the pool’s reserves and any size fills instantly against the curve. An order-book (CLOB) market structure is coming, and a parimutuel one is possible after that.

They are not versions of each other — they’re different market structures, and they behave differently in ways a UI can feel:

CPMM CLOB
Price comes from pool reserves — always live, always two-sided the book — which can be empty, one-sided or wide
Your fill the curve, at the quoted size walks the book; partial fills are normal
Liquidity a pool resting orders

So the rule, for you as much as for us:

Discriminate on market structure, never on a protocol version. Don’t write if (v3). Ask what kind of market this is, and let unknown structures fall through to something safe.

Two habits that follow, and will save you a rewrite:

  • Never assume a pool exists. Anything reading reserves directly is CPMM-specific.
  • Never assume the displayed odds are your fill price. They’re equal on a CPMM at small size; on a book they are not, and the number a user is shown before confirming must come from the quote, not the ticker.

Fork the skin, never the brain

Everything with a formula, money, identity, or correctness in it is a shared service, fixed once for everyone. Only presentation is disposable.

That rule is what makes a venue cheap to build and safe to run. If points or pricing or session handling lived in each skin, a fix would have to be shipped to every venue that ever forked it — and the ones that didn’t upgrade would quietly be wrong about people’s money.

What Connect adds on top of the chain

The chain is indexed already: an Envio indexer maintains markets, trades, balances and resolutions as raw truth. Connect consumes that rather than re-indexing it, and builds the layer an indexer structurally can’t:

  • Per-user economics — cost basis, realised and unrealised PnL, per-market results.
  • Scores and incentives — edge, win rate, streak, volume, leaderboards, ranks, points.
  • Identity — accounts that own several wallets, and the follow graph on top.
  • Multi-tenant serving — per-venue projection, edge-cached reads, and realtime fan-out over one multiplexed socket.

Raw truth says what happened on chain. Connect says what it means for this user, in this venue — and streams it.

What that buys a venue

  • Reads and realtime — markets, odds, activity, search, leaderboards, wallet profiles, positions and history, live over one socket.
  • Login — SIWE or Privy, with the session handled for you.
  • Gasless trading — a sponsorship gate plus a paymaster, so a user can predict without holding gas.
  • A checkout you don’t build — <ProphecyCheckout>, themeable, wallet-agnostic, with one-tap predicts and optimistic confirm.
  • Structure — venue-kit gives you the whole venue shell; you restyle it.

The reference venue composes all of that. Every page in this site’s sidebar is one piece of it, live, beside the code that produces it.

Where to go next

  • Get started — install, providers, and the configuration you need.
  • Architecture — every package, what it’s for, and where the services sit.
  • Environments — mainnet and testnet, chains, tokens, endpoints.
  • The wire — why your integration can’t silently drift out of sync with ours.