The xOne roadmap for XDC clients is a list of gates, A to E, plus research track Q. A gate closes on recorded evidence for an exact build, not on opinion. This post explains each gate, its status on main, and the dates in the plan.
Short version: no gate is closed today. The reconciliation of 2026-11-14 says it plainly: no gate A to E or Q is done, because no gate has recorded evidence (block range plus commit) for all its rows. See the roadmap page for the site view.
What do gates A to E mean in the xOne roadmap?
Gates A to E are the qualification steps of the Rust client (xOneRS), from feasibility to public rollout. Each gate lists what it requires and what evidence closes it.
- Gate A feeds Gate B. Gate B feeds Gates C and D. Gates C and D feed Gate E.
- Evidence for a prerequisite item lets dependent engineering work start. It does not skip a later gate.
- Track Q research cannot replace a client gate.
The plan counts 280 rows in total. The reconciliation, made against main at dd5548f on 2026-11-14, gives each row a status: 122 done, 127 partial, 10 missing, 3 superseded and 18 policy rules. Every gate row is partial.
What does each gate require?
Gate A needs feasibility pins and decisions, Gate B needs replay at 0 mismatches, Gate C needs a live follower record, Gate D needs an isolated producer soak, and Gate E needs an approved public rollout. Every gate is partial today.
Gate A: feasibility
Requires: pins, the wide-balance and special-transaction matrix, the networking spike (S2), a decision on ADR-002, and a reviewed cross-store recovery design.
Closed by: a Gate A record with a commit.
Status: partial. ADR-002 and ADR-005 are not signed. The special-transaction matrix is deferred to #28. Some items need an owner decision or the oracle key.
Gate B: foundational correctness
Requires: sequential replay of V1, V2 and fork rules at 0 mismatches, a negative corpus, unwind and restart properties, crash and signer tests, and a simulator.
Closed by: recorded replay ranges at 0 mismatches, plus the test evidence.
Status: partial. The Apothem genesis replay reached block 432,000 with 0 mismatches. The V2 window covers 302 epoch switches. The plan asks for at least 1,000 epoch switches and full history. Open issues: #9, #10, #11, #12, #15, #44.
Gate C: sync and resources
Requires: anchored bootstrap, retention windows, snap interoperability, overload tests and a performance baseline.
Closed by: a live follower record on net2040 and Apothem. The reconciliation lists the missing records: a 7-day tip soak, a 5-restart record and a per-block parity run.
Status: partial. Owner issue: #45, open with no comments on 2026-11-14.
Gate D: isolated producer
Requires: a local adversarial devnet with kill, restart, partition, stale restore and signer handoff, and 0 conflicting signatures.
Closed by: a recorded devnet soak. The plan sets a 72 h soak with fault cases.
Status: partial. The rehearsal page says "not closed". A 2 h 08 min soak found 0 heights with two hashes. Stale restore and signer handoff are not recorded, and the 72 h soak has not run.
Gate E: public rollout
Requires: B, C and D first. Then an owner-approved testnet soak counted by eligible turns, independent verification, a rollback rehearsal, and a mainnet follower soak.
Status: partial. Apothem soak has not started. The mainnet follower and its 14-day soak (#48) have not run. Mainnet minting is refused in the code. Every public mint test needs owner approval.
What is track Q?
Track Q is research and compatible interface work for post-quantum readiness. It changes no consensus rule and no wire byte.
- Merged: a crypto inventory (56 on-chain rows, 14 planned rows), a threat model, a standards table and a cost-lab plan.
- Open: the inventory still owes a fourth discovery pass (#17). A contract-compliant lab run is not done (#18).
- No algorithm is active.
AlgorithmId::Secp256k1Keccak = 1is the only valid value. - A PQ change needs a written specification, an independent audit, vectors in at least two independent clients, a multi-client devnet run and a governance decision.
The reconciliation marks this as correct: no activation.
When do the gates close in the plan?
The plan gives a close date for each gate, as the latest end date of its items. The dates are plan dates, not promises.
| Gate | Plan date |
|---|---|
| A | 2026-11-19 |
| B | 2026-11-27 |
| C | 2026-12-06 |
| D | 2026-12-06 |
| E | 2027-01-07 |
| Q | 2026-11-24 |
Read them with the plan's own caveats:
- Each estimate is a rough figure in calendar days, multiplied by 1.5.
- The chart starts on 2026-11-16. No item runs before its dependencies.
- The plan says: "Dates are plan dates, not promises."
- Gate E depends on owner approval of each public mint test and on the 14-day soak. Its date moves with those decisions.
- The plan keeps a weekly table of estimate against actual. It changes the 1.5 factor when three weeks in a row differ. The first estimate line is dated 2026-11-16.
No date here is a promise. A gate closes when its evidence exists.
How does the xOne roadmap compare with other client roadmaps?
Other client teams publish direction posts with themes. The xOne plan publishes gates with close conditions and plan dates. The summaries below come from the xone.sh roadmap review of 14 November 2026. A date in a competitor post is that team's context, not a verified delivery.
| Client | Published direction, as summarised | Source and date |
|---|---|---|
| reth | AOT/JIT execution and block-access-list-driven parallelism; state-root pipelining, tiered storage and configurable retention. | Releasing reth 2.0, 8 April 2026 |
| Erigon | Parallel execution, compact historical data, separable RPC and txpool services, account abstraction, L2 use and a longer-term Erigon NeXT architecture. | Erigon 2025 roadmap, 28 March 2025 |
| Nethermind | Witness capture, stateless replay, a minimal execution binary and proof generation. | Road to ZK implementation, updated April 2026 |
| Besu | Worst-case execution benchmarks, further sync work, Bonsai archive performance and a more efficient UInt256 stack. | Besu 2025 accomplishments and 2026 roadmap, 19 November 2025 |
| ethrex | Execution hot paths, PGO/BOLT, database I/O, caching, RPC allocations and root computation. It records discarded experiments. Priority is urgency, not effort or a date. | ethrex ROADMAP.md, reviewed 14 November 2026 |
| XDPoSChain | Reward automation, dynamic gas-limit testing, EIP-7702 testing, epoch-penalty testing, audit work and release documentation. | 2026 summer release milestone, reviewed 14 November 2026 |
| xOne | Gates A to E and track Q. A gate closes on recorded evidence for an exact build. Plan dates run from Gate A on 2026-11-19 to Gate E on 2027-01-07, and the plan says: "Dates are plan dates, not promises." | Execution plan, reconciliation |
No competitor theme, gas limit or schedule applies to XDC by default.
Do the other xOne clients follow the same gates?
Yes. The other xOne clients use the same gate DAG with the same evidence rules and the same mint protocol. See which xOne client to run for the clients, and xOneRS for the Rust client.
xOneTS (TypeScript), xOnePy (Python) and xOneC (C++) each carry a docs/process/gates.md. These three repositories are private. Each file describes the Rust gate DAG "as [the client] uses it": gates B, C, D and E, with the same evidence rules and the same mint protocol. Each file maps the gates to that client's own work items. The xOneTS plan, dated 2026-11-12, is a proposal that mirrors the Rust plan.
The xOnePy and xOneC files also list source gates that every pull request runs. These are checks on the code, not gate closures. A gate closes only on recorded evidence.
Where can I follow the work?
Read the reconciliation file, the plan and the post-quantum documents in the Rust repository.
- The site roadmap page shows the gates next to competitor planning references.
- The reconciliation file records each row, its evidence and its owner issue.
- The post-quantum documents are in
docs/pqin the Rust repository.
Frequently asked questions
Is any xOne gate closed?
No. The reconciliation of 2026-11-14 says no gate A to E or Q is done, because no gate has recorded evidence (block range plus commit) for all its rows. Every gate row is partial.
What closes a gate in the xOne roadmap?
Recorded evidence for an exact build closes a gate. For Gate B, that is recorded replay ranges at 0 mismatches plus the test evidence. For Gate D, it is a recorded devnet soak, and the plan sets a 72 h soak with fault cases.
When does Gate E close?
The plan date for Gate E is 2027-01-07. It is a plan date, not a promise. Gate E depends on owner approval of each public mint test and on the 14-day soak, so its date moves with those decisions.
Does track Q change XDC consensus?
No. Track Q is research and compatible interface work. It changes no consensus rule and no wire byte. No algorithm is active, and AlgorithmId::Secp256k1Keccak = 1 is the only valid value.
Do xOneTS, xOnePy and xOneC use the same gates?
Yes. Each carries a docs/process/gates.md that describes the Rust gate DAG as that client uses it, with gates B, C, D and E, the same evidence rules and the same mint protocol.
Sources
- Reconciliation, 2026-11-14 (counts, GATE-A to GATE-E, GATE-Q rows)
- Execution plan, 2026-11-11 (estimates, schedule, final qualification)
- Post-quantum readiness
- xOneTS gates and plan (private repository)
- xOnePy gates (private repository)
- xOneC gates (private repository)
This article describes the source and evidence at its review date. Check the linked repository for current implementation and qualification status.
Explore the engineering evidenceEdit this page on GitHub opens the Markdown source (content/blog/xone-roadmap-gates/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.