> 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/transparency/code-and-verification.md). # Code & Verification Explains how readers can assess code and verify protocol claims when available. ### Source of truth The whitepaper identifies [the AFTERBELL repository](https://github.com/tobiazlincoln/afterbell) as the project’s public source-code reference. Technically capable readers can use it to inspect the architecture against the documented claims. This page does not claim verified deployment, a completed audit, CI status, test coverage, formal verification, or reproducible builds. ### Contract architecture The source identifies five named contracts and their responsibility boundaries: | Contract | Responsibility boundary | | ------------------- | --------------------------------------------------------------- | | `ConditionalTokens` | ERC-1155 outcome-token representation; split, merge, and redeem | | `MarketFactory` | Market creation and fee collection | | `OracleResolver` | Chainlink read, Robinhood cross-check, and circuit breaker | | `CTFExchange` | CLOB settlement, EIP-712 signed orders, and batch execute | | `FeeCollector` | Fee collection and fee splitting | These boundaries provide a useful review map. The source does not define Solidity function names, contract addresses, deployment addresses, storage layouts, or access-control architecture. ### Reader-oriented verification flow The following is a conceptual review workflow. It is not formal verification. ``` PUBLIC SOURCE ↓ Review architecture ↓ Identify contract responsibilities ↓ Inspect oracle logic ↓ Inspect CLOB settlement boundary ↓ Inspect fee logic ↓ Compare implementation against whitepaper claims ``` This process helps a reader separate documented design from unsupported assumptions. For example, the review can ask whether the contract responsibility boundaries align with the whitepaper, without assuming unprovided implementation details. ### Oracle verification boundary The documented resolution model uses Chainlink as the primary Stock Token Feed and the Robinhood REST API as the secondary cross-check. `OracleResolver` applies the stated 5% disagreement condition. ``` Chainlink + Robinhood API ↓ compare ↓ ≤5% → normal resolution >5% → pause → manual resolution ``` At a conceptual level, a reader can inspect whether the architecture contains the named primary input, cross-check boundary, circuit-breaker condition, and exception path. The source does not provide exact contract or deployment addresses. ### Order-settlement boundary The CLOB is off-chain. `CTFExchange` is the on-chain settlement layer. EIP-712 signed orders and batch execution are part of the documented exchange architecture. ``` Signed order → off-chain CLOB matching → CTFExchange → on-chain settlement ``` The central verification question is therefore: what is matched off-chain, and what is actually settled on-chain? This separates the order-discovery and matching function from contract-enforced settlement. The source does not define the order schema, matching algorithm, or cancellation mechanics. ### Technology reference | Layer | Source-defined technology | | -------------- | ----------------------------------- | | Chain | Robinhood Chain `4663` | | Contracts | Solidity `0.8.26` | | Development | Hardhat | | EVM target | Cancun | | Outcome tokens | ERC-1155 / OpenZeppelin | | Exchange | CLOB / EIP-712 / batch execute | | Oracle | Chainlink / `AggregatorV3Interface` | | Cross-check | Robinhood REST API | | Backend / CLOB | Node.js / WebSocket | | Frontend | React / viem / wagmi | This is a source-defined stack reference. It does not claim a particular deployment topology, uptime level, or performance result. ### What cannot be verified yet The current source does not provide enough information to claim: * A completed independent audit. * Production deployment maturity. * Guaranteed uptime. * Verified trading volume or proven revenue. * Guaranteed liquidity. * Formal verification or comprehensive test coverage. * Permanent decentralization or full trustlessness. This is a required transparency boundary. It prevents the public repository and architecture description from being treated as evidence of claims the source does not make. ### Audit and development status Smart contracts are not yet audited. An audit is planned before mainnet. The project is still under development. The whitepaper is **v0.1, September 2026**. It will evolve as the project learns and changes. No version history is asserted here. ### Verification principle AFTERBELL should be evaluated from what can be inspected, not from what is merely promised. ``` DOCUMENTED → architecture and stated responsibilities IMPLEMENTED / SOURCE-REFERENCED → public repository reference PLANNED → audit before mainnet and roadmap capabilities UNPROVEN → production maturity, revenue, liquidity, and full trustlessness ``` The transparency model keeps these categories separate. A documented component should not be presented as production-proven without supporting evidence. {% hint style="info" %} The public repository is the project’s code reference. It is not, by itself, evidence of an audit, deployment, or security guarantee. {% 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/transparency/code-and-verification.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.