xOne tracks feature gaps with a written audit in the xOneRS repository. The audit scores other clients, lists what they have and xOneRS lacks, and files one GitHub issue per gap. On 2026-11-15 the ledger on main holds 319 gaps, and all 319 have an issue.

This post explains the method, the exact counts and how we count them. A gap issue is a proposal. See the roadmap gates post for the correctness gates, which are a separate list.

How does the gap audit work?

The audit follows a five-phase brief. The first report lists the steps: product profile, competitor discovery and scoring, feature matrix, gap ledger, issue loop, and expansion until a pass adds nothing.

  • The audit ran in passes. Pass 7 (2026-11-14, onboarding and easy setup) is the latest on main.
  • Each pass reads competitor source at a pinned commit. The pins are in gap-ledger.json.
  • Presence of a feature is checked by file path and identifier. It is not a behavior test, and it does not prove that a client is correct.

Which clients does xOne compare against?

A repository joins the comparison when its score reaches 60 out of 100. competitors.json holds 649 candidates: 40 selected and 609 rejected.

The score has four parts:

  • feature overlap with the xOneRS product profile (50 points; XDC-specific capabilities weigh most)
  • activity (20 points: a commit in the last 6 months 20, 6 to 18 months 10, older 0)
  • adoption by stars (15 points)
  • code access (15 points: public OSI licence 15, unclear 5, private 0)
REFERENCE TABLEScroll to explore all columns →
Repository Score Overlap / activity / adoption / access
XinFinOrg/XDPoSChain 86 48 / 20 / 3 / 15
BuildOnViction/victionchain 83 42 / 20 / 6 / 15
ethereum/go-ethereum 80 30 / 20 / 15 / 15
paradigmxyz/reth 78 28 / 20 / 15 / 15

Ten rejected candidates score 60 or more. The reasons are in the file. Examples: a fork that adds nothing over a selected parent, a client at end of life, and our own sibling clients. Pass 7 added onboarding tools such as Eth Docker, Sedge and Foundry. The pass 7 report also lists 376 metadata-screened rejections.

How many gaps are in the ledger?

The ledger holds 319 gap rows, and 319 distinct issue numbers. Every row has status issued. We counted them with jq over gap-ledger.json at origin/main 3a6b9039c:

jq '.gaps|length' gap-ledger.json                       # 319 rows
jq '[.gaps[].issue_url]|unique|length' gap-ledger.json  # 319 issues
jq '[.candidates[]|select(.status=="selected")]|length' competitors.json  # 40
jq '[.candidates[]|select(.status=="rejected")]|length' competitors.json  # 609

By priority: P0 1, P1 78, P2 185, P3 55. The ledger has 17 area values. The largest are rpc (68), ops (44) and storage (43). No area is named security, and this post does not cover security work.

How does a gap get a priority?

The priority rule changed between passes, and the ledger keeps both. The first report sets P0 for a missing node type (archive mode), and P1 to P3 by how many selected competitors have the feature. The ledger on main states the pass 7 rule: P1 removes an immediate first-node obstacle, P2 enables operator and developer workflows, and P3 adds optional integrations. It also says that historical priorities are retained.

How does a gap become an issue?

Each gap gets one GitHub issue with the label gap-audit, a priority label and an area label. The body has 13 sections in a fixed order: What, Why, 80% of the way to, ASD-STE100, Diagrams, Images, Prompt, Workflow, Loop, Graph, Layout, Flow and Summary.

Issue #218 is an example. It is GAP-0047, a required-block peer check. It links the competitor source files, names the xOneRS code today, and lists five numbered steps and three acceptance criteria. GitHub shows it as closed.

A gap is one shippable unit. The first report's rule is: do not split gaps. A related need goes into the scope of an existing issue.

How does the audit avoid duplicate issues?

The audit checks before it files and again after it files.

  • Before filing, each gap is searched in open and closed issues. The first pass ran gh issue list --state all --search "<keywords> in:title" per gap. In pass 7, 99 of 100 title checks found no match (pass7-discovery-checks.json).
  • All 100 pass 7 bodies list related issues to reuse. Each says it does not reopen their scope.
  • 98 of the 100 pass 7 bodies start with a marker comment. The ledger keeps a body_sha256 for each pass 7 row.
  • After filing, a reconciliation closed two duplicates: #728 into #714, and #747 into #716.

What does SKIP mean in the audit?

A SKIP entry is a feature found in another client that the audit chose not to file. The reason is always written down.

The 37 pass 7 skipped candidates are in the current report. Most are owned by another issue or belong inside a larger gap. A few lack enough comparator evidence. The numbered SKIP-01 to SKIP-38 table is in the report as of the pass 6 commit. It counts 38 rows. Examples: SKIP-01 (Engine API, no XDC counterpart), SKIP-09 (runtime miner toggles, conflicts with signer safety) and SKIP-15 (already present in xOneRS).

How many gap issues are open?

On 2026-11-15, the label gap-audit has 383 issues: 223 open and 160 closed. The 319 ledger issues are 178 open and 141 closed. The other 64 labeled issues are newer than the ledger on main.

Closed does not always mean shipped. Two of the closed issues are the duplicates above. See what xOne runs today and the roadmap for status.

Frequently asked questions

How many feature gaps does xOneRS have?

The ledger on main has 319 gap rows, each with an issue. The gap-audit label has 383 issues on 2026-11-15, because 64 are newer than the ledger.

How many other clients does xOne compare against?

The audit selected 40 of 649 candidates. A candidate needs a score of 60 or more out of 100.

Does a closed gap issue mean the feature shipped?

Not always. A closed issue can be a duplicate that points to another issue.

Why are some features marked SKIP?

The audit found no XDC counterpart, a conflict with the xOne design, or an issue that already owns the work.

Sources