> 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/trust-model/off-chain-components.md). # Off-Chain Components Identifies the services that operate outside the blockchain. ### Hybrid by design AFTERBELL is intentionally hybrid. The blockchain handles settlement and protocol state, while several operational functions remain off-chain. This design separates responsive order handling and external-data verification from contract-enforced settlement and outcome redemption. Off-chain does not automatically mean unsafe. It creates different trust and availability assumptions. The question is not whether a component is “good” or “bad” because it runs off-chain. The question is what that component must do correctly, what happens if it is unavailable, and whether the protocol has an explicit boundary for its output. ``` User / browser ↓ Frontend → signed order ↓ Off-chain CLOB → matching ↓ CTFExchange on Robinhood Chain → settlement ↓ USDG + ERC-1155 outcome position ↓ Resolution and redemption ``` The CLOB, frontend, Robinhood REST API cross-check, off-chain keeper, and manual-resolution evidence all sit outside the chain. They support the product, but they are not the authority that settles an outcome position on Robinhood Chain. ### Frontend: the user-facing control surface The frontend uses React, viem, and wagmi. It is the layer through which a user selects a market, chooses Yes or No, prepares an order, signs that order, and interacts with the protocol. ``` Frontend → market selection → Yes / No selection → order preparation → user signature → protocol interaction ``` The frontend is important because it translates protocol choices into a user action. It should accurately communicate the market and the action the user is about to sign. However, it is not the settlement authority. A frontend display does not itself create an outcome position, move USDG, resolve a market, or make a position redeemable. Those effects occur through the on-chain protocol path. This distinction limits the frontend’s authority, but it does not eliminate its trust assumption. Users depend on the interface to correctly represent available protocol state and to prepare the intended order interaction. An unavailable frontend can impair normal user interaction. It does not, by itself, rewrite already-settled on-chain positions. The architecture does not specify portfolio features, analytics, notifications, wallet-provider choices, or backend API design. Those details are intentionally not inferred here. ### CLOB matching engine: signed intent to compatible match The central limit order book is an off-chain matching engine implemented with Node.js and WebSocket. It receives signed orders and finds compatible trading intent before settlement moves on-chain. ``` User → signed order → off-chain CLOB → compatible order → match → settlement path ``` This is the main operational boundary in the trading flow. Users create signed intent, but the CLOB performs the matching function off-chain. After a match, the settlement path reaches `CTFExchange` on Robinhood Chain. `CTFExchange` is the on-chain settlement component; the CLOB is not an on-chain matching component. Keeping matching off-chain means the blockchain does not execute the entire search for compatible orders. The architecture gains a separation between matching and settlement. The trade-off is that the CLOB becomes an operational dependency for normal new-order matching. If the CLOB is unavailable, normal new-order matching is impaired. This is an availability concern scoped to the matching function. It does not mean already-settled on-chain outcome positions automatically become unsafe, nor does it alter their recorded state by itself. The source identifies EIP-712 signed orders and batch execution at the on-chain settlement boundary. It does not specify the matching algorithm, order priority, cancellation behavior, persistence layer, queue architecture, or throughput. No particular matching policy should be assumed from the existence of a CLOB. {% hint style="info" %} The CLOB determines compatible off-chain intent. `CTFExchange` settles matched activity on-chain. Neither role substitutes for the other. {% endhint %} ### Robinhood REST API: a secondary reference The Robinhood REST API is the secondary cross-check for the Chainlink Stock Token Feed. It is off-chain, external, and a reference source. It is not the primary oracle. It is not an on-chain oracle. It is not described as a decentralized oracle network. ``` Chainlink price vs Robinhood API price ↓ compare values ↓ ≤5%: normal resolution >5%: market pause and manual resolution ``` Chainlink provides the primary value for the resolution path. The Robinhood API provides an independent cross-check before normal resolution. When the two values disagree by more than 5%, the market pauses and manual resolution can use off-chain evidence. This cross-check reduces single-source dependence. It does not prove either value correct. The API is still an external dependency whose data must be available and usable for the comparison path. The architecture does not define its endpoint, polling interval, authentication, rate limits, caching, or retry behavior. ### Off-chain keeper: operational dependency The source identifies an off-chain keeper as part of AFTERBELL’s architecture. It also assigns 10% of the stated fee allocation to the keeper bot. This establishes that keeper operation is a named part of the system’s operational model. The current source does not fully define the keeper’s execution responsibilities or automation behavior. It should not be assumed to submit a particular transaction, follow a particular schedule, or use a particular recovery workflow. The trust implication is therefore narrow but real: some operational execution depends on off-chain infrastructure functioning. The known architecture does not justify claims about its exact workflow, automation guarantees, or availability characteristics. ### Manual resolution evidence: human exception path Manual resolution exists for the case where the automated verification path cannot proceed normally. If Chainlink and the Robinhood API disagree by more than 5%, the market pauses. An administrator then reviews off-chain evidence and can resolve the market manually. ``` Chainlink → Robinhood API cross-check → disagreement above 5% → market pause → administrator reviews off-chain evidence → manual resolution ``` This is a deliberate human trust boundary. The pause prevents an automatic result from being applied while the two reference sources materially disagree. The manual step then requires administrative judgment about the available evidence. The architecture does not identify the administrator, define an evidence hierarchy, specify an appeal process, name a resolution deadline, or describe a governance structure. It would be inaccurate to imply a particular control mechanism. The documented point is simpler: exceptional disagreements can reach manual resolution using off-chain evidence. ### Off-chain trust and availability map | Component | Function | Trust / availability assumption | | --------------- | --------------------- | ------------------------------------------------------ | | Frontend | User interaction | Interface must correctly represent protocol state | | CLOB | Order matching | Matching infrastructure must operate correctly | | Robinhood API | Price cross-check | External reference data must be available and usable | | Keeper | Operational execution | Off-chain execution must function | | Manual evidence | Exception resolution | Administrative judgment is required in exception cases | These assumptions do not override on-chain settlement. They describe the services and decisions that feed the settlement and resolution path. A user should distinguish a contract-enforced state change from the operational conditions needed to reach it. ### Normal and exception paths #### Normal trading The normal trading path begins in the frontend. A user selects a market and outcome, then signs an order. The CLOB receives the signed order over its off-chain interface and matches compatible intent. The matched activity proceeds to `CTFExchange`, which provides on-chain settlement. ``` Frontend → signed order → CLOB → match → CTFExchange → on-chain settlement ``` The CLOB’s role ends at matching. USDG settlement and the ERC-1155 outcome position belong to the on-chain layer. This division means the user’s final protocol position is not merely an entry in the CLOB. #### Normal resolution The normal resolution path uses two distinct reference sources. Chainlink supplies the primary stock-token price. The Robinhood REST API provides the secondary cross-check. If their disagreement is 5% or less, normal resolution proceeds. ``` Chainlink → Robinhood API cross-check → disagreement of 5% or less → resolution ``` The comparison helps detect a material discrepancy before the protocol finalizes an outcome. It does not establish an external truth independent of those inputs. #### Exception resolution The exception path starts with the same two values, but their disagreement exceeds 5%. The market pauses rather than continuing through the normal automated resolution path. Manual resolution can then use off-chain evidence. ``` Chainlink → Robinhood API → disagreement above 5% → market pause → manual resolution using off-chain evidence ``` The pause is a safety boundary, not a claim that the system can automatically settle every disagreement. The administrator’s judgment is part of the trust model in this exception case. ### What this trust model means AFTERBELL is not fully trustless. Order matching is off-chain. Secondary oracle verification is off-chain. Keeper infrastructure is off-chain. Exceptional resolution can involve an administrator. This is not presented as a failure of the architecture. It is the actual architectural model: on-chain contracts enforce settlement and outcome state, while off-chain systems handle operational work and provide external inputs that contract state alone cannot produce. The project’s stated philosophy is **“trust, but verify, twice.”** Technically, that means the architecture attempts to reduce single-source dependence by comparing Chainlink’s primary value with a Robinhood API reference. It explicitly retains an exception path when that comparison leaves the outcome unresolved. ### Current status and limits AFTERBELL is still being developed. The described design is whitepaper **v0.1, September 2026**, and should not be presented as proven production infrastructure. Smart contracts are not yet audited. An audit is planned before mainnet. Off-chain components should be evaluated alongside this unresolved contract-security status because each layer contributes to the complete operating system. Revenue projections are not proven. Organic liquidity is not guaranteed. AFTERBELL does not currently have a token; it is a product, not a token launch. {% hint style="warning" %} The hybrid design provides on-chain settlement, not a guarantee that every off-chain service, external price, or manual judgment is always correct or available. {% 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/trust-model/off-chain-components.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.