> For the complete documentation index, see [llms.txt](https://agentdex.gitbook.io/agentdex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://agentdex.gitbook.io/agentdex-docs/under-the-hood/roadmap.md). # Roadmap This roadmap covers the path from today's centralised-operator architecture to a system where any third party can independently verify state from a public log. The steps below are staged because each opens new questions that the previous answers. The headline framing: **the validator is not a separate component. It is a transitional form of the new engine.** Phase 3 produces a clean reference implementation. Phases 4–5 publish and harden it. {% hint style="info" %} Anything pre-Phase 4 is labelled unverified. {% endhint %} ### Phase 0 — Where we are Centralised operator. Off-chain matching engine. On-chain custody in BridgeUpgradeable with a 7-day force-withdrawal escape hatch. Mark price built from multiple external sources with a bounded sensitivity property ([Mark price](/agentdex-docs/trading/mark-price.md)). No state commitments on L1. No public canonical log. Operator-authoritative balance updates. We don't claim this is the final architecture. It's the starting point. ### Phase 1 — Unverified Data (Sequencer + Internal Store) **Goal**: structure engine events into deterministic blocks and transactions. * Map engine outbox events into a block / transaction model. * Persist to an internal store with a stable schema. * Establish the block / transaction contract early — this is the wire format Phase 4 publishes. * Position honestly as **unverified data**: no third-party correctness check yet. **Risks**: locking in a sub-optimal structure, dropping events. **Mitigations**: explicit "internal / unverified" labelling on every surface, contract reviewed before commitment, log everything for later audit. ### Phase 2 — Explorer + Sequencer Infrastructure Parallel sub-phases, all building on Phase 1's data. #### 2a — Explorer A read-only UI: blocks, transactions, details. Backed by the internal store. Labelled "Preview / Unverified". #### 2b — Sequencer optimisation Throughput tuning, batching, observability. #### 2c — Internal SDK + documentation Libraries that work against the internal block / transaction store. Schema documentation. Logging and metrics. ### Phase 3 — Validator (Reference Implementation) Starts after Phase 1 closes. **Critically important**: this is the same codebase that will become the production engine in Phase 5. **Goal**: a clean, deterministic re-implementation of the trading logic that anyone can run. Stages: 1. **Implementation** — pure functions for orders, fills, margin, funding, liquidations. Slow, but correct. 2. **Unit tests** — full scenario coverage with known input/output pairs. 3. **Dry-run** — run against historical engine data; log every discrepancy. Extended window: weeks, not days. **Risks**: discrepancies between implementation and engine; rounding edge cases; ordering subtleties. **Mitigations**: long dry-run windows, detailed discrepancy logs, use the validator as a bug-discovery tool for the legacy engine. ### Phase 4 — Publishing & Disclosure Sequential after Phase 3, the components below are parallel. #### 4a — Rollup publication Publish block data to a blob layer or alternative. Mechanism selected based on chain fees and constraints. Still labelled **unverified** until the validator confirms. #### 4b — Validator + libraries open-sourced Reference implementation on GitHub. Helper libraries for rollup verification. Anyone can run a node against the published log. #### 4c — Explorer migrated to public data The explorer transitions from internal store to public published data. Consistency verified. Documentation for external consumers. **After Phase 4: independent verification is possible.** Hold a state snapshot + the public log, derive any later state yourself. ### Phase 5 — Production-Ready Core Transform the validator into the production engine. * Performance work, benchmarks, metrics. * Production-ready architecture (HA, capacity, monitoring). * **Backwards-compatibility adapter** — translates current engine events into new engine events. The new engine is a drop-in replacement; downstream services (market-data fan-out, indexers, etc.) keep working. * Canary deployment. Parallel operation with the legacy engine. Post-cutover postmortem. ### Cross-cutting work (not phased, ongoing) #### Message reliability Kafka and Redis can lose messages under failure. Mitigations: * Retry mechanisms with idempotency. * Pending-state tracking. * Reconciliation jobs. #### Failed-transaction visibility Today, failed operations have limited audit trails. Goal: every operation (success or fail) logs and appears in blocks. #### Determinism guarantees Stronger fixed-ordering of operations, nonce-based replay protection, sequence-number invariants. The whitepaper specifies the apply function as deterministic; the engine needs to match. ### What we don't promise * **Specific dates.** Each phase opens new questions. Public commitments will be made when each phase is ready to land, not before. * **A token.** [Airdrop scoring](/agentdex-docs/incentives/airdrop-scoring.md) is the *measurement* infrastructure. Whether and when a token launches is a separate decision. * **A specific consensus model after Phase 5.** Decentralised sequencer / proof-of-stake validation is beyond this roadmap. ### What we do promise * **Honest labelling.** Anything pre-Phase 4 is labelled unverified. We won't surface internal data as "verified" or "trustless" before it is. * **Open-source the validator** when it's ready, with permissive enough licensing for independent verification. * **Document trust assumptions explicitly.** [Risks](/agentdex-docs/reference/risks.md) is the live source of truth — when a trust assumption changes, the page changes. > Movement is not progress. Progress is defined by the system's ability to reproduce and validate state. --- # 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://agentdex.gitbook.io/agentdex-docs/under-the-hood/roadmap.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.