> 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/infrastructure-dependencies.md). # Infrastructure Dependencies Identifies third-party and operational dependencies the system relies on. ### Dependency map AFTERBELL relies on on-chain contracts and external operational services. Each dependency connects to a specific protocol function: user interaction, order matching, settlement, outcome representation, price verification, resolution, or operational execution. This is not a generic technology inventory. A dependency failure can affect a narrow function or a wider protocol path. A CLOB outage affects normal new-order matching. An unavailable settlement chain affects on-chain interactions. A missing price cross-check affects resolution verification. ``` User → frontend → signed order → CLOB → CTFExchange ↓ Robinhood Chain → outcome position ``` ### Robinhood Chain Robinhood Chain is the EVM execution environment for AFTERBELL’s smart contracts. Its chain ID is `4663`, and the source identifies an FCFS mempool. It hosts the contract layer for CLOB settlement, outcome state, resolution, redemption, and fee-related actions. ``` Robinhood Chain → EVM execution → smart contracts → settlement → outcome state ``` `CTFExchange`, `ConditionalTokens`, `MarketFactory`, `OracleResolver`, and `FeeCollector` depend on this environment for their on-chain functions. If the chain is unavailable, normal on-chain settlement and protocol interactions cannot proceed normally. This does not mean funds are automatically lost. The current source does not define consensus, validators, block time, sequencer architecture, or gas economics. These characteristics must not be inferred from EVM compatibility or the FCFS mempool. ### Chainlink Stock Token Feed Chainlink is the primary price-input dependency. The Chainlink Stock Token Feed provides the on-chain value read by `OracleResolver` through the documented `AggregatorV3Interface`. ``` Chainlink Stock Token Feed ↓ OracleResolver ↓ market resolution ``` If usable Chainlink data is unavailable, the normal resolution path is impaired. This is both a trust and availability dependency: resolution needs usable external price information, and the feed must be available when the market reaches its resolution condition. The whitepaper does not specify fallback feeds, feed-timing controls, node design, or additional price methodologies. The architecture should not be described as having those mechanisms. ### Robinhood REST API The Robinhood REST API is the secondary price cross-check. It provides an off-chain reference value that is compared with the primary Chainlink value before normal resolution proceeds. If the API is unavailable or unusable, the secondary verification path is impaired. It is not the primary oracle and is not an on-chain oracle. Its role is to provide the second reference for the documented 5% circuit-breaker comparison. The source does not define backup APIs, caching, retry behavior, rate limits, endpoints, authentication, or uptime guarantees. The API is therefore a named external dependency, not an unspecified redundancy layer. ### CLOB and WebSocket communication The CLOB is the off-chain matching dependency. It uses Node.js and WebSocket to receive signed orders and match compatible intent before activity reaches the on-chain settlement boundary. ``` Node.js + WebSocket ↓ off-chain CLOB ↓ signed-order matching ↓ CTFExchange settlement ``` The CLOB is required for the normal order-matching path. If it is unavailable, new off-chain order matching is impaired. This effect is scoped to matching. Already-settled on-chain positions are not automatically altered by a CLOB outage. WebSocket is part of the CLOB communication layer. If it is unavailable, real-time order flow is impaired. The source does not specify a database, queue, cache, load-balancing layer, or alternative transport architecture. ### Frontend The frontend is the normal user interface for market interaction. It uses React, viem, and wagmi to support market selection, Yes or No selection, order preparation, user signatures, and protocol interaction. ``` React + viem + wagmi ↓ frontend ↓ market interaction and order signing ``` If the frontend is unavailable, users lose the normal interface for these actions. The underlying smart contracts do not stop existing or functioning merely because the interface is unavailable. The frontend is an availability and interface dependency, not the settlement authority. The current source does not identify wallet providers, backend APIs, analytics, notification systems, or interface recovery mechanisms. ### Off-chain keeper The architecture identifies an off-chain keeper as an operational dependency. The stated fee allocation assigns 10% to the keeper bot, alongside 70% to the treasury and 20% to market maker subsidies. The current source does not fully specify every keeper responsibility. It therefore supports only the limited conclusion that some operational execution depends on this off-chain component functioning. It does not specify the keeper’s transaction workflow, schedule, automation behavior, or recovery behavior. If relevant keeper operations cannot run, those relevant off-chain operations may be impaired. The scope cannot be made more precise without additional source material. ### USDG settlement asset USDG is the ERC-20 settlement asset identified by the architecture. It is used in the trading and settlement flow and in the stated path that can mint new shares from USDG. Settlement therefore depends on USDG being usable within the protocol’s settlement architecture. This page does not introduce other stablecoins or alternative settlement assets. The source identifies USDG as the settlement asset. The contract layer can enforce the settlement state it receives through the protocol’s defined path. The current source does not specify broader asset-infrastructure behavior, so no additional guarantees are claimed. ### ConditionalTokens and outcome positions `ConditionalTokens` is the contract dependency for ERC-1155 Yes and No outcome positions. It supports split, merge, and redeem. This layer gives a prediction-market position an on-chain representation and enables the winning outcome to retain redemption value after resolution. The outcome-token mechanics depend on this contract layer. It should be evaluated together with the resolution inputs that determine which outcome wins. The source does not provide token IDs, condition IDs, storage design, or function-level implementation details. Smart contracts are not yet audited. An audit is planned before mainnet. The presence of an on-chain outcome-token layer does not establish audited security. ### Dependency map | Dependency | Layer | Function | If unavailable | | -------------------- | ---------------------------- | --------------------------------- | ---------------------------------------------------- | | Robinhood Chain | On-chain | Settlement and contract execution | On-chain operations cannot proceed normally | | Chainlink | Oracle | Primary price input | Normal resolution may be impaired | | Robinhood API | Off-chain oracle cross-check | Secondary verification | Cross-check is impaired | | CLOB | Off-chain | Order matching | New matching is impaired | | WebSocket | Off-chain | CLOB communication | Real-time order flow is impaired | | React / viem / wagmi | Frontend | User interaction | Normal interface is impaired | | Keeper | Off-chain | Operational execution | Relevant off-chain operations may be impaired | | USDG | On-chain asset | Settlement | Settlement depends on asset availability | | ConditionalTokens | On-chain | Outcome positions | Outcome-token mechanics depend on the contract layer | The table does not assign the same consequence to every dependency. It separates the affected function from a broader claim that the full protocol is unavailable. ### Trust versus availability A **trust dependency** means the protocol assumes an external source or actor provides usable or correct information. An **availability dependency** means infrastructure is available when its function is needed. Chainlink is both. It provides the primary resolution value, so the protocol trusts it as an input and needs it available for normal resolution. The Robinhood API is also both because it must provide usable data for the cross-check. The CLOB is primarily an operational availability and matching dependency. It must operate for normal new-order matching, but it does not settle positions on-chain. The frontend is an availability and interface dependency. It provides the normal interaction path, not settlement authority. An administrator is a trust dependency in the exception path. When Chainlink and the Robinhood API disagree by more than 5%, manual resolution uses off-chain evidence. That human judgment is part of the current resolution model. {% hint style="info" %} Availability asks whether a component can perform its function. Trust asks whether its information or decision can be relied on. A component can be one, both, or neither for a given protocol step. {% endhint %} ### System dependency graph The trading path depends on user-facing, operational, and on-chain components: ``` USER ↓ FRONTEND ↓ CLOB ↓ CTFExchange ↓ ROBINHOOD CHAIN ↓ OUTCOME POSITION ``` The frontend prepares interaction and signatures. The CLOB matches signed intent. `CTFExchange` provides the settlement boundary on Robinhood Chain. `ConditionalTokens` provides the ERC-1155 outcome position that can later be redeemed according to resolution. Resolution has a separate dependency graph: ``` CHAINLINK + ROBINHOOD API ↓ ORACLE RESOLVER ↓ NORMAL RESOLUTION OR CIRCUIT BREAKER ↓ MANUAL RESOLUTION ``` Chainlink supplies the primary value, and the Robinhood API supplies the secondary reference. When their disagreement is 5% or less, normal resolution proceeds. When it exceeds 5%, the market pauses and manual resolution uses off-chain evidence. The graph makes the human exception path explicit. ### Current status AFTERBELL remains under development. Smart contracts are not yet audited, and an audit is planned before mainnet. These dependencies should not be presented as fully production-proven infrastructure. This is whitepaper **v0.1, September 2026**. Revenue projections are not proven, organic liquidity is not guaranteed, and AFTERBELL does not currently have a token. It is a product, not a token launch. {% hint style="warning" %} The dependency map identifies architecture requirements, not guarantees of continuous operation, correct external data, or audited contract security. {% 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/infrastructure-dependencies.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.