Architecture Map
    Updated 2026-05-0412 min read

    Prediction Market Platform Architecture Map: Exchanges, Wrappers, Routers, Perps Rails, and Intelligence Layers

    One consumer-facing brand can hide multiple control layers underneath it. This map splits listing, execution, settlement, clearing, app surface, and editorial intelligence into separate roles.

    Architecture Lanes

    6

    Stack Roles

    5

    Matrix Columns

    7

    Taxonomy Items

    6

    How to read this architecture map

    Separate the rail, wrapper, router, clearing stack, and intelligence layer before comparing brands.

    “Prediction market platform” now describes several different products. This map separates the rail that writes rules, the app that displays markets, the router that may choose execution paths, and the intelligence layer that explains what the market means.

    Use the map to answer control questions first: who lists contracts, who executes, who settles, who handles the account surface, and who is only explaining the market to readers.

    This is a map, not a ranking. It is not investment advice, an endorsement of any venue, or a trade execution feature.

    Six layers people flatten into one phrase

    Start by asking which layer controls the thing you care about.

    Rules + settlement

    Direct exchange / regulated rail

    The venue lists contracts and controls exchange mechanics directly.

    User question

    Who writes the contract rules and resolves the market?

    Controls
    contract listing
    rulebook
    settlement process
    exchange access
    Examples
    Kalshi
    Polymarket US / QCX
    Forecastex
    Predictit
    Primary sources needed
    • CFTC DCM/DCO registry rows
    • official platform rulebooks
    • official regulatory status records
    UX + catalog subset

    Wrapper / distribution app

    A familiar consumer app surfaces contracts from an underlying exchange rail.

    User question

    Why does this app show fewer markets or different support language than the exchange itself?

    Controls
    front-end UX
    catalog subset
    support flow
    account display
    Examples
    Coinbase
    Robinhood
    Prizepicks
    FanDuel Predicts
    Primary sources needed
    • official partner announcements
    • official routing/partner documentation
    • wrapper help-center docs
    Execution path

    Smart-order-routing aggregator

    A product tries to find or split execution across venues instead of only showing odds.

    User question

    Is this just a comparison table, or is it routing execution?

    Controls
    market matching
    route selection
    order splitting
    execution UX
    Examples
    Primary-source detail not enough yet
    Primary sources needed
    • official launch page or docs
    • terms of service
    • supported venue list from the product itself
    Market creation

    User-generated marketplace

    Users can create or seed markets rather than relying only on centrally curated listings.

    User question

    Who decides what markets exist?

    Controls
    market creation flow
    liquidity incentives
    moderation
    listing rules
    Examples
    Primary-source detail not enough yet
    Manifold (Non-Money Reference)
    Primary sources needed
    • official platform docs
    • official announcement page
    • terms/listing policy
    Funding / margin logic

    Perps / margin-style rail

    A rail packages prediction-like outcomes or adjacent derivatives inside a margin/perpetuals product surface.

    User question

    Is this a binary event contract, a perpetual, or something else?

    Controls
    margin model
    fee model
    liquidation/funding logic
    collateral rules
    Examples
    Primary-source detail not enough yet
    Kalshi Timeless
    Polymarket Perps
    Primary sources needed
    • official protocol/platform docs
    • official proposal pages
    • official regulatory status records where applicable
    Context + source discipline

    Media / intelligence layer

    A product explains markets, sources, rules, and context without executing trades.

    User question

    Where do I go to understand what the market means and whether the signal is trustworthy?

    Controls
    editorial explanation
    source links
    tracker maintenance
    rule/context interpretation
    Examples
    PredictionMarkets.US
    Primary sources needed
    • internal public pages only; no claims of brokerage or execution

    Controls matrix

    Rows are architecture lanes. Each card answers the decisions users often assume one brand controls.

    Direct exchange / regulated rail

    Who controls contract listing?

    Exchange / rail

    Who controls execution?

    Exchange orderbook

    Who controls support/account display?

    Exchange or member-facing app

    Who controls settlement/oracle?

    Rulebook + settlement process

    Who controls market creation?

    Central listing process

    Who captures fees or economic upside?

    Exchange / rail economics

    What does the user actually do here?

    Trade directly on the venue

    Wrapper / distribution app

    Who controls contract listing?

    Underlying rail, filtered by app

    Who controls execution?

    Underlying exchange rail

    Who controls support/account display?

    Wrapper app

    Who controls settlement/oracle?

    Underlying rulebook

    Who controls market creation?

    Underlying rail, not the wrapper alone

    Who captures fees or economic upside?

    Wrapper + underlying rail, depending on terms

    What does the user actually do here?

    Use a familiar app surface

    Smart-order-routing aggregator

    Who controls contract listing?

    Matched venues / supported rails

    Who controls execution?

    Router logic + destination venue

    Who controls support/account display?

    Router product

    Who controls settlement/oracle?

    Destination venue

    Who controls market creation?

    Usually not the router

    Who captures fees or economic upside?

    Router and/or routed venue

    What does the user actually do here?

    Route or compare execution paths

    User-generated marketplace

    Who controls contract listing?

    Users plus moderation policy

    Who controls execution?

    Marketplace rules

    Who controls support/account display?

    Marketplace product

    Who controls settlement/oracle?

    Platform-specific resolution model

    Who controls market creation?

    User creation flow

    Who captures fees or economic upside?

    Marketplace and market creators/liquidity providers

    What does the user actually do here?

    Create, seed, or trade user-listed markets

    Perps / margin-style rail

    Who controls contract listing?

    Rail / protocol / platform

    Who controls execution?

    Margin or perpetuals engine

    Who controls support/account display?

    Perps surface

    Who controls settlement/oracle?

    Funding, margin, and oracle logic

    Who controls market creation?

    Rail governance or platform listing

    Who captures fees or economic upside?

    Rail economics, funding, and fee model

    What does the user actually do here?

    Trade an adjacent derivative, not always a binary event contract

    Media / intelligence layer

    Who controls contract listing?

    No listing control

    Who controls execution?

    No execution control

    Who controls support/account display?

    No account surface

    Who controls settlement/oracle?

    Explains source and rule differences only

    Who controls market creation?

    No market-creation control

    Who captures fees or economic upside?

    No brokerage, clearing, routing, or custody

    What does the user actually do here?

    Understand markets, sources, rules, and platform differences

    Operating-model matrix

    The same consumer brand can combine curation, execution, fees, settlement, and regulatory roles in different ways.

    Token exposure is not contract exposure. A platform can have exchange fees, app economics, protocol fees, collateral tokens, governance tokens, or no token surface at all; this map keeps those layers separate.

    Direct exchange / regulated rail

    Curation

    Listings and rulebook controlled by the exchange or regulated rail.

    Execution

    Venue orderbook and matching mechanics control whether an order actually trades.

    Value accrual

    Exchange and, where applicable, clearing economics accrue to the regulated rail.

    Fee model

    Contract, trading, and clearing fees follow the venue's official schedule.

    Settlement / oracle

    The rulebook and designated settlement source or oracle control the outcome.

    Regulated stack role

    May include a DCM and, where vertically integrated, a DCO or clearing stack.

    Token / exposure model

    May use cash, collateral tokens, clearing margin, or no public token at all depending on the rail. Token mechanics do not define exchange status.

    Economic caution

    Do not infer exchange economics, clearing economics, or user upside from a token ticker unless official filings or platform docs say so.

    Wrapper / distribution app

    Curation

    The app exposes a selected catalog from one or more underlying rails.

    Execution

    Orders route to or through an underlying exchange, clearing, or partner relationship.

    Value accrual

    Distribution, account-surface, or partner economics accrue around the consumer app layer.

    Fee model

    App and partner economics may differ from the underlying rail's public fee schedule.

    Settlement / oracle

    The underlying rail's rulebook controls the contract outcome, not the wrapper screen alone.

    Regulated stack role

    Often an FCM, IB, member, or support surface rather than the DCM/DCO itself.

    Token / exposure model

    Usually exposes the underlying rail through an app account; any app equity, public-company stock, loyalty program, or token surface is separate from the contract itself.

    Economic caution

    Do not treat buying the wrapper company's stock or token as equivalent to trading the routed prediction-market contract.

    Smart-order-routing aggregator

    Curation

    The product matches equivalent or near-equivalent markets across supported venues.

    Execution

    Route selection or order splitting may choose the destination venue when supported.

    Value accrual

    Router software, spread, fee, or subscription economics may accrue at the routing layer.

    Fee model

    Users need to inspect both router costs and destination-venue trading costs.

    Settlement / oracle

    The destination venue still controls the outcome and settlement source.

    Regulated stack role

    Terms and registrations must be checked before assuming broker, FCM, or exchange status.

    Token / exposure model

    May charge software, routing, subscription, spread, or protocol fees; token exposure is unverified unless the router's own docs specify it.

    Economic caution

    A router can capture value without controlling settlement, and a token or fee switch does not prove the router owns the destination venue's economics.

    User-generated marketplace

    Curation

    Users create or seed markets subject to platform moderation and listing policy.

    Execution

    Platform-specific marketplace mechanics control trading and liquidity.

    Value accrual

    Economics may accrue to the platform and, where allowed, creators or liquidity providers.

    Fee model

    Marketplace fee and revenue rules are platform-specific and should be read directly.

    Settlement / oracle

    Resolution depends on the platform's resolver, oracle, moderation, or community process.

    Regulated stack role

    Do not treat it as equivalent to a CFTC-regulated DCM unless official filings say so.

    Token / exposure model

    May use platform credits, points, creator incentives, liquidity incentives, or tokens depending on the marketplace design.

    Economic caution

    User-created-market incentives are not the same as regulated exchange economics or guaranteed creator revenue.

    Perps / margin-style rail

    Curation

    A protocol or platform lists contracts, markets, or prediction-like instruments on the rail.

    Execution

    A perps, margin, liquidation, or funding engine controls execution behavior.

    Value accrual

    Fees, funding, liquidations, or protocol economics may capture value at the rail.

    Fee model

    Trading, funding, collateral, and liquidation rules matter more than a simple contract fee.

    Settlement / oracle

    Oracle, funding, margin, and collateral rules control payoff mechanics.

    Regulated stack role

    Varies by product; verify separately from event-contract DCM status.

    Token / exposure model

    Often has the clearest token/protocol-fee surface: collateral, funding, liquidations, governance, or fee capture can sit inside the rail.

    Economic caution

    Do not translate protocol-fee capture or governance-token narratives into event-contract user returns without primary-source support.

    Media / intelligence layer

    Curation

    Editorial selection chooses which explainers, trackers, and source-linked pages to maintain.

    Execution

    No order execution, routing, matching, custody, clearing, or brokerage occurs here.

    Value accrual

    Audience, research, and editorial product value accrues without routing trades.

    Fee model

    No brokerage, clearing, custody, or execution fee is charged by the intelligence layer.

    Settlement / oracle

    The layer explains rule and source differences; it does not resolve markets.

    Regulated stack role

    No DCM, DCO, FCM, or IB role.

    Token / exposure model

    No token, collateral, custody, staking, clearing, or execution exposure is created by reading an intelligence page.

    Economic caution

    Audience or subscription value is not trade execution, brokerage, clearing, custody, or token exposure.

    Rail taxonomy: what kind of market surface are you looking at?

    Separate exchange venue, clearing stack, crypto-native rail, app wrapper, consent lane, and editorial intelligence layer before assuming control.

    PredictionMarkets.US is not a broker, router, exchange, custodian, clearinghouse, or execution venue.

    Official Hyperliquid docs now verify HIP-4 as an outcome-market primitive. Market breadth, live volume, and competitive impact still require primary or owned data before being rendered as facts.

    App brand, exchange rail, clearing stack, consent framework, and editorial layer are separate questions.

    Reader diagnostic

    CFTC exchange / regulated event-contract venue rail

    A venue or exchange rail controls contract listing, rulebook mechanics, orderbook access, and the official settlement path for regulated event contracts.

    User question

    Is the place I am using the actual exchange rail, or just an app showing that rail?

    Examples policy: Use examples only when the venue status is supported by CFTC records or official venue documentation; do not add live status from affiliate or media pages.
    Example labels
    Kalshi
    ForecastEx
    verified DCM / official venue records only
    Controls
    • contract listing
    • rulebook mechanics
    • orderbook access
    • settlement path
    Does not control
    • third-party wrapper UX
    • every app support workflow
    • unverified clearing or broker status
    Source requirements
    CFTC venue records
    official exchange rulebook
    official platform help center or docs
    Risk if misread

    A reader may treat a wrapper or media summary as if it controls the contract, then miss the actual rulebook and settlement source.

    Reader diagnostic

    Clearing / FCM / institutional access stack

    A clearing, FCM, or institutional access layer can sit beside an exchange rail without being the same thing as the consumer-facing app.

    User question

    Who clears, intermediates, or gives institutional access — and is that status actually verified?

    Examples policy: CDNA/CME-style partner or institutional-access labels stay source-requirement language until supported by CFTC, NFA, or official partner records.
    Example labels
    CDNA / CME partner stack — source-required
    FCM
    DCO
    institutional access layer
    Controls
    • clearing relationship where verified
    • intermediation where verified
    • institutional access terms where verified
    Does not control
    • market title wording
    • app catalog curation
    • event-resolution source unless the rulebook says so
    Source requirements
    CFTC registry or filing
    NFA record where applicable
    official partner announcement
    official clearing or access documentation
    Risk if misread

    A reader may overstate a partner, clearing, or broker role and turn a stack component into a false platform-status claim.

    Reader diagnostic

    Crypto-native event rail

    A crypto-native rail may use collateral tokens, smart contracts, protocol governance, or on-chain settlement instead of a traditional regulated venue stack.

    User question

    Is this an event-contract venue, a crypto execution rail adding outcome contracts, or just a reported future feature?

    Examples policy: Polymarket / QCX LLC d/b/a Polymarket US split can be discussed through official platform records; Hyperliquid HIP-4 can be described only as an official-docs-verified outcome-market primitive, while breadth, volume, adoption, and competitive impact remain source-gated.
    Example labels
    Polymarket / QCX where source-backed
    Hyperliquid HIP-4 — official docs verify primitive
    crypto-native outcome rail
    Controls
    • protocol or platform execution mechanics where documented
    • collateral or token rail where documented
    • on-chain or oracle process where documented
    Does not control
    • CFTC venue status without official records
    • U.S. app availability
    • off-chain support or wrapper behavior
    Source requirements
    official protocol docs
    official platform docs
    official governance/proposal source
    CFTC or U.S. official record for regulated-venue claims
    Risk if misread

    Official docs can verify a primitive without proving live breadth, durable liquidity, user adoption, market share, or competitive impact.

    Reader diagnostic

    App / wrapper / distribution rail

    A consumer app can distribute, filter, or explain markets from an underlying exchange rail while leaving the contract language and settlement path elsewhere.

    User question

    Does the app brand control the market, or is it distributing another rail?

    Examples policy: Robinhood, FanDuel, DraftKings, Underdog, PrizePicks, and similar app brands should be described as distribution surfaces only when official docs support the underlying rail relationship.
    Example labels
    Robinhood-style wrapper
    FanDuel / DraftKings-style distribution
    Underdog / PrizePicks-style app surface
    Controls
    • front-end UX
    • catalog presentation
    • support path
    • account display where applicable
    Does not control
    • underlying contract wording unless officially stated
    • settlement source
    • clearing role without official records
    Source requirements
    official app documentation
    official partner disclosure
    underlying exchange docs or rulebook
    Risk if misread

    A reader may blame the app for a rule or settlement mechanic controlled by the underlying exchange rail.

    Reader diagnostic

    Consent-constrained / sport-specific lane

    Some categories, especially horse racing/IHA-style contexts, require a separate permission or consent lens rather than a generic sports-market label.

    User question

    Is this market constrained by a sport-specific consent framework instead of ordinary event-contract taxonomy?

    Examples policy: Keep this generic unless an official statute, regulator, venue rule, or league/source document supports the specific lane.
    Example labels
    horse racing / IHA-style consent lane
    sport-specific permission framework
    Controls
    • category eligibility lens
    • consent or permission requirement where verified
    • source discipline for sport-specific rules
    Does not control
    • all sports markets
    • state gambling-law outcomes by itself
    • platform legality outside the specific framework
    Source requirements
    statute or official regulator source
    official venue rulebook
    official league or consent documentation where applicable
    Risk if misread

    A reader may flatten horse-racing consent constraints into generic sports-betting law and miss the specific source needed.

    Reader diagnostic

    Media / intelligence layer

    An intelligence layer explains rules, rails, sources, and risks without routing trades or controlling settlement.

    User question

    Am I looking at an explanation layer or a place that can actually take or settle an order?

    Examples policy: PredictionMarkets.US can describe itself only as an editorial/source-linking intelligence layer, never as a broker, router, exchange, custodian, or clearing venue.
    Example labels
    PredictionMarkets.US editorial intelligence layer
    Controls
    • source curation
    • rule explanation
    • cross-platform literacy
    • internal linking
    Does not control
    • trade execution
    • order routing
    • brokerage
    • custody
    • clearing
    • market settlement
    Source requirements
    public editorial page
    primary sources for each platform capability claim
    no execution or custody claim without official records
    Risk if misread

    A reader may confuse analysis with execution capability; the page explicitly separates those roles.

    Rail and clearing stack are separate questions

    Separate verified stack pieces from pending rail watch items before turning a product headline into an infrastructure claim.

    Official sources checked
    DCM
    DCO

    Gemini Titan + Gemini Olympus

    Gemini has venue + clearing pieces for regulated derivatives/prediction markets; do not describe it as a broker/FCM unless that status is verified.

    Not verified here

    FCM status is not rendered as verified. Do not describe this as a complete customer-facing broker stack without official records.

    Official source spine
    • https://www.globenewswire.com/news-release/2026/04/30/3284943/0/en/Gemini-Receives-DCO-License-Approval-From-CFTC.html
    • https://www.cftc.gov/IndustryOversight/IndustryFilings/TradingOrganizations?search=Gemini
    • https://www.cftc.gov/IndustryOversight/IndustryFilings/TradingOrganizations/44472
    • https://www.cftc.gov/IndustryOversight/IndustryFilings/ClearingOrganizations?search=Gemini
    • https://www.cftc.gov/IndustryOversight/IndustryFilings/ClearingOrganizations/59189
    official docs verified primitive
    render docs verified primitive only

    Hyperliquid HIP-4 outcome rail

    Pending-source policy

    Official Hyperliquid docs verify the HIP-4 primitive; this card still withholds market breadth, live volume, user adoption, and competitive-impact claims until primary or owned data supports them.

    Official Hyperliquid docs now verify HIP-4 outcome markets as fully collateralized fixed-range contracts useful for prediction markets and bounded options-like instruments. Market breadth, live volume, user adoption, and competitive impact still require primary or owned data before being rendered as facts.

    User question

    Is this a regulated event-contract venue or a crypto execution rail adding outcome contracts?

    Source requirements
    • Official Hyperliquid HIP-4 docs verify the outcome-market primitive
    • Primary or owned data required for market breadth, live volume, user adoption, market-share, or competitive-impact claims
    • CFTC or U.S. official record required before any regulated-venue claim

    Toolchain / Workbench Memo

    The stack is not one thing; ask what the tool controls.

    Am I looking at a venue, wrapper, client library, router, dashboard, or intelligence layer?

    Control layer

    Official venue API / client

    The venue's official API or client surface is documented by the exchange or rail operator.

    Examples policy: Render category labels unless the venue's official API docs, help center, rulebook, or regulated rail records were re-fetched same-session.
    Controls
    • Access documentation
    • Supported order and market data interfaces
    • Venue-specific integration requirements
    Does not control
    • Third-party dashboard claims
    • External app support flows
    • Another venue's settlement source
    Source requirements
    Official venue documentation
    Official platform help center
    CFTC, NFA, or official rail records when regulatory status is claimed
    Control layer

    Third-party bot client / SDK wrapper

    A developer tool can make a venue API easier to use without controlling the market's rulebook or settlement path.

    Examples policy: Do not render specific tool names unless official docs, a maintained repository, or an official launch page were re-fetched same-session.
    Controls
    • Developer ergonomics
    • Client-side helper functions
    • Integration workflow around a venue API
    Does not control
    • Contract wording
    • Order matching at the destination venue
    • Market resolution or settlement
    Source requirements
    Official tool documentation
    Official repository controlled by the tool author
    Official venue docs for any claim about the underlying API
    Control layer

    Analytics dashboard / terminal

    A dashboard or terminal observes markets and packages data; observation is not execution or settlement control.

    Examples policy: Render the category only unless the dashboard's official product page or docs were re-fetched same-session.
    Controls
    • Charts and screens
    • Filtering and watchlists
    • Data presentation and alerts
    Does not control
    • Venue rulebooks
    • Clearing or custody
    • Resolution-source selection
    Source requirements
    Official product page
    Official documentation
    Primary venue source for any underlying market rule claim
    Control layer

    Smart router / execution layer

    A routing layer may choose where an order goes, but the destination venue still controls the contract and settlement rules.

    Examples policy: Do not name a router unless official launch pages, terms, or docs prove what it routes and what it does not route.
    Controls
    • Route choice when officially documented
    • Execution-path comparison
    • Order-splitting or destination selection UX
    Does not control
    • Destination venue settlement
    • Destination venue rulebook
    • Clearing, custody, or brokerage status unless official records say so
    Source requirements
    Official router documentation
    Official terms of service
    Official supported-venue list
    Control layer

    Wrapper app

    A consumer app can provide account UX, support language, and catalog curation over an underlying rail.

    Examples policy: Render app names only when official partner pages, help-center docs, or regulatory records close the support and rail relationship.
    Controls
    • Account and support surface
    • Catalog visibility
    • User-facing product flow
    Does not control
    • Underlying exchange rulebook by itself
    • Settlement source by itself
    • Every market listed on the rail
    Source requirements
    Official partner announcement
    Official wrapper help center
    Underlying rail documentation
    Control layer

    Media / intelligence layer

    An intelligence layer explains rules, source differences, operational risks, and context without taking orders.

    Examples policy: Render as a category and describe the control boundary; do not imply execution, custody, clearing, or brokerage.
    Controls
    • Explanation and context
    • Source discipline
    • Cross-platform literacy
    Does not control
    • Trade execution
    • Routing or brokerage
    • Clearing, custody, or market settlement
    Source requirements
    Public editorial page
    Primary sources for every platform capability claim
    No execution or custody claim without official registration records

    Positioning rules

    • PredictionMarkets.US does not route trades.
    • PredictionMarkets.US does not custody funds.
    • PredictionMarkets.US explains source/rule risk and operational context.
    • Tool names require primary docs or official launch pages before rendering.

    No-go claims

    • Do not imply a client library, SDK, bot, or analytics dashboard controls settlement.
    • Do not imply PredictionMarkets.US competes as a broker, router, exchange, or execution venue.
    • Do not turn the architecture map into a current-state tool directory; directories rot.
    • Do not name third-party tools unless official docs or launch pages were re-fetched same-session.

    If your problem is… inspect this layer first

    A fast routing guide for figuring out which architecture layer actually explains the issue.

    Market missing

    Curation / listing layer

    The app may only expose a subset of markets, or the rail may not list that contract.

    Order fills weird

    Execution / router / orderbook layer

    Separate the visible button click from orderbook depth, routing, and destination venue mechanics.

    Balance display weird

    Wrapper / account-display layer

    A wrapper can show balances, collateral, or support language differently from the underlying rail.

    Outcome disputed

    Settlement / oracle layer

    Resolution depends on the rulebook, source hierarchy, and oracle process — not just the app screen.

    What does this mean?

    Intelligence / source layer

    Use sourced context before treating a market price, launch, or platform announcement as a trade signal.

    PredictionMarkets.US role and source discipline

    Where the editorial layer stops and where trading, routing, or custody would begin.

    PredictionMarkets.US role

    PredictionMarkets.US is the intelligence and source-linking layer. We explain markets, sources, rules, platform differences, settlement context, and user-facing mechanics.

    PredictionMarkets.US does not route trades, execute orders, broker, clear, or custody funds.

    Source discipline

    Platform-capability claims should come from official documentation, rulebooks, filings, help-center materials, or platform-maintained source pages. Crypto press, trade press, social posts, and forum threads are not treated as primary citations for what a platform controls.

    Where primary-source detail is not enough yet, the map says so instead of treating a launch rumor or secondary article as verified infrastructure.

    DCM, DCO, FCM, and IB labels should come from CFTC, NFA, or official platform records before they are treated as platform-specific facts.

    Regulated stack roles are not the same as brand names

    A trading app, exchange, clearinghouse, broker, and research layer can be separate entities.

    Stack role

    DCM — Designated Contract Market

    A CFTC-registered trading venue for listed derivatives contracts.

    Controls

    Market rules, listing standards, trading access, and venue operations under its rulebook.

    Does not mean

    It does not automatically mean the consumer brand is the clearinghouse, broker, or support app.

    Stack role

    DCO — Derivatives Clearing Organization

    A CFTC-registered clearing organization that manages clearing and settlement obligations.

    Controls

    Clearing, margin or collateral rules, risk management, and settlement performance for cleared contracts.

    Does not mean

    It is not the same thing as the trading app a user sees.

    Stack role

    FCM — Futures Commission Merchant

    A registered intermediary that can handle customer futures activity and account relationships.

    Controls

    Customer-facing account, order, margin, and support functions depending on the arrangement.

    Does not mean

    It does not by itself list contracts or operate the exchange rulebook.

    Stack role

    IB — Introducing Broker

    An intermediary that introduces customer business to an FCM or regulated rail.

    Controls

    Customer introduction, distribution, and routing relationship details stated in official records.

    Does not mean

    It does not clear trades or replace the underlying exchange and clearing stack.

    Stack role

    Intelligence layer

    A source-linked editorial and analytical layer that helps readers understand markets.

    Controls

    Explanation, context, source discipline, trackers, and cross-platform literacy.

    Does not mean

    It is not a broker, router, DCM, DCO, FCM, IB, custodian, or clearing service.

    What the map does not do

    Restraints that keep the taxonomy descriptive instead of promotional.

    Does not rank lanes as better or worse.
    Does not claim PredictionMarkets.US routes trades, executes orders, or offers brokerage services.
    Does not call any router a partner unless there is a primary-source relationship.
    Does not cite crypto/trade press as primary source for platform capabilities.
    Does not infer token value, investment upside, or user economics from media commentary.
    Does not treat user-generated markets as legally equivalent to CFTC-regulated exchanges.
    Does not collapse wrapper apps and underlying exchange rails into the same product.
    Does not include live volume/user-count numbers unless sourced from a primary page or official filing same session.
    Does not use competitor sites as citations; read them for intel only and replace with primary sources.
    Does not collapse DCM, DCO, FCM, IB, or entity-map roles into consumer brand labels.
    Does not treat governance tokens, collateral tokens, protocol fees, or app equity as interchangeable economic exposure.
    Does not name a third-party tool unless its official docs or launch page were re-fetched same-session.
    Does not imply a client library, SDK, bot, or analytics dashboard controls settlement.
    Does not imply PredictionMarkets.US competes as a broker, router, exchange, or execution venue.
    Does not turn the architecture map into a current-state tool directory; directories rot. This page defines control layers.
    Does not call Hyperliquid a CFTC-regulated prediction market unless official CFTC/US records support it.
    Does not cite crypto press for HIP-4 facts.
    Does not imply Gemini has a full CFTC stack if FCM remains unverified.
    Does not imply PredictionMarkets.US routes, brokers, clears, or executes trades.
    Does not rank platforms by better architecture; explain control layers.
    Does not promote media-reported rail launches into verified platform facts without official source closure.
    Does not collapse app distribution, exchange venue, clearing stack, crypto-native rail, consent framework, and editorial intelligence into one product label.

    Map scope and metadata

    A quick read on update timing, scope, and the kind of page this is.

    Last updated

    2026-05-04

    Scope

    Product architecture taxonomy for consumer education, not a live trading feature.

    Read it as

    Map, not execution

    Continue exploring

    Prediction Market Platform Architecture Map 2026 | PredictionMarkets.US