# DBIS Hyperledger Identity Stack Decision **Last updated:** 2026-03-28 **Purpose:** Make the Aries / AnonCreds / Ursa decision path explicit for the DBIS RTGS program so these layers do not remain vague “maybe required” items. ## Current conclusion For the current DBIS RTGS program, the identity stack is **not yet frozen** beyond the placeholder Indy inventory. The repo and live environment do **not** currently prove: - a deployed Aries agent layer - a deployed AnonCreds issuance / verification flow - an explicit Ursa runtime dependency that operators must manage directly ## Recommended decision framework ### Option A — Minimal first production slice Use: - Chain 138 / Besu - FireFly primary - OMNL / Fineract - selected HYBX sidecars Do **not** require Aries / AnonCreds / Ursa in the first production slice. Use this option if: - the initial RTGS program does not require decentralized credential exchange - institution identity and compliance are satisfied through existing banking / regulatory processes - the team wants to avoid holding up settlement on unresolved identity-stack deployment work ### Option B — Identity-enhanced RTGS slice Include: - Aries agents - AnonCreds issuer / holder / verifier roles - Ursa-backed cryptographic path if required by the selected stack Use this option if: - the RTGS design requires verifiable credentials as a first-class runtime dependency - participant admission, authorization, or compliance checks depend on decentralized identity flows - DBIS wants credential verification to be part of the operational settlement path, not only a future capability ## Recommended default **Recommended default:** Option A for the first production slice. Reason: - Aries / AnonCreds / Ursa are not currently deployed or proven in this environment. - Requiring them now would expand the critical path materially. - The current gating problems are still in banking-rail orchestration and interoperability, not identity-agent runtime. ## What must be decided if Option B is chosen ### Aries - agent placement - wallet / DID model - mediation / routing model - protocol set used in production - operational ownership and observability ### AnonCreds - issuer role - holder role - verifier role - schema and credential-definition lifecycle - revocation model ### Ursa - whether it is an explicit operator-managed dependency - whether it is only an indirect library/runtime concern - what cryptographic controls or attestations it adds to the program ## Production-gate rule - If Option A is chosen: - Aries / AnonCreds / Ursa are marked `out of scope for first production slice` - they do not block first RTGS activation - If Option B is chosen: - none of them can stay as planning-only items - they must have: - deployment runbooks - runtime health checks - ownership - end-to-end validation ## Related artifacts - [DBIS_RTGS_E2E_REQUIREMENTS_MATRIX.md](DBIS_RTGS_E2E_REQUIREMENTS_MATRIX.md) - [dbis_chain_138_technical_master_plan.md](../../dbis_chain_138_technical_master_plan.md) - [TODO_TASK_LIST_MASTER.md](../00-meta/TODO_TASK_LIST_MASTER.md)