System architecture: four actors, three layers
From the white paper: sections 3.1 and 5.1 describe four kinds of actors and a system in which neither the administration layer nor the public ledger holds personal data; this page arranges that system in three layers, gives the mechanism behind the promise and says what runs where today.
Four actors. Every Civitas deployment, from the reference instance running today to a future national rollout, is described by the same four roles:
1. Issuers: organizations authorized to create and sign verifiable credentials, such as government agencies, NGOs and financial institutions.
2. Holders: the people themselves. Each holder keeps keys and credentials in a non-custodial wallet on their own phone.
3. Verifiers: organizations that request and check credential presentations, such as banks, employers and service providers.
4. The deployment administrator: the body that leads a national or regional deployment and decides who may issue or verify locally. Civitas exercises this role on the reference instance today.
Layer one: the administration layer, the Civitas Consoles Live. There are two. In the Ecosystem Console an ecosystem administrator admits institutions after business due diligence (KYB), manages third-party integrations and enforces the deployment's governance rules. It runs today as part of the production platform at platform.civitasid.org, which carries the Civitas ID name. The Ecosystem Console is designed never to hold personal data or per-person activity logs: it knows institutions, credential types and rules, not people. The Service Console is where an institution works: its owner creates the service and manages its keys in the Service Admin, and the institution defines its credentials and interactions in the Service Dashboard. The records an institution keeps about its own clients live there, in that institution's own tenant database, logically separated from every other tenant. Civitas hosts those tenants today, and the institution remains the controller of its own records; the platform is designed so that an institution can run its tenant on its own infrastructure, an option that is not built yet Research: the platform cannot yet be self-hosted, and self-hosting follows the open-source release planned for the first half of 2027. The goal-path rules described on the orchestration page Research: no shipped code are designed to be held in this layer once the engine is built; the reasoning itself is designed to run on the holder's device wherever possible.
Layer two: the trust layer on Stellar In build: every contract runs on the Stellar test network. A set of Soroban smart contracts records institution-level facts: which organizations are registered as issuers, their status (active, suspended or revoked), the Stellar account each controls, and, for each institution, which version of its own DID log it stands behind. The DID logs themselves, which carry each institution's key history, and the credential schemas each institution publishes as separate signed resources stay off-chain on the institution's host, by default platform.civitasid.org. Two contract types run today, both on the test network and wired to the production platform: the trust registry, and the log witness, which records those log versions and by design has no administrator and no upgrade path. The layer settles on four contract types (trust registry, log witness, revocation registry, issuance anchors); there is no separate DID registry and no schema contract, because the DID log carries the key history and schemas are published under each institution's own identifier. The revocation registry and the issuance anchors are not built; status lists for credentials held by people never go on chain, so the revocation registry is limited to lists for legal entities or anchors of list versions, and it is still to be designed. Nothing personal is ever written to the chain: no holder identifiers, no credential content, no record that a person was checked. A registry check at verification time reads a signed snapshot exported from the contract, not the chain itself, and it completes with all live blockchain access blocked. There is no mainnet deployment and no mainnet date; deployment to the Stellar public network waits on a security audit of the next release of the OpenZeppelin stellar-contracts library (the registry is pinned to the audited v0.7.2 today) and on a key ceremony, rehearsed in advance, that places the three governance keys with three separate holders.
Layer three: direct wallet-to-institution interactions Live. When a wallet talks to an issuer or a verifier, it does so directly and encrypted, under a pairwise identifier generated fresh for that one relationship and never published to any registry. There is no central database in the middle, and an issuer and a verifier cannot compare identifiers to discover they are dealing with the same person. Today this layer runs on AnonCreds credentials over a Hyperledger Indy substrate, using the platform's own encrypted exchange protocol; selective disclosure, zero-knowledge predicates and end-to-end revocation all work on this rail in production. That substrate is being replaced, in stages and with no switch-over day for users, by OID4VCI and OID4VP over the W3C Verifiable Credentials data model Research: no code yet; the first standards-compliant releases are targeted for early 2027. The standards page sets out the target stack in full.
What runs where today. The issuer and verifier platform, both Civitas Consoles and the encrypted interaction layer run in production on infrastructure Civitas operates. Holders use the launched iOS and Android wallet Civitas inherited with the platform it operates Live; a white-label Civitas build exists but has no app-store release yet. Every deployed contract runs on the Stellar test network only.
Status, 2026-10-01: the Civitas Consoles, the issuer and verifier platform and the encrypted wallet-to-institution layer run in production at platform.civitasid.org; the trust registry and log witness contracts run on the Stellar test network, wired to the production platform, while the DID logs and the schemas published under each institution's identifier stay off-chain with the institution; the revocation registry and issuance anchor contracts are not built.