Magistery

Protocol Stack, Apps, and Ecosystem Roadmap

The full Magistery stack — from core contracts to SDK, subgraph, bots, and application templates anyone can build.

Magistery is a protocol - contracts that anyone builds on. The contracts are Layer 0. Everything below is what gets built on top to make the protocol useful, viral, and unstoppable.

Architecture

LAYER 0: Contracts (deployed, immutable, done)
  MarketFactory, OrderBook, Treasury, NegRiskAdapter
  UMAResolver, KalshiResolver, PolymarketResolver, OperatorResolverFactory

LAYER 1: SDK (exists, TypeScript/viem)
  MagisteryClient  - typed contract interactions, fee math, safety checks

LAYER 2: Indexer (The Graph subgraph)
  Decentralized, permissionless, no server
  Every app needs this  - fast queries for markets, orders, positions, volume

LAYER 3: Application templates (open source, forkable)
  ├── polymarket-clone/      - 1-click deployable prediction market frontend
  ├── telegram-bot/          - prediction market bot for any Telegram group
  ├── discord-bot/           - same for Discord
  ├── embed-widget/          - web component any site can drop in
  └── keeper-bot/            - automated order matching service

Everything is open source. Everything is permissionless. No servers we control, no APIs we run, no accounts we manage. Anyone forks, anyone deploys, anyone customizes. We get 0.1% on every trade regardless of which app generates it.

Layer 2: The Graph Subgraph

The subgraph is the data layer every application needs. Without it, every frontend independently replays the entire blockchain history to build current state. With it, any app gets instant GraphQL queries.

What it indexes:

  • MarketCreated → market entity (question, creator, resolver, deadline, status)
  • OrderPlaced → order entity (maker, side, price, amount, market)
  • OrderFilled → update filled amounts, create fill entity, compute volume
  • OrderCancelled → mark order cancelled
  • MarketResolved → mark market resolved, record winning outcome
  • NegRiskAdapter events → multi-outcome market entities

What apps can query:

  • All active markets (sorted by volume, deadline, creation date)
  • Order book for any market (open bids and asks, depth)
  • User's positions across all markets (tokens held, P&L)
  • Trade history for any market
  • Protocol-wide stats (total volume, active markets, fees collected)

Deployment: The Graph Network on Polygon. Decentralized - no server, no maintenance, no control. Anyone can query. Funded by GRT query fees (negligible cost).

Priority: #1. This unblocks everything else.

Layer 3: Application Templates

Polymarket Clone (1-click frontend)

A complete prediction market frontend. Fork the repo, set env vars, deploy to Vercel/IPFS.

What it includes:

  • Market discovery (browse, search, filter by category/resolver/status)
  • Market detail (order book visualization, price chart, trade history)
  • Trading interface (place buy/sell orders, cancel orders)
  • Portfolio (positions, P&L, open orders)
  • Market creation flow (create market, link resolver, set deadline)
  • Resolution flow (assert outcome, track liveness, settle)
  • Wallet connection (RainbowKit/wagmi)
  • Safety checks built in (resolver whitelist, linking checks, deadline warnings)

What the deployer customizes:

  • Branding (logo, colors, name)
  • Trusted resolver whitelist
  • Featured markets
  • Categories/tags
  • Domain

Stack: Next.js, viem, Magistery SDK, The Graph subgraph.

Every instance uses the same contracts. Every trade generates 0.1% to treasury.

Magistery Bot — SHIPPED

Open source, production-grade, modular prediction market bot. First application built on Magistery.

Repository: github.com/0xMagistery/bot

What it does:

  • Operators deploy their own instance, set their fee, earn on every trade
  • Users deposit TON USDT — LayerSwap bridges to Polygon, auto-swaps to USDC
  • Browse/search Polymarket markets, bet via inline buttons or natural language (AI assistant)
  • Copy trading — follow any address, auto-mirror trades
  • Background keeper matches orders, resolves markets, settles positions automatically
  • Winnings auto-return to user's TON wallet after resolution
  • Community resolution via proposals, disputes, and polls
  • 561 tests, crash-safe settlement, operator fees

Architecture: Modular core engine with pluggable adapters (Telegram shipped, Discord/web planned), payment rails (LayerSwap), and market sources (Polymarket). Single process: bot + keeper + catalog sync.

Deploy: One-click Railway deploy or Docker. See the bot README for full setup.

Why it's viral: Every operator who deploys is a new prediction market venue. Sports groups, crypto groups, gambling communities. Zero friction — no website, no app download, just chat commands.

Discord Bot

Same concept as Telegram, adapted for Discord's slash command system and embed format.

  • /create-market question:Will ETH hit 5k? deadline:2026-12-31
  • /bet outcome:yes amount:50 price:0.65
  • Rich embeds for order books, market status, portfolio
  • Role-based permissions (who can create markets, who can resolve)

Embeddable Widget

A web component that any website drops in to show a live prediction market.

<script src="https://unpkg.com/@magistery/widget"></script>
<prediction-market condition-id="0x..." />

Use cases:

  • News sites embed election/event markets alongside articles
  • Sports sites embed game outcome markets
  • Blogs embed markets relevant to their content
  • Forums let users create and trade inline

The widget connects to the user's wallet (MetaMask/WalletConnect), reads from The Graph, writes via SDK.

Keeper Bot

Automated order matching service. Scans order books for crossable orders and fills them.

  • Monitors OrderPlaced events via subgraph or direct event subscription
  • Identifies BuyVsBuy pairs where prices sum >= $1.00
  • Identifies BuyVsSell pairs where buy price >= sell price
  • Submits fill transactions
  • Earns nothing directly (the surplus goes to order makers), but keepers can be incentivized by frontends or run as a public good

Anyone runs a keeper. More keepers = faster fills = better UX for everyone.

Resolver Expansion

New resolver modules anyone can build and deploy. No changes to core contracts needed.

Already built: UMAResolver, KalshiResolver, PolymarketResolver, OperatorResolverFactory + OperatorResolver

Possible future resolvers:

  • Chainlink Functions resolver - resolve from any API (sports scores, weather, stock prices)
  • Multisig resolver - N-of-M signers agree on outcome (for private/trusted groups)
  • DAO vote resolver - outcome determined by on-chain governance vote
  • Time-weighted oracle resolver - resolve based on TWAP from DEX price feeds

Twitter/Reddit resolution doesn't need a custom resolver - UMAResolver already handles it. The assertion claim is a human-readable string. UMA voters verify by checking the source themselves. That's how UMA is designed.

For quantitative social media data (follower counts, engagement metrics), a Chainlink Functions resolver would call the API and resolve on-chain. But this adds API trust dependency.

Priority Order

  1. The Graph subgraph — DONE (v3.0.0 deployed)
  2. Magistery Bot — DONE (production-grade, open source)
  3. Polymarket clone template — next priority, reference frontend implementation
  4. Keeper bot — ensures fills happen, critical for liquidity
  5. Discord bot — second messaging platform (core engine is platform-agnostic, adapter pattern ready)
  6. Embed widget — passive distribution
  7. New resolvers — as demand requires

Revenue Model

Every application template uses the same contracts. Every matched trade generates 0.1% to treasury. The more apps, the more volume, the more revenue. We don't charge for the templates, the SDK, or the subgraph. The fee is in the contracts, forever, on every trade, from every app.

100 frontends × 100 users each × $1000 daily volume = $10,000 daily volume
$10,000 × 0.1% = $10/day treasury revenue

1000 frontends × 1000 users × $10,000 daily volume = $10B daily volume
$10B × 0.1% = $10M/day treasury revenue

The protocol doesn't need to be popular. It needs to be easy to build on. The apps make it popular.

On this page