Civitas ID White Paper White paper version 3.0 · 30 October 2026
All pages

The trust registry on Stellar

From the white paper: section 4.2 describes a public list of recognized institutions, kept on a public network that no single company or government runs, and a registry check that already completes with all live chain access blocked and is designed to need no Civitas server in the path; this page describes the contract that holds that list and how the check works today.

What the contract is. The trust registry is a Soroban smart contract In build: it runs on the Stellar test network, where the instance production uses is wired to the platform and a second instance of the same code serves development. It records which institutions are recognized as credential issuers; the rest of the platform depends on it. It builds on OpenZeppelin's stellar-contracts library, pinned at its audited v0.7.2 release. There is no mainnet deployment and no mainnet date: mainnet follows the audit of the next release of that library.

What an entry holds. Each entry records one credential issuer: its institutional identifier (a did:webvh DID), its status (Active, Suspended or Revoked), a key list, its display names, a few reference fields, among them the Stellar account the institution controls and its Indy DID, and the time of its last change. Signing key: none yet. Credentials are signed via the service's Indy DID for now; the new key will be listed in its log. The registry records issuers only. Verifiers, the roles and credential types each institution is approved for, its attribute-access permissions and the conditions of its approval belong to the design, not to the deployed contract Research: not built; once built, a permitted-attributes check will let a verifier request only the attributes it is authorized to receive for a given credential type.

The entry lifecycle. Registration, key rotation, suspension, reactivation and revocation have all been exercised end to end against the contract production uses. Suspend and reactivate are synchronous operator-class actions, as are registrations and changes to an entry's keys and reference fields, the Stellar-account binding among them. Revocation is governance-class: it requires, along with contract upgrades and role rotation, two of three governance keys. One caveat: the quorum is a rehearsal of the mechanism, not yet a distribution of control, because the three keys have not been placed with three separate holders. The public-network runbook requires that key ceremony as a condition of deploying there.

Binding issuers to Stellar accounts. The contract implements the identity-verifier interface of SEP-57, the Stellar T-REX standard for regulated tokens, through the OpenZeppelin stellar-contracts library In build: exercised on the test network. Every live issuer is bound to the Stellar account its own signed DID log names, an account in its owner's wallet, and the platform's registrar binds no other account; an applicant proves control by signing a challenge inside a transaction that is never submitted. Any Stellar application can ask whether an account belongs to a recognized issuer, and gets a negative answer the moment that issuer is suspended.

Status drives visibility. Registry status decides which services appear in the wallet's catalog, and every public service listing computes its visibility the same way. Suspending an issuer removes its services from every public door with no separate publication step; reactivating it brings them back.

Verification without the chain. The registry check needs no live chain access. An exporter publishes the registry state as a signed snapshot (a JWS the reader checks against a pinned key), and the platform's verifier extension consults that snapshot during a verification. It runs on the interactions a service attaches it to, after the platform's own check of the credential's proof. On the rail in service the extension finds the issuer by the Indy DID in the credential's definition, which the registry entry records beside its did:webvh DID. A test ran the registry check in full, from loading the signed snapshot to a verdict, with every non-local network connection blocked. That covers the registry check only: on the credential rail in service, the platform's check of a presented credential's proof, and the wallet when it builds one, still read the Hyperledger Indy ledger. Direct chain reads run as free, near-instant simulated transactions; writes settle in about five seconds and never block the user: approving an issuer completes while its registration confirms. Publishing a schema under an institution's DID log writes nothing to Stellar, because the witness below is updated only when the log itself changes.

What it costs. Fees are measured on the test network, not estimated. Registering an issuer writes a persistent entry for about 0.153 XLM; a status change costs about 0.0009 XLM. Soroban archives idle state: entries carry a thirty-day time to live, and a weekly renewal pass keeps them alive for about 0.0021 XLM per entry.

The DID log and its witness. An institution's did:webvh identifier is backed by its DID log: a signed, hash-chained file of the institution's own keys that only the institution can extend and anyone can check. The log is kept off-chain, served from the institution's host, by default platform.civitasid.org. A deliberately powerless contract, the log witness, records on the ledger which version of that log the institution stands behind. It stores four things only: the DID, the Stellar account that made the attestation, the log's version identifier and the time; it holds no log, no log entry, no key and no schema. It has no administrator and no upgrade path, anyone may attest anything, and a reader counts an attestation only when the account that made it is both the account this registry binds to the DID and the account the institution's own signed log names. Only the institution can change the account its log names, and the platform's registrar binds no other account, so the platform cannot choose whose attestation counts In build: witness contract live on the test network and wired to the production platform; every service with an active registry entry runs on a self-certifying identifier with an attested log, and a new service is created together with its log. There is no separate DID registry: the DID log carries each institution's key history, and this registry records which institutions are recognized.

The contracts still to come. The trust layer has four contract types: this registry, the log witness above, and two that do not exist yet Research: no shipped code. Credential schemas are published off-chain under each institution's own identifier and ride its DID log rather than a contract of their own (schema publication). Still to come:

No holder identifiers, credential content or personal data are written to the chain by any deployed or planned contract.

Proof-gated disbursement Research: no code. The network that records the registry also moves money, so a cash transfer could in principle be released by a Soroban contract only on presentation of a valid proof derived from a credential the person already carries, with no personal data on chain. No production prover today emits proofs from credentials small enough to fit inside a Stellar transaction, and the proof circuit is not built. The pilot bar is a test-network demonstration that releases funds on a valid proof generated on a phone.

Status, 2026-10-01: the trust registry runs on the Stellar test network (the production instance wired to the platform), with registration, rotation, suspension, reactivation and quorum-guarded revocation exercised end to end; the log witness runs beside it on the test network, and every service with an active registry entry carries an attested log; nothing runs on the public Stellar network.