Decentralized Prediction Market Platform
The platform lets users take YES/NO positions on real-world questions. Funds and outcomes live on-chain, while a conventional API layer owns discovery, identity, portfolio state and everything else that would be miserable to read from a blockchain. What makes the build unusual is the resolution path: instead of a single trusted oracle, a language-model agent gathers evidence, writes a resolution candidate with a full audit trail, and a human signs it off before settlement is triggered.
Monorepo: web client, HTTP API, chain listener, realtime gateway, shared contracts package
Documented as an architecture and delivery record. The full stack needs a database, chain services and worker processes, so the public artefact is the architecture, the flows and the implementation notes rather than a live deployment.
How the runtimes cooperate
Pick a lifecycle below and step through it. Highlighted nodes and links show exactly which processes take part at each stage.
Market discovery, order tickets, portfolio and account flows in the browser.
From a drafted question to something users can trade.
Highlights
Separated request, realtime and worker planes
The system is best read as four cooperating runtimes. User requests, live updates, chain watching and AI research all have very different latency and failure characteristics, so each gets its own process and its own failure domain.
Web client
The trading surface: market discovery, market detail, order tickets, portfolio and account flows.
- Server-rendered pages with a client-side data layer for anything that moves.
- Talks to the API for state and to the wallet provider for signing.
- Subscribes to the realtime gateway for price and activity updates.
HTTP API
The main application boundary: markets, orders, identity, media, roles, permissions and public metadata.
- Modular service layout with one module per bounded context.
- Owns validation and business rules; the chain is the settlement layer, not the rulebook.
- Publishes events onto the realtime gateway instead of holding sockets itself.
Chain listener
Worker runtime that watches settlement events and drives asynchronous market jobs.
- Runs apart from the request path so reorgs and RPC stalls stay contained.
- Reconciles on-chain truth back into the database.
- Maintains rollup job state so a restart resumes instead of replaying from genesis.
Realtime gateway
Dedicated WebSocket process for live market, order and notification fan-out.
- Isolated from the HTTP API so a socket storm cannot exhaust request workers.
- Carries market updates, fills and user-scoped notifications.
Shared contracts package
Single source of truth for entities, enums and cross-service types.
- Keeps the API, listener and gateway structurally in sync at compile time.
- Holds the migration history for the shared schema.
Every backend module
One module per bounded context across the API and the worker plane. The chain-facing and wallet-facing groups are what make this more than a CRUD application. 37 units across 6 groups.
Market domain
6Chain & custody
7Value distribution
4Identity & access
5Messaging
3Content & platform
12Stack by layer
Delivered work
Client surfaces
- Market listing, market detail, portfolio, profile and onboarding flows.
- Reusable market widgets: activity charts, live-bet feed, trade panels and price bars.
- Embedded-wallet authentication and smart-account UX wired through the whole session lifecycle.
- An interactive in-app architecture walkthrough for onboarding new engineers.
Platform and services
- Modular API covering markets, orders, identity, media, notifications, SEO metadata and role-based permissions.
- Chain listener split from the request path, with resumable rollup job state.
- Dedicated realtime gateway for market and notification fan-out.
- Shared package holding entities, enums and migrations for every service.
Resolution and treasury
- Agent-driven resolution pipeline with candidate records, configuration and an append-only audit log.
- Multisig-backed treasury operations with explicit nonce management.
- Gas sponsorship so new users can transact before funding a wallet.
- Airdrop and reward allocation tracked as first-class records.
Modules and demo strategy
Market lifecycle
Creation, trading, closure and settlement of a prediction market.
- Spans all four runtimes — the clearest illustration of why they are separate.
- Documented as a flow rather than a screen.
Identity and wallets
Turns a social login into a usable on-chain account.
- Embedded wallet provider plus smart accounts and sponsored gas.
- Removes the single biggest drop-off point in Web3 onboarding.
Resolution pipeline
Decides what actually happened, defensibly.
- Evidence gathering, candidate generation, audit trail, human confirmation.
- Designed so any settlement can be explained after the fact.
Analytics rollups
Keeps dashboards fast as history grows.
- Pre-aggregated pool and user tables maintained by the worker plane.
- Job state is persisted so restarts resume rather than recompute.