proxmox/docs/02-architecture/DBIS_ECOSYSTEM_TECHNICAL_MASTER_PLAN.md

DBIS Ecosystem Technical Master Plan

Last Updated: 2026-04-24
Audience: Engineering, operators, architecture owners, and program owners
Mode: Execution-oriented umbrella root for the live and planned DBIS ecosystem

1. Purpose And Decision Rules

This document is the canonical ecosystem root for the DBIS stack across the main repo and materially relevant submodules. It does not replace the narrower plans. It sits above them, normalizes status and terminology, and defines which source wins when specialized documents disagree.

Canonical source priority

When two documents disagree, use this order:

1. machine-readable config and trackers
2. implementation and validation scripts
3. specialized canonical docs and runbooks
4. older narrative plans

Status vocabulary

• live: repo, operator runtime, and current evidence all support production use
• partially live: some production components are live, but important slices are still missing or constrained
• repo-implemented: implemented in repo or submodule, but not yet fully promoted operator-live
• operator-only: present or recoverable in runtime, but not fully codified in repo truth yet
• planned: intentionally designed, but not yet implemented enough to rely on
• blocked external: progress depends on vendor, network, institutional, or third-party inputs
• retired: no longer part of the target system except as history or compatibility residue

Subordinate source plans

This umbrella root governs these narrower artifacts:

• dbis_chain_138_technical_master_plan.md: Chain 138 infrastructure and runtime sub-plan
• DBIS_RTGS_MASTER_PLAN_IMPLEMENTATION_TRACKER.md: institutional settlement execution tracker
• URA_MANIFEST_AUTOMATION_IMPLEMENTATION_TRACKER.md: policy and activation control-plane tracker

2. Current Live Ecosystem Baseline

Baseline status map

Subsystem	Current state	Status	Primary workstream	Canonical references
Besu / Chain 138 topology	5 validators, canonical sentries and RPC tiers reconciled, duplicate legacy RPC CTs retired, cluster-wide inventory audit added	live	W1	BESU_NODE_CONFIGURATION_MAP_20260424.md, check-cluster-besu-inventory.sh
DODO PMM / routing / public bridge surface	Chain 138 PMM core live; public routing surface codified; stablecoin and top-asset coverage documented, but route confidence is not yet first-class in quote APIs	partially live	W2	DEPLOYER_TO_PUBLIC_STABLECOIN_ROUTES.md, public-routing-coverage-matrix.json
Explorer / RPC / public ingress	Explorer, RPC, and public ingress surfaces exist and are operator-usable; current runtime is healthy	live	W1	RPC_ENDPOINTS_MASTER.md, verify-end-to-end-routing.sh
Phoenix deploy API / deployment control	Phoenix deploy API, deploy targets, and repo validation are codified; broader control-plane integration is still being expanded	partially live	W3	phoenix-deploy-api/server.js, deploy-targets.json
URA manifest / policy profile flow	Manifest, policy profiles, registry hooks, merge/validate/smoke scripts, and ops-readiness surfaces exist in repo	repo-implemented	W4	README.md, manifest.json, policy-profiles.json
RTGS / DBIS Rail / OMNL / sidecars	execution trackers, catalogs, and first-slice architecture are substantial; some sidecar and institutional paths remain gated by operator work and external parties	partially live	W5	DBIS_RTGS_MASTER_PLAN_IMPLEMENTATION_TRACKER.md, DBIS_RAIL_SETTLEMENT_EVENT_SOURCES.md
Hyperledger / identity / workflow stack	runtime status, identity decisions, and interoperability docs exist, but this is not yet a fully operator-live sovereign stack	planned	W7	DBIS_HYPERLEDGER_RUNTIME_STATUS.md, DBIS_HYPERLEDGER_IDENTITY_STACK_DECISION.md
Proxmox / NPMplus / operator automation	Proxmox topology, audits, NPMplus/Gitea TLS checks, operator wrappers, and evidence scripts are live and actively used	live	W8	PROXMOX_VE_OPERATIONAL_DEPLOYMENT_TEMPLATE.md, proxmox-operational-template.json, monitor-blockchain-health.sh

Baseline summary by subsystem

Besu / Chain 138 topology and role model

The canonical Besu fleet now spans all current Proxmox cluster hosts, with reconciled validators, sentries, RPC classes, and an explicit cluster inventory audit. The current baseline supports healthy block production, empty txpool checks, and host-placement reconciliation as operator truth.

DODO PMM / routing / public-network bridge surface

Chain 138 has live PMM infrastructure, stablecoin and compliant asset inventory, and a documented path from Chain 138 assets through WETH to supported public EVM surfaces. Public coverage is now documented, but route selection still lacks a native confidence and policy gate.

Explorer / RPC / public ingress

Public ingress, explorer surfaces, and RPC endpoint classes are live enough for current operator use. The topology is healthier and more explicit than before, but still benefits from further control-plane normalization.

Phoenix deploy API / deployment control surfaces

Phoenix has codified deploy targets, API routes, and validation gates. It is already a real deployment surface, but not yet the full policy-aware orchestration layer for route, institution, and activation decisions.

URA manifest and policy-profile flow

URA now has repo-native manifests, policy profiles, validation scripts, smoke tests, and a growing ops-readiness surface. The on-chain PolicyProfileRegistry in smom-dbis-138 gives this stack a credible path from docs/config into enforceable control-plane state.

RTGS / DBIS Rail / OMNL / settlement sidecar baseline

The institutional settlement stack has real architecture, trackers, and execution references, including sidecar and OMNL evidence structures. It is substantial and strategically important, but still mixed between repo-implemented, operator-only, and blocked-external slices.

Hyperledger / identity / workflow runtime status

Identity and workflow architecture is clearly represented, but it remains more of a governed design direction than a fully promoted live runtime slice today.

Proxmox / NPMplus / operator automation baseline

The operator layer is one of the strongest current pieces: Proxmox inventory, Besu fleet audits, cert checks, validation wrappers, and deployment scripts now create a meaningful operational backbone for the ecosystem.

3. Target-State Architecture

Sovereign compute and network topology

The target state is a multi-host sovereign Proxmox fabric with explicit node-class ownership, reconciled cluster inventory, deterministic Besu topology, and auditable ingress/control paths. Live runtime and checked-in template truth should converge, with cluster-resource discovery replacing host-blind assumptions.

Settlement and routing plane

The routing plane should unify Chain 138 PMM liquidity, public EVM bridge exits, ALL Mainnet venue surface, and destination-chain liquidity into one evidence-backed routing layer. The target is not merely “can bridge” or “can swap,” but “can produce a policy-permitted route with current evidence and measurable confidence.”

Policy and activation control plane

The canonical next-generation control plane is:

URA manifest + policy profiles + PolicyProfileRegistry + route confidence

This pattern should govern what is activated, where it is allowed, how it is quoted, and what evidence is required. It should integrate Phoenix deploy/control APIs, jurisdiction matrices, DBIS Rail gating, and on-chain publication where needed.

Institutional RTGS / DBIS Rail / custody plane

The target institutional layer is a composable RTGS and DBIS Rail stack with explicit custody models, sidecar boundaries, settlement event sources, and compliance traceability. It should be capable of supporting first-slice operator reality while leaving room for more sovereign custody and settlement controls over time.

Deployment and orchestration plane

Phoenix, operator wrappers, deploy manifests, and machine-readable trackers should converge into a single orchestration layer that knows what can be deployed, under what policy profile, and with what acceptance evidence.

Identity / workflow / interoperability plane

Hyperledger, workflow, and identity systems should evolve from strategic design documents into explicitly gated environment slices with clear runtime ownership, integration boundaries, and promotion criteria.

Observability / evidence / audit plane

The ecosystem should continuously produce validation outputs, cluster inventory, route coverage, and operator readiness evidence. The goal is for production gates to consume machine-readable proof, not just narrative claims.

4. Execution Workstreams

W1. Besu / Chain 138 infrastructure and RPC topology

Field	Value
Objective	Keep Chain 138 and the Besu fleet healthy, reconciled, and template-aligned across all cluster hosts
In-scope components	validators, sentries, RPC tiers, allowlists, generated node configs, Proxmox/Besu inventory and audits
Dependencies	Proxmox inventory truth, host placement, generated Besu configs, operator runbooks
Production gate	healthy block production, empty txpool or explained pending state, no canonical Besu inventory gaps
Evidence / output artifact	check-cluster-besu-inventory.sh, monitor-blockchain-health.sh
Owner class	mixed

W2. Liquidity, PMM, bridge, and public routing coverage

Field	Value
Objective	Turn current PMM and bridge capability into explicit, evidence-backed public routing coverage
In-scope components	DODO PMM, wrapped/public inventory, bridge receiver mapping, public routing matrix, destination DEX coverage
Dependencies	Chain 138 liquidity, bridge configs, destination-chain liquidity discovery, routing docs
Production gate	route coverage matrix current, bridge destination support explicit, stablecoin and top-asset tiers documented
Evidence / output artifact	public-routing-coverage-matrix.json, LIVE_ECOSYSTEM_FINANCIAL_INVENTORY_AND_ROUTING_GAPS_20260424.md
Owner class	mixed

W3. Phoenix deploy/control-plane integration

Field	Value
Objective	Make Phoenix the reliable orchestration and exposure surface for deployable ecosystem services
In-scope components	phoenix-deploy-api, deploy targets, deploy validation, public-sector and URA API surfaces
Dependencies	deploy-target accuracy, validation scripts, environment readiness, Gitea/Cloudflare/NPMplus stability
Production gate	deploy targets validate, Phoenix routes expose canonical manifests and control-plane surfaces, operator handoff remains current
Evidence / output artifact	validate-config-files.sh, phoenix-deploy-api/openapi.yaml
Owner class	mixed

W4. URA manifest, policy profiles, registry, and route confidence

Field	Value
Objective	Promote URA and policy profiles into the canonical activation and routing control plane
In-scope components	URA manifest, profile registry, merge/validate tooling, PolicyProfileRegistry.sol, route-confidence scoring, policy-aware quote/build interfaces
Dependencies	URA schemas, profile validation, Phoenix integration, DBIS Rail policy mapping, route evidence
Production gate	manifest and profiles validate, registry paths are coherent, route-confidence schema exists, quote/build surfaces can consume policy state
Evidence / output artifact	URA_MANIFEST_AUTOMATION_IMPLEMENTATION_TRACKER.md, PolicyProfileRegistry.sol
Owner class	repo

W5. DBIS RTGS / DBIS Rail / OMNL / settlement sidecars

Field	Value
Objective	Convert the institutional settlement stack from fragmented plans into a staged production program
In-scope components	RTGS first slice, DBIS Rail, OMNL mappings, settlement event sources, custody and sidecar boundaries
Dependencies	policy profiles, jurisdiction traceability, institutional onboarding, external counterparties
Production gate	first-slice controls and sidecar boundaries explicit, evidence sources mapped, operator runbooks and checklists current
Evidence / output artifact	DBIS_RTGS_MASTER_PLAN_IMPLEMENTATION_TRACKER.md, DBIS_RAIL_JURISDICTION_TRACEABILITY.md
Owner class	mixed

W6. Jurisdiction / compliance and onboarding matrices

Field	Value
Objective	Turn compliance and jurisdiction documentation into executable governance inputs for the ecosystem
In-scope components	jurisdiction catalog, compliance matrices, onboarding charter/playbook, DBIS Rail traceability links
Dependencies	policy profiles, RTGS/DBIS Rail architecture, institution onboarding references
Production gate	jurisdiction catalog current, matrix docs mapped to policy profiles, onboarding outputs traceable to control-plane requirements
Evidence / output artifact	config/jurisdictions/catalog.v1.json, compliance-matrices/README.md
Owner class	repo

W7. Identity / Hyperledger / interoperability stack

Field	Value
Objective	Mature identity and interoperability architecture into a staged runtime program
In-scope components	Hyperledger runtime decisions, identity stack, workflow runtime, interoperability surfaces
Dependencies	sovereign compute readiness, institutional workstreams, policy controls, operator ownership
Production gate	runtime topology, ownership, and promotion criteria explicit enough to move from design into implementation slices
Evidence / output artifact	DBIS_HYPERLEDGER_RUNTIME_STATUS.md, DBIS_HYPERLEDGER_IDENTITY_STACK_DECISION.md
Owner class	planned

W8. Observability, verification, evidence, and operator readiness

Field	Value
Objective	Ensure the ecosystem can prove readiness and health through machine-readable evidence and operator workflows
In-scope components	validation wrappers, cluster audits, cert checks, route/readiness evidence, operator handoffs, deployment readiness artifacts
Dependencies	stable inventories, maintained runbooks, validation scripts, current indexes
Production gate	operator wrappers current, key cert/health checks automated, evidence docs indexed, validation gates passing
Evidence / output artifact	run-all-validation.sh, OPERATOR_HANDOFF_2026_04_24.md
Owner class	mixed

5. Near-Term Roadmap (0–12 Months)

0–3 months

• keep W1 healthy and template-aligned across all current cluster hosts
• finish promoting W4 from repo-implemented to operator-usable for manifest, policy profile, and registry paths
• wire route confidence into the same machine-readable family as URA and public routing coverage
• keep Phoenix deploy/control surfaces aligned with current manifests and deploy targets

3–6 months

• promote W2 from documented routing potential to policy-aware route coverage
• advance W5 first-slice institutional settlement and sidecar gates with evidence-backed operator readiness
• formalize W6 so jurisdiction and onboarding matrices act as real control inputs, not passive references

6–12 months

• integrate URA + policy profiles + route confidence into Phoenix/API quote/build surfaces
• make W8 evidence and operator readiness outputs sufficient for routine promotion gates
• move selected W7 identity/interoperability pieces from design status into repo-implemented slices where source-of-truth and ownership are explicit

6. Longer-Horizon Roadmap (12–36 Months)

• deepen sovereignization of compute, control, and settlement dependencies
• expand beyond the current EVM-heavy bridge/routing surface into non-EVM lanes where evidence and policy can be enforced cleanly
• mature DBIS Rail, RTGS, and custody-sidecar systems into richer institutional operating models
• promote additional identity, workflow, and interoperability systems into governed runtime slices
• converge route-confidence, policy profiles, and settlement policy into one end-to-end institutional control plane

7. Open Blockers And External Dependencies

Repo-solvable

• route-confidence schema and quote/build integration are not yet first-class
• Phoenix control-plane surfaces are not yet fully policy-aware
• some institutional and identity tracks remain split across multiple narrower docs without enough shared machine-readable state

Operator-solvable

• some planned control-plane and settlement flows still depend on operator activation and deployment rather than fully codified automation
• runtime promotion for URA, sidecars, and some institutional slices still needs explicit environment rollout work

External / vendor / network blockers

• counterparties, institutional integrations, and some network-specific dependencies remain outside repo control
• certain public-network and destination-liquidity expansions depend on third-party bridge, exchange, or ecosystem realities
• Wemix and other externally constrained paths remain subject to network or vendor-specific blockers

Recommended Architectural Direction

The strongest near-term strategic recommendation is to adopt this as the canonical next-generation control-plane pattern:

URA manifest + Policy Profile Registry + route confidence

That pattern should be the bridge between:

• Phoenix deploy and control APIs
• jurisdiction and compliance matrices
• DBIS Rail and RTGS policy enforcement
• Besu/routing evidence and route selection
• on-chain publication of approved policy-profile state in smom-dbis-138

This is not distant speculation. It is the most important near-term architecture move because the repo already contains the beginnings of every major piece.