Risk register

From the white paper: section 7 names four risks; this page names what could break the labels and the dates, and what bounds each risk.

Seven risks matter enough to state. The first four are structural: they come with the territory. The last three arise from the current stage of delivery, and each is stated with the position it is in today.

Credential acceptance and regulatory recognition. A credential is worth what institutions will accept it for. Whether a verifiable credential can satisfy a KYC or AML framework differs by country, and cross-sector acceptance (a temporary protection credential feeding a bank's onboarding check) often requires policy change rather than code. The mitigation is ecosystem engagement: acceptance is negotiated case by case with partners and regulators in the pilot geographies. No credential issued through Civitas has yet been accepted for a regulated KYC decision in a live deployment.

Privacy, surveillance and data misuse. The people this platform serves have well-founded reasons to distrust systems that collect data about them, and misuse would cause real harm. The principal mitigation is architectural and runs today Live: no credential content is stored centrally, identifiers are pairwise per relationship, and consent is action-based and given on the device; the platform does keep, for each wallet, a device identity used to detect a cloned wallet. No architecture eliminates governance risk entirely; the governance and safeguarding framework carries the remainder.

Standards fragmentation and lock-in. The verifiable-credentials ecosystem is converging but has not converged. Civitas mitigates by adopting the exchange protocols the major ecosystems, EU Digital Identity included, are converging on (OID4VCI and OID4VP), and a DID method with a verifiable key history (did:webvh), rather than proprietary alternatives, and by passing every read and write of the Stellar trust layer through one ledger adapter so that backend can be swapped. The planned credential formats, SD-JWT and an unlinkable option for credentials shown to many verifiers (BBS+ or a zero-knowledge layer over SD-JWT, neither chosen), are targets, not code Research: no shipped implementation. A sharp standards bifurcation could still force architectural adjustment.

Geopolitical and institutional stability. A change in government policy, a funding cliff at a partner, or a shift in multilateral priorities could change country-level plans. The design answer is that no single relationship is structurally load-bearing: every component is designed to be independently deployable, and the open-source release planned for the first half of 2027 will let an implementing partner operate the stack without Civitas. Until that release ships, the open license is a commitment; none is applied to a repository yet. In the near term the risk is managed through institutional relationships.

Single identity-verification vendor. Wallet onboarding for a person with no digital record starts with a document check by a commercial document-verification provider In build: integrated in the wallet, sandbox only. Two limits are material: no live verification has yet been performed, and the current integration does not yet cover the refugee identity card issued in Kenya; a second provider for Kenya is being integrated In build: not yet in production, and coverage in other countries is unconfirmed. The mitigation is structural rather than contractual: verification sits behind a single integration boundary and is a replaceable, per-country component, and it is one route into the ecosystem, not the only one, since an accredited issuer can issue from its own records. Before a country program relies on this route, a pilot must show the chosen provider reads the target population's documents at an acceptable success rate on low-cost devices.

Governance keys not yet distributed. Authority over the trust registry is exercised with cryptographic keys. Governance-class registry actions, revocation among them, require a two-of-three multi-signature quorum, exercised end to end In build: Stellar test network. The three keys have not yet been placed with three separate holders, so today the quorum is a rehearsed procedure, not a separation of powers. The exposure is bounded because the registry runs on the test network and every write is an auditable on-chain transaction; a key ceremony, rehearsed in advance, that places the three governance keys with three separate holders and sets how a lost key is replaced is a precondition of mainnet deployment, which itself has no date because it also waits on the audit of the next release of the OpenZeppelin stellar-contracts library the registry is built on (pinned today at the audited v0.7.2).

Migration off the current rail. Credentials today run as AnonCreds over Hyperledger Indy Live, with zero-knowledge predicates, selective disclosure and end-to-end revocation working in production. Both hard capabilities must be reproduced on the new rail before the old one can retire: status-list revocation on the new formats is specified with no code Research, and the next-generation predicate work has two candidate approaches, neither measured on the low-cost devices the target populations use Research. The migration is staged, so credential types move one at a time with no cut-over day imposed on holders; a pilot must show issuance, offline holding, QR presentation, verification and a revocation check on the new rail before the current one is switched off.

Status, 2026-10-01: the four structural risks are standing positions managed through partners and architecture; of the delivery risks, the verification provider runs sandbox only, the governance quorum runs on the Stellar test network with its keys not yet placed with separate holders, and the first standards-compliant credential releases are planned for early 2027.