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 serviceEverything 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 volumeOrderCancelled→ mark order cancelledMarketResolved→ 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
OrderPlacedevents 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
The Graph subgraph— DONE (v3.0.0 deployed)Magistery Bot— DONE (production-grade, open source)- Polymarket clone template — next priority, reference frontend implementation
- Keeper bot — ensures fills happen, critical for liquidity
- Discord bot — second messaging platform (core engine is platform-agnostic, adapter pattern ready)
- Embed widget — passive distribution
- 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 revenueThe protocol doesn't need to be popular. It needs to be easy to build on. The apps make it popular.