For product, business and anyone deciding whether to build on RiskRouter
Roadmap: what comes next, and what it waits on
No dates we cannot keep. Each step below names the thing it waits on, so you can tell for yourself whether it has happened. What has shipped, and when, is in the changelog.
Today
Built and running today
- The evidence log: salted fingerprints in a Merkle tree, signed heads, RFC 3161 time stamps and Bitcoin anchors, checked offline by two independent verifiers. Verify
- Proofs beyond one record: completeness chains, selective disclosure, spot checks, co-sealing and deadline proofs. Is this all of it?
- What to record, by law: regime packs, each field mapped to its article. Regime packs
- Ways in: the API, integration kits in Python, PHP, C# and Java, drop-in recorders, agent adapters, an MCP endpoint, and sealing a file in the browser. Integrate · Seal a file
- Running it yourself, with the same code, in your own account. Self-hosting
Next
Next, and what each step waits on
| Step | Waits on | Where it stands |
|---|---|---|
| Commercial terms, production keys for paying customers, a legal entity | The authorisation needed to carry on this activity in Belgium | Applied for. Until then the sandbox is free and no commercial terms are in force. |
| Live pilots with software vendors | That authorisation, a specialist legal opinion, and the vendor’s build passing the conformance suite | Technical evaluation can start now. The pilot letter |
| Independent witnesses co-signing the log | The public witness network listing the log, then witnesses configuring it | Requested. Witnesses shows the count from the files: none yet. |
| The recorders on PyPI and npm | Accounts on both registries, opened by the operator | Release workflow ready. Until then, copy them from the kit; the code is the same. |
| An Internet-Draft at the IETF on digest-only evidence logs | Submission by its author | Written and rendered with the IETF’s own tools. |
| Quote records in the Merkle log at volume | Real load on the original ledger reaching its ceiling for a contracted firm | Designed, not built: nothing is built for load that does not exist. |
| Outreach beyond two segments | The review of 4 November 2026, on counted results | Software vendors serving regulated finance, and AI platforms, until then. |
Not now
Decided against, for now
- Qualified time stamps
- Need a paid contract with a qualified authority. Taken up when a customer needs one; the tooling to request and check them is already in place. Why
- A qualified electronic ledger under eIDAS
- Needs a legal entity, an audited trust service and a paid conformity assessment renewed every two years. Revisited when the entity exists and a customer, a tender or a supervisor asks for one. Why
- Zero-knowledge proofs over many records
- Revisited when a supervisor, an auditor or a pilot firm names a rule it wants proven without seeing the records. Selective disclosure and completeness chains cover most of the need today. What exists
- Pages in French, Dutch and German
- Withdrawn on 5 October 2026: the site is in English for now. Bringing one back is a switch in the build, which then refuses any missing string.
Never
What RiskRouter will never build
- Claims handling, customer care, legal services or carrier management. We never touch your customer or own your carrier relationship: those are boundaries, and they are why you keep control.
- Lock-in: no SDK you are required to use, no format only we can read. The specification is open, and anyone may implement it.
- A sandbox behind a sales form, or a feature built only to fill a comparison table.
- A claim of a licence, a certification or a customer we do not have.
Your say
Tell us what is missing
If a step here would decide whether you build on RiskRouter, say so: a concrete need from a vendor goes to the top of the list, inside the rules above. Contact