Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.generalmarket.io/llms.txt

Use this file to discover all available pages before exploring further.

​
Architecture

A prediction market is a stack of responsibilities, each delegated to the layer least likely to abuse it. Vision distributes trust across five layers. No single component controls the outcome. The architecture is redundant not because redundancy is fashionable, but because trust concentrated is trust misplaced.
Vision Protocol Stack — five layers from external data through L3 blockchain, data pipeline, BLS consensus, to frontend interface

​
Data Node Independence

Each oracle operates its own data-node instance. They poll the same 98 APIs, store their own copies, compute their own snapshots. If one data-node fails, two others still reach consensus. If all three disagree about a price, no tick resolves. This is the cost of not trusting anyone — you must verify everything three times. A fourth data-node, read-only, serves the frontend and bot APIs. It holds no signing authority. It cannot influence resolution. It merely reports what the protocol has decided.
Four independent data nodes — one per oracle plus a read-only frontend instance, all polling the same 98 external APIs
Data-node independence means a single compromised data source cannot alter outcomes. Each oracle computes prices from its own database, and BLS consensus rejects disagreement. The protocol is as paranoid as its architecture suggests.

​
Contract Architecture

Three contracts. Clear separation. The money never touches the logic.
L3 contract architecture — Vision.sol for batch logic, VisionReserve for USDC custody, OracleRegistry for BLS key management
VisionReserve is the only contract that holds USDC. Vision.sol cannot move funds directly — it calls the reserve, which verifies the caller. The separation exists to ensure a bug in batch logic cannot drain the treasury. Paranoia, in contract design, is a virtue.

​
BLS Consensus Model

Nothing happens without agreement. Tick resolution, config updates, balance proofs, batch creation — every protocol action requires an aggregated BLS signature from a quorum of oracles. The threshold is ceil(2n/3). With three oracles, that means two must agree. A single dissenter blocks nothing. Two dissenters block everything.
BLS consensus flow — three oracles sign independently, signatures aggregate, Vision.sol verifies against registered pubkeys

​
Security Boundaries

Trust is not a feeling. It is a line drawn between what you control and what you don’t. Every boundary in this system is enforced by either cryptography or smart contract logic — never by good intentions.
Trust boundaries — player controls (on-chain, trustless) vs oracle controls (BLS consensus) vs what oracles cannot do

​
Source Modules

ModuleResponsibility
Vision.solBatch registry, bitmap commits, config hashes, claim verification
VisionReserve.solUSDC custody — deposits, withdrawals, reward transfers
OracleRegistry.solBLS public key management, aggregated pubkey, threshold
Tick EnginePer-batch tick scheduling, resolution, bitmap flip
ResolverPrice comparison, parimutuel matching, PnL computation
Config OrchestratorData-node polling, config proposals, BLS consensus on updates
Chain ListenerL3 event monitoring — new batches, bitmap updates, deposits
Bitmap StoreTwo-slot (pending/active) bitmap management per player per batch
BLS SignerPrivate key operations, signature aggregation
Data Node98-source collection, PostgreSQL storage, REST + WS + SSE serving
Each oracle runs co-located with its own data-node process. They share a VPS but not a database. The frontend data-node is a separate, read-only instance that serves public API traffic without interfering with oracle data pipelines.