> For the complete documentation index, see [llms.txt](https://whitepaper.after-bell.uk/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://whitepaper.after-bell.uk/technical-architecture/system-architecture.md). # System Architecture Maps AFTERBELL’s hybrid order, settlement, outcome, and resolution architecture. ### Architecture at a glance AFTERBELL is a prediction-market product for stock tokens. It combines off-chain order matching with on-chain settlement and outcome representation on Robinhood Chain. ``` User / browser ↓ Frontend → signed order ↓ Off-chain CLOB → matching ↓ CTFExchange on Robinhood Chain ↓ USDG settlement + ERC-1155 outcome position ↓ Market resolution → redemption ``` This is a hybrid architecture. It is not accurate to describe every component as decentralized. The frontend, CLOB, Robinhood REST API cross-check, keeper, and manual resolution evidence are off-chain dependencies. ### Architecture layers | Layer | Component | Location | Primary responsibility | | ------------ | -------------------------- | ------------------------- | ------------------------------------ | | Presentation | Frontend | Off-chain | Market interaction and order signing | | Matching | CLOB | Off-chain | Receive and match signed orders | | Settlement | CTFExchange | On-chain | CLOB settlement | | Outcome | ConditionalTokens | On-chain | ERC-1155 outcome representation | | Oracle | Chainlink stock token feed | On-chain feed integration | Primary price source | | Cross-check | Robinhood REST API | Off-chain | Secondary price verification | | Resolution | OracleResolver | Protocol logic | Resolution and circuit breaker | | Operations | Keeper | Off-chain | Operational execution | | Fees | FeeCollector | On-chain | Fee collection and distribution | Robinhood Chain is an EVM environment with chain ID `4663`. The source identifies an FCFS mempool. It does not specify block timing, consensus, RPC infrastructure, or a gas model. ### Presentation and order layers The frontend is the user-facing control surface. A user discovers a market, selects a Yes or No outcome, and signs trading intent. React provides the interface. viem and wagmi support interaction with the EVM-compatible chain. The signed order then moves to the off-chain CLOB. The CLOB uses Node.js and WebSocket. It receives signed orders and matches compatible orders. Matching is separated from blockchain settlement: the CLOB determines compatible trading intent, while smart contracts execute and enforce settlement. The source identifies EIP-712 signed orders. This means the user signs structured order intent. The source does not provide the typed-data schema, order types, priority rules, partial-fill behavior, cancellation mechanics, or persistence design. ### Settlement and outcome layers Matched activity proceeds toward CTFExchange, the on-chain settlement component. It supports CLOB settlement and batch execution. Settlement uses USDG and produces or transfers the ERC-1155 outcome position described by ConditionalTokens. The system can match an order against another participant or mint new shares from USDG. This describes two high-level paths into an outcome position. The source does not specify the minting algorithm or the exact settlement sequence for either path. ConditionalTokens represents binary outcomes as Yes and No positions. It supports split, merge, and redeem operations. For a market asking, “Will NVDA close above $150 on Friday?”, the eventual winning position retains redemption value. The losing position becomes worthless. ### Resolution and fee layers Resolution depends on Chainlink’s stock token feed as the primary source and the Robinhood REST API as an off-chain cross-check. OracleResolver reads and cross-checks the data. If the two prices disagree by more than 5%, the market pauses and manual resolution can use off-chain evidence. This is the protocol’s “trust, but verify, twice” approach. It creates an exception path instead of claiming fully automatic resolution under every condition. MarketFactory establishes markets and associated fee configuration. FeeCollector handles fee collection and distribution. The specified rates are 0.5% for trading and 0.1% for resolution. Fees are allocated 70% to the treasury, 20% to market-maker subsidies, and 10% to the keeper bot. The economics pages describe that allocation in detail. ### End-to-end example Consider a user who selects **Yes** for “Will NVDA close above $150 on Friday?” 1. The frontend presents the market and the Yes/No choice. 2. The user signs an EIP-712 order through the frontend. 3. The off-chain CLOB receives the signed intent over its order interface. 4. The matching engine matches it with compatible participant intent, or the system uses the stated USDG-backed new-share path. 5. CTFExchange provides the on-chain settlement boundary. 6. USDG settles the position, and the user receives or holds an ERC-1155 outcome position. 7. The market stays open until its defined resolution condition is reached. 8. Chainlink provides the primary resolution price. 9. The Robinhood REST API provides the independent cross-check. 10. A discrepancy above 5% pauses the market for manual-resolution evidence. 11. Otherwise, the verified result determines the winning outcome. 12. ConditionalTokens supports redemption of the winning position. This is an architectural walkthrough, not a statement about individual transactions or contract calls. The source does not provide their exact implementation sequence. ### Trust boundaries and status The CLOB, WebSocket connection, Robinhood API, keeper, and manual-resolution evidence are operational trust dependencies. The CLOB does not perform settlement on-chain. Manual resolution means an administrative exception path exists when the circuit breaker activates. These boundaries should be evaluated alongside the on-chain contracts. {% hint style="warning" %} AFTERBELL is under development. Smart contracts are not yet audited. An audit is planned before mainnet. This architecture is a v0.1 September 2026 design, not production-proven infrastructure. {% endhint %} --- # 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://whitepaper.after-bell.uk/technical-architecture/system-architecture.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.