> 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/on-chain-components.md). # On-Chain Components Identifies the protocol functions executed and recorded on-chain. ### Settlement and enforcement layer AFTERBELL uses the blockchain as its settlement and protocol-enforcement layer. The entire product is not on-chain. Order discovery and matching, secondary oracle verification, operational execution, and exception evidence remain outside the chain. The on-chain layer records and enforces the protocol state that follows from those inputs. It settles USDG movements, represents outcome positions, applies resolution, enables redemption, and handles protocol fee flows. It does not independently discover orders, establish external prices, or prove that off-chain evidence is correct. ``` User ↓ Off-chain CLOB ↓ CTFExchange ↓ Robinhood Chain ↓ USDG + ERC-1155 outcome tokens ↓ Resolution ↓ Redemption ``` This separation is central to the trust model. A settled result can be enforced on-chain, while the facts used to reach that result may still depend on external systems. AFTERBELL describes this model as **“trust, but verify, twice.”** ### Robinhood Chain Robinhood Chain is the execution and settlement environment for AFTERBELL’s smart contracts. It has chain ID `4663`, is EVM-compatible, and has an FCFS mempool. These properties define the environment in which protocol transactions execute. Solidity contracts can operate in the EVM environment, and users or protocol operations can submit settlement, resolution, redemption, and fee-related transactions to the chain. The chain provides a shared execution layer for the protocol’s contract state. Once a transaction executes, the resulting contract state can enforce the associated USDG and ERC-1155 outcome-token effects. That is different from asserting that the chain validates every fact relevant to a market. The available architecture does not specify validator design, consensus, block time, gas model, RPC infrastructure, or sequencer design. Those details should remain undefined until they are documented. ### ConditionalTokens: outcome representation `ConditionalTokens` represents market outcomes as ERC-1155 tokens. A binary market has two positions: **Yes** and **No**. These positions give an on-chain form to a participant’s prediction-market exposure. Consider the market: > Will NVDA close above $150 on Friday? The market has a Yes outcome and a No outcome. A participant holding the Yes position has exposure to the proposition resolving true. A participant holding the No position has exposure to it resolving false. The contract’s named responsibilities are **split**, **merge**, and **redeem**: * **Split** creates the paired outcome representation from the supported collateral path. * **Merge** combines paired outcome positions back through the protocol’s outcome-token mechanics. * **Redeem** allows the winning outcome position to claim its redemption value after resolution. At resolution, the winning outcome retains redemption value. The losing outcome becomes worthless. This gives the protocol a concrete on-chain state transition: a position that was previously conditional becomes redeemable only if its represented outcome wins. The ERC-1155 representation removes the need to trust an off-chain ledger to record the final outcome position or redemption result. It does not remove the need to trust the market’s resolution inputs. The source does not define token IDs, condition IDs, storage layout, or individual Solidity function interfaces. ### MarketFactory: market-level protocol state `MarketFactory` creates markets and performs fee-related market setup and collection responsibilities. Market creation belongs on-chain because later protocol actions need a shared, protocol-defined market state to reference. Trading, resolution, and redemption only have a common meaning when they point to the same market. Establishing that reference on-chain makes the market part of the contract-governed protocol state rather than an unverified frontend label. This does not mean every market-design decision is independently validated by the chain. The contract can enforce the market state and applicable fee logic after configuration. It cannot determine whether the market configuration was economically appropriate or whether its external resolution condition will be easy to verify. The current source does not define market configuration fields or the access-control implementation. This page therefore treats `MarketFactory` as the market-creation and fee-related component described by the architecture. ### CTFExchange: settlement after matching `CTFExchange` is the on-chain boundary for central-limit order book settlement. It supports EIP-712 signed orders and batch execution. The critical division is: ``` CLOB: off-chain matching CTFExchange: on-chain settlement ``` The blockchain does not perform the entire order-matching process. A user signs structured order intent, the off-chain CLOB finds compatible participant intent, and the matched activity proceeds to `CTFExchange` for on-chain settlement. ``` Signed order → Off-chain match → CTFExchange → On-chain settlement ``` This boundary provides a durable settlement point for matched trading activity. Settlement uses USDG and results in the relevant ERC-1155 outcome position being created, transferred, or otherwise represented through the protocol’s stated paths. The architecture also states that a position can arise from a match with another participant or from minting new shares from USDG. EIP-712 signatures tie the user’s signed trading intent to the settlement flow. Batch execution allows multiple settlement actions to be executed together. Neither capability tells us how the CLOB chose a match. The source does not specify the matching algorithm, order schema, nonce structure, replay protection, priority, cancellation rules, or exact transaction sequence. {% hint style="info" %} On-chain settlement constrains the resulting protocol state. It does not turn off-chain matching into an on-chain matching engine. {% endhint %} ### OracleResolver: resolution with a circuit breaker `OracleResolver` reads Chainlink, cross-checks Robinhood data, applies the circuit-breaker condition, and resolves markets. The primary oracle is the Chainlink Stock Token Feed. The secondary reference is the Robinhood REST API. ``` Chainlink primary price + Robinhood API cross-check ↓ comparison ↓ normal resolution or market pause ``` If the Chainlink value and Robinhood API value disagree by more than 5%, the market pauses. Automated resolution does not continue through that disagreement. An administrator then resolves the market manually using off-chain evidence. The circuit breaker reduces dependence on a single source by requiring comparison before normal resolution proceeds. It does not cause `OracleResolver` to independently prove that either external value is truthful. Chainlink and the Robinhood API remain inputs from outside the contract’s native state. The pause path is also an explicit trust boundary. It prefers a halted market and manual review over an automatic result when the two sources materially disagree. Manual resolution is not described as a fully on-chain determination. ### FeeCollector: protocol fee flows `FeeCollector` collects and splits fees. Its role is limited to enforcing the protocol’s fee flow once the relevant fee-bearing activity occurs. The stated allocation is: | Recipient | Allocation | | ---------------------- | ---------: | | Treasury | 70% | | Market maker subsidies | 20% | | Keeper bot | 10% | On-chain collection and distribution can make the stated split part of the protocol’s enforced state. It does not establish that the economic configuration is optimal, that revenue projections will be realized, or that liquidity will be available. Organic liquidity is not guaranteed. ### On-chain trust boundary | Component | On-chain responsibility | Remaining dependency | | ----------------- | -------------------------------------------- | ------------------------------------------ | | ConditionalTokens | Outcome representation and redemption | Correct market resolution | | MarketFactory | Market creation and fee-related logic | Correct market configuration | | CTFExchange | CLOB settlement and batch execution | Off-chain matching | | OracleResolver | Resolution, cross-check, and circuit breaker | External oracle inputs and manual evidence | | FeeCollector | Fee collection and distribution | Correct economic configuration | The table separates enforcement from inputs. Contracts can enforce their programmed state transitions. They cannot independently validate the external data, operating services, or human judgment that may precede those transitions. ### What on-chain enforcement does not guarantee Blockchain enforcement is the ability to apply contract rules to a transaction and record the resulting state. External-input assumptions concern whether the information and operational actions supplied to those rules are correct and available. These are different assurances. For the NVDA market, the chain can enforce the resulting outcome-token redemption state after resolution. It cannot independently determine whether an external closing-price source was correct. Similarly, it can settle a submitted match, but it cannot establish that the CLOB was available to all users or selected a particular compatible order correctly. Putting these components on-chain does not automatically guarantee: * Correct Chainlink price data or correct Robinhood API data. * Correct CLOB matching or CLOB availability. * Correct manual-resolution evidence. * Audited smart-contract security. The final point is current and material. Smart contracts are not yet audited. An audit is planned before mainnet. Contract deployment or EVM execution should not be interpreted as a production-security guarantee before that work is complete. ### End-to-end example: NVDA above $150 For “Will NVDA close above $150 on Friday?”, the complete path crosses both trust domains: 1. **Off-chain:** A user selects **Yes** in the frontend and signs an order. 2. **Off-chain:** The CLOB matches that signed order with another participant, or the stated USDG-backed new-share path is used. 3. **On-chain:** `CTFExchange` handles settlement on Robinhood Chain. 4. **On-chain:** The user holds the Yes ERC-1155 outcome position through `ConditionalTokens`. 5. **Off-chain to on-chain resolution:** Friday’s condition reaches the resolution path. 6. **External input:** Chainlink supplies the primary price. 7. **External input:** The Robinhood REST API supplies the cross-check. 8. **On-chain decision path:** If the disagreement is 5% or less, normal resolution proceeds through `OracleResolver`. 9. **Exception path:** If disagreement exceeds 5%, the market pauses. 10. **Off-chain exception:** An administrator can use off-chain evidence for manual resolution. 11. **On-chain:** The winning outcome becomes redeemable. The losing outcome has no redemption value. ### Current status AFTERBELL is still being developed. This architecture is documented in whitepaper **v0.1, September 2026**. It is not proven production infrastructure. Revenue projections are not proven, and organic liquidity is not guaranteed. AFTERBELL does not currently have a token. It is a product, not a token launch. {% hint style="warning" %} Smart contracts are not yet audited. An audit is planned before mainnet. Readers should evaluate the on-chain layer together with its oracle, matching, and manual-resolution dependencies. {% 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/on-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.