> 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/what-we-have.md).

# What We Have

States the materials, designs, and capabilities currently available.

### Current-state principle

AFTERBELL is a product under development. The whitepaper describes its architecture and technical implementation, but does not claim that every component has reached production maturity.

This distinction matters. A defined architecture, available underlying infrastructure, and public source reference are not the same as audited contracts, proven revenue, guaranteed liquidity, or production validation.

{% hint style="info" %}
This page inventories what the whitepaper identifies. It does not convert roadmap items or architectural claims into evidence of production deployment.
{% endhint %}

### Chain foundation

AFTERBELL builds its smart-contract layer on Robinhood Chain. The source identifies Robinhood Chain as a Layer-2 with chain ID `4663`, EVM compatibility, and an FCFS mempool.

```
Robinhood Chain
  → EVM execution environment
  → AFTERBELL smart-contract layer
  → settlement and protocol state
```

These are the documented infrastructure foundations. The source does not specify validator details, block time, sequencer architecture, uptime, throughput, or RPC infrastructure.

### Market primitive

The defined core product architecture is a Yes/No prediction market with off-chain CLOB matching and on-chain settlement. Outcome positions use ERC-1155 tokens.

```
Select market
  → choose Yes / No
  → sign order
  → order matching
  → settlement
  → resolution
  → redemption
```

The CLOB handles order matching off-chain. The on-chain layer settles the protocol result and represents the outcome position. This is a technical design, not a claim about current trading volume or a fully mature market operation.

### On-chain contract design

| Contract            | Source-defined responsibility                                        |
| ------------------- | -------------------------------------------------------------------- |
| `ConditionalTokens` | ERC-1155 outcome tokens; split, merge, and redeem                    |
| `MarketFactory`     | Create markets and collect fees                                      |
| `OracleResolver`    | Read Chainlink, cross-check Robinhood, and apply the circuit breaker |
| `CTFExchange`       | CLOB settlement, EIP-712 signed orders, and batch execute            |
| `FeeCollector`      | Collect and split fees                                               |

The source defines these responsibilities. It does not provide contract addresses, deployment evidence, access-control design, upgradeability, storage layout, or function signatures.

### Oracle verification architecture

The primary price source is the Chainlink Stock Token Feed, read through `AggregatorV3Interface`. The secondary reference is the Robinhood REST API.

```
Chainlink Stock Token Feed
          +
Robinhood REST API cross-check
          ↓
     compare values
          ↓
≤5% → normal resolution
>5% → market pause → manual resolution
```

The 5% disagreement rule and manual-resolution path form a verification architecture. They are not a claim of perfect trustlessness. The source is explicit: **“This is not trustless.”**

### Technical stack

| Layer          | Technology                 |
| -------------- | -------------------------- |
| Chain          | Robinhood Chain `4663`     |
| Execution      | EVM                        |
| Outcome tokens | ERC-1155 / OpenZeppelin    |
| Settlement     | USDG ERC-20                |
| Oracle         | Chainlink Stock Token Feed |
| Cross-check    | Robinhood REST API         |
| Order book     | Node.js / WebSocket        |
| Frontend       | React / viem / wagmi       |
| Contracts      | Solidity `0.8.26`          |
| Development    | Hardhat / Cancun EVM       |

The table records the source-defined stack. It does not establish production uptime, performance, or deployment maturity.

### Public code reference

The whitepaper identifies [the AFTERBELL repository](https://github.com/tobiazlincoln/afterbell) as the public source-code reference.

The repository gives readers a place to inspect source material. Its existence does not establish a completed audit, passing test suite, deployed contracts, or production readiness. Those claims require separate evidence and are not made here.

### Team disclosure

AFTERBELL is built by the Tobiaz team. The source states that the team is not anonymous and is not a DAO.

This is a factual disclosure about the project’s stated builder identity and organizational form. The source does not provide biographies or credentials, so none are inferred.

### What this means

AFTERBELL has a defined technical architecture and a public code reference. It identifies an underlying chain, named protocol contracts, an oracle-verification design, a CLOB settlement boundary, and a specific technology stack.

Architecture existence does not equal production validation. The same source identifies unaudited contracts, unproven revenue, unguaranteed organic liquidity, and unresolved regulatory uncertainty.

The whitepaper is **v0.1, September 2026**. This separation between documented design and proven operation is part of the project’s transparency model.


---

# 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/what-we-have.md?ask=<question>&goal=<endgoal>
```

`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.
