← Back to Blog
Roadmap

Roadmap Preview: GeraNexus v0 to v1 — Phases, Milestones, Open Questions

Published 21 April 2026 · 4 min read

Coming soon — join the waitlist

Quick answer. Three phases over eighteen months: v0.1 (consent tokens + receipts, published Q3 2026), v0.5 (escrow state machine + partial completion, early 2027), v1.0 (arbitration interop + cross-marketplace receipt composition, late 2027). Dates are targets, not promises. This post lists what is in each phase and the open questions that could delay them.

Phase v0.1 — consent and receipts (Q3 2026)

  • Consent token format finalised (JWS, narrow scope, short expiry).
  • Negotiation / booking / completion receipt formats finalised.
  • Ed25519 signature spec with JCS canonicalisation.
  • /.well-known/gera-nexus.json descriptor schema v1.
  • Reference implementation in TypeScript + Python, MIT-licensed.
  • First production integrations: GeraClinic, GeraHome.

Open question that could push this back: the consent-recovery flow for users who lose their device. If we cannot agree a spec with at least one identity provider, v0.1 ships without recovery and patches it in v0.2.

Phase v0.5 — escrow and partial completion (early 2027)

  • Escrow state machine normatively defined.
  • Refund ladder schema for partial completion (ratio, deadline, evidence requirements).
  • First escrow-capable payment rail integrations: GeraCash, Stripe.
  • Auto-release SLA configuration with per-marketplace override bounds.
  • Batch-receipt support (Merkle root over many receipts, one signature) for high-volume marketplaces.

Open questions that could push this back: cross-currency escrow (whose FX spread applies?), sub-£2 fast-settle mode (shorter dispute window, different arbitrator tier), and whether partial-completion ratios need a standard vocabulary or can stay marketplace-defined.

Phase v1.0 — arbitration and composition (late 2027)

  • Arbitration evidence-bundle format finalised (complete chain + consent token + policy document).
  • Third-party arbitrator onboarding spec, including conflict-of-interest disclosure.
  • Cross-marketplace receipt composition primitives (the insurance-claim, tax-return, reputation use cases).
  • Legal review and draft guidance with at least one regulator (FCA / ICO / equivalent).
  • v1.0 frozen spec with a two-year stability commitment and a formal versioning policy.

Open question that could push this back: cross-jurisdiction enforcement. A signed receipt is evidence, not enforcement. If we cannot agree a basic interop story with at least one regulator, v1.0 ships the receipt format but leaves enforcement to bilateral agreements.

What we will not do in v1

  • Discovery / search. That is the NANDA / public web layer.
  • Identity provisioning. That is Apple, Google, GovID, Gera Auth.
  • Payment-rail semantics. Stripe, GeraCash, Skyfire own those.
  • Reputation scoring. Downstream on the receipt chain.

Scope discipline is the main way specs ship on time. Every nice-to-have we deferred to v2 is a nice-to-have that did not block v1.

How to follow or contribute

The draft spec lives at geranexus.com/spec. GitHub issues and pull requests are the forum for debate; we do not gate debate behind mailing lists. If you work on an adjacent project (MCP, A2A, Agora, NANDA, LMOS, Skyfire, or equivalent), we want your eyes on the draft before v0.1 freeze. Email [email protected] or join the waitlist below.

Help shape the protocol.

Join the waitlist