# DBIS Hyperledger Identity Stack Decision

**Last updated:** 2026-03-29  
**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** as part of the canonical RTGS rail, but the repo and live environment now prove:

- a deployed Aries agent layer on primary `6500`
- a deployed AnonCreds-capable wallet path via ACA-Py `askar-anoncreds`

The repo and live environment still do **not** yet prove:

- a deployed AnonCreds issuance / verification flow in the RTGS business path
- 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 runtime is now deployed, but it is not yet integrated into the canonical RTGS flow.
- Requiring full credential issuance / verification now would still expand the critical path materially.
- The current gating problems are still in banking-rail orchestration and interoperability, not in simply hosting an 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_IDENTITY_COMPLETION_PACKAGE_RUNBOOK.md](DBIS_IDENTITY_COMPLETION_PACKAGE_RUNBOOK.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)