> For the complete documentation index, see [llms.txt](https://docs.prophecypredict.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prophecypredict.xyz/welcome/readme.md). # Introduction **Prophecy is an on-chain prediction market protocol.** It provides the smart contracts that venues, creators, traders, and liquidity providers use to run branded prediction markets with transparent trading, automated resolution, and self-custodial settlement. Prophecy is **protocol, not platform**. Market creation, trading, resolution, redemption, gas sponsorship, and venue gating all happen on-chain. Consumers interact with the contracts directly; nothing about how they do so is prescribed by the protocol. ### What the Protocol Provides * **PredictionMarketCore** — The single write surface. Market creation, buying and selling outcome tokens, liquidity, complete-set mint/merge, redemption, and LP fee claims. * **OrderRouter and FixedProductMarketMaker** — One constant-product AMM per market, deployed as a clone. Each clone is also the market's ERC-20 LP token. * **ConditionalTokens** — Gnosis-style ERC-1155 outcome tokens and collateral escrow. Positions are real tokens held at the trader's own address. * **VenueRegistry** — Permissionless venue registration with per-venue fee rates and an optional pluggable access-control policy. * **VenuePaymaster** — ERC-4337 paymaster that lets venues sponsor trade gas, working with EIP-7702 delegation so traders keep their EOA address. * **Oracle adapters** — The seam between markets and truth. `ProphecyOracleAdapter` bridges the Prophecy Oracle; `OnChainEventAdapter` resolves from a watched contract event. ### What Makes Prophecy Different #### AI-resolved questions, on-chain aggregation Resolution is a separate protocol. The [Prophecy Oracle](/oracle/overview.md) takes a natural-language question with a list of sources, dispatches AI agent subcommittees at a scheduled time, aggregates their responses **on-chain** — median for numeric answers, majority voting for discrete ones — and posts an immutable answer. No human arbitration, no dispute window, no keepers. A question resolves in minutes, and the whole aggregation is auditable in contract state rather than trusted to an off-chain reporter. Somnia's low gas costs are what make full on-chain aggregation practical. Markets bind to a question through an allowlisted adapter. Because the two are separate, one question can settle up to 64 independent markets — different collateral, different venues, different fee tiers — from a single answer, paid for once. #### Positions you actually hold Outcome tokens are ERC-1155 tokens at the trader's own address, backed 1:1 by collateral escrowed the moment they were minted. They can be transferred, held in cold storage, or composed into another protocol without Prophecy's involvement. That structure is why settlement is so simple: winners redeem directly against their own escrow, on their own schedule, with no claim deadline and no dependence on anyone else claiming first. #### Zero protocol fees The protocol takes **nothing**. There is no treasury and no address that can extract value from a trade. Every fee is charged on a trade and goes to a participant: the LP fee to liquidity providers, a routing fee to the venue that brought the trader, a market fee to the venue that created the market, and a creator fee to the market's creator. Venue rates are set by venue owners up to a 10% cap and read live at trade time, with a `maxFeeBps` guard on every trade so no rate change can land on a trader mid-flight. **Settlement is free.** No rake on winnings, no waterfall, no dust. #### Gasless trading `VenuePaymaster` lets a venue sponsor trade gas so users trade without holding SOMI. EIP-7702 delegation keeps the user's EOA address stable, and the paymaster is restricted in-contract to `buy` and `sell` — so a venue's deposit can only ever pay for trades, even if its sponsor key is compromised. #### Gating you define, not gating we guessed Venues attach an optional `IVenuePolicy` contract consulted on market creation, trading, and cross-venue routing. Allowlists, denylists, token gates, and KYC checks are yours to implement, so the rules are as expressive as your product needs. Venues that want no gating attach nothing — the default. *** ### Where to Start * **New to the protocol?** Read [Concepts → Overview](/concepts/overview.md) for a conceptual tour of markets, outcome tokens, trading, and fees with no contract detail required. * **Integrating?** Start with [Developers → Overview](/developers/overview.md), then [Market Definition](/developers/market-definition.md) and the [On-Chain Contracts](/developers/on-chain-contracts.md) reference. * **Operating a venue?** Start with [Operators → Overview](/operators/overview.md), then register in [Creating a Venue](/operators/creating-a-venue.md). * **Resolving questions?** The [Oracle](/oracle/overview.md) section covers the question lifecycle, source types, and consensus. * **Want the bigger picture first?** Read [Why Prophecy](/welcome/why-prophecy.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.prophecypredict.xyz/welcome/readme.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.