Delivery roadmap and dates

From the white paper: the paper describes what is available today and what Civitas is working toward in 2027, and section 1 points here for the roadmap; this page gives the delivered baseline and six delivery motions, and says which dates are targets agreed with funders and which are internal.

How to read the dates. One rule holds throughout: dates are targets agreed with funders, not promises. Where a date is an internal target only, this page says so. Two dates do not exist and are not implied anywhere here: a mainnet date for the Stellar contracts, and a start date for any field pilot.

The delivered baseline. Everything in this list runs on the production platform at platform.civitasid.org, with its trust layer on the Stellar test network, which is why these pages label each capability In build rather than Live.

• The trust registry runs as a Soroban contract on the test network, wired to the production platform, and a wallet verification carries its verdict on every interaction a service attaches the registry check to.
• Every issuer with a live registry entry is bound through the SEP-57 interface to the Stellar account its own DID log names.
• Registry status drives the wallet catalog and every public service listing: a suspended or revoked issuer's services drop out at once.
• Governance-class registry actions need a two-of-three quorum: a rehearsal of the mechanism, not yet a distribution of control, until a key ceremony places the three keys with three separate holders.
• Every registry write made through the platform's registrar bridge records who asked for it. Stored data is extended before it expires: every issuer entry that is not revoked by a weekly renewal pass, the rest of both contracts' data in advance.
• Every service with an active registry entry runs on its own DID log, attested in the log witness, an on-chain contract that records which log version each institution stands behind, and every new service is created together with its log.
• Schemas publish from the Service Dashboard as attested resources under each institution's own identifier, off-chain.
• Keys are split by what they may do: owner keys change an institution's log, and a publishing key, the kind the Service Dashboard makes, only publishes schemas.
• Owners review, repair and sign their lists of published schemas, and nothing is signed that the owner has not seen.

Motion one: finish the trust layer. The proof is delivered: integration documentation from which the trust layer has been installed from scratch on the test network, a threat model kept as a living record in which every threat is mitigated or accepted, and a first round of user acceptance testing, run on the production platform on 25 September 2026 with participants in Kenya recruited by a partner organisation. Mainnet then waits on two preconditions and carries no date: the security audit of the next release of the OpenZeppelin stellar-contracts library the registry builds on (the deployed registry pins its audited v0.7.2 release), and a key ceremony, rehearsed in advance, that places the three governance keys with three separate holders and sets how a lost key is replaced.

Motion two: the standards migration, staged. The rail in production today is AnonCreds over Hyperledger Indy Live, with selective disclosure, zero-knowledge predicates and end-to-end revocation working. The migration replaces it in three stages. Stage one, the public trust layer on Stellar, is the baseline above. Stage two replaces formats and protocols: OID4VCI and OID4VP with DCQL queries for exchange, W3C Verifiable Credentials 2.0 as the credential envelope, SD-JWT for selective disclosure, an unlinkable option for credential types shown to many verifiers (a BBS-family signature or a zero-knowledge layer over SD-JWT, neither chosen yet), status-list revocation, and the wallet re-based onto those rails. None of this has shipped code Research: first releases targeted early 2027, a target agreed with funders. Institutional did:webvh identifiers, also part of the target profile, are already in place: every service with an active registry entry runs on its own DID log, attested in the log witness on the Stellar test network In build. Stage three packages verification as a standalone library, command-line tool and hosted endpoint. The old rail is switched off only after both production capabilities, threshold proofs and revocation, are reproduced on the new rail and a pilot shows issuance, offline holding, QR presentation, verification and a revocation check on it, on the low-cost devices the target populations carry. The wallet redesign for low-literacy users runs alongside this motion Research: specified, no screens built.

Motion three: open the stack. Full release of the code under the recommended Mozilla Public License 2.0 (a recommendation, not yet applied; see the licensing page) and of governance content under Creative Commons Attribution 4.0, with implementing-partner documentation, API references and runbooks, targeted for the first half of 2027. No license has yet been applied to any repository.

Motion four: publish the governance framework. Institution onboarding rules, trust-registry governance, schema standards, and safeguarding adapted to Kenya and Colombia, targeted for 2027.

Motion five: the guided path and the assistant. The goal-path engine Research comes first, then the wallet assistant Research, pilot-ready in the 2027 to early 2028 window agreed with funders. No assistant or agent code exists in any layer today; the live seed of this motion is the wallet's navigation from a missing credential to the service that issues it.

Motion six: field pilots. Pilots in Colombia and Kenya follow partner agreements, and this paper dates none. One gating check already runs, country by country: whether document-based identity verification In build: provider account in sandbox reads the documents displaced people actually hold. In Kenya the current integration does not yet cover the refugee identity card, and a second provider for Kenya is being integrated In build: not yet in production.

Status, 2026-10-01: the whole delivered baseline sits on the Stellar test network behind the production platform; the nearest funder-agreed target is the first standards-compliant releases of early 2027, and mainnet has no date.