Files

Deploy to Phoenix / deploy (push) Has been cancelled

Details

- Config, docs, scripts, and backup manifests
- Submodule refs unchanged (m = modified content in submodules)

Made-with: Cursor

2026-03-02 11:37:34 -08:00

16 KiB

Raw Permalink Blame History

DBIS Rail — Regulator-Facing Brief v1

Network: DBIS Mainnet (ChainID 138)
Document type: Institutional narrative summary
Audience: Bank counterparties, examiners, external counsel, risk committees, institutional integration teams
Companion documents: Technical Spec v1, Rulebook v1, Security Threat Model v1

1. Executive Overview

The DBIS Rail is a programmable settlement rail operating on DBIS Mainnet (ChainID 138). It enables the recording of settlements and the minting of GRU (and linked token) against authorizations that are rooted in ISO-20022 messaging and regulated ledger practice, while keeping finality determination and compliance within the operational and regulatory domain.

Purpose. The rail is designed to:

Provide a deterministic on-chain execution layer for settlement instructions that have been validated off-chain.
Enforce threshold-controlled mint governance so that GRU is minted only when a defined quorum of authorized signers has approved a Mint Authorization.
Support institutional finality discipline by tying each on-chain settlement to a unique message identifier, an accounting reference, and a hash of the underlying evidence bundle.

Core principle. DBIS Rail enforces authorization integrity on-chain while preserving fiat finality determination within regulated ledger domains. The chain does not decide whether fiat funds are final; it enforces that only properly authorized, replay-protected, and policy-compliant instructions result in settlement and mint.

2. Network and Governance Model

Network. The rail runs on DBIS Mainnet (ChainID 138), a permissioned blockchain using Besu with QBFT (Quorum Byzantine Fault Tolerant) consensus. Block production is performed by a defined validator set under operational governance. The application layer consists of a set of contracts that implement participant registration, signer allowlisting, settlement routing, and mint execution.

Governance.

Validators: Produce and order blocks. They do not sign Mint Authorizations and do not execute settlement logic. Validator rotation and emergency measures are governed operationally (and may be augmented by on-chain governance in future).
Contract administration: Role-based (e.g., ROOT_ADMIN, PARTICIPANT_ADMIN, SIGNER_ADMIN, ROUTER_ADMIN) with multisig or timelock where appropriate. Upgrades and critical configuration changes follow defined governance procedures.
Signer quorum: Mint Authorizations require a threshold of allowlisted signers (default: 3-of-5) with mandatory participation from a designated Compliance category. No single role can approve a mint alone.
Mint path: The only on-chain path that can cause GRU to be minted is via the Settlement Router. The Mint Controller accepts instructions solely from the Router after validation of signatures, replay protection, and policy checks.

Compartmentalization. Validators, signers, the ISO Gateway (off-chain), the Settlement Router contract, and the GRU Mint Controller are distinct. Validators order transactions; signers attest to authorizations; the Gateway assembles evidence and produces the authorization payload; the Router validates and records; the Mint Controller executes the mint. No single component both determines finality and executes mint.

3. Settlement Lifecycle (High-Level)

Settlement on the DBIS Rail follows a defined sequence. The following is a high-level description; technical detail is in the Technical Spec.

ISO message receipt. The ISO Gateway receives one or more ISO-20022 messages (e.g., pacs, camt, pain family) and associated evidence.
Compliance checks. Required compliance checks (KYC, AML, sanctions, jurisdiction, limits) are performed. No Mint Authorization may be issued for a failing or unresolved case.
Double-entry accounting. The underlying transaction (or batch) is posted in the DBIS ledger domain with required reserve account tagging. Posting must be complete and immutable before an authorization is issued.
Deterministic accounting reference. An accounting reference (accountingRef) is generated from the ledger posting using a deterministic formula (ledger system, journal, batch, timestamp, reserve account). This binds the future on-chain settlement to a specific ledger event.
Mint Authorization construction. A Mint Authorization (MintAuth) is built containing message identifier, evidence hash (isoHash), accounting reference, funds status (ON_LEDGER_FINAL or OFF_LEDGER_FINAL per Rulebook), recipients, amounts, time window, chain identifier, and verifying contract. The construction follows EIP-712 for signing.
Threshold signer approval. Allowlisted signers from the required categories sign the Mint Authorization. The default rule is 3-of-5 with Compliance mandatory. Signers are expected to sign only when Rulebook preconditions (good funds, accounting, compliance, evidence) are satisfied.
Router validation and recording. The Settlement Router receives the Mint Authorization and signatures. It verifies signature validity, quorum and category rules, time window, replay (messageId not previously used), policy caps, and participant allowlist. If all checks pass, it records the settlement and calls the Mint Controller.
GRU mint. The Mint Controller mints the specified amounts to the specified recipient addresses. It is callable only by the Router.
Audit events. The Router and related contracts emit immutable on-chain events (e.g., SettlementRecorded, MintExecuted) including message identifier, accounting reference, evidence hash, and amounts. These support audit and regulatory reporting.

4. Good Funds and Finality Framework

Finality of the underlying fiat or ledger position is not determined by the chain. It is determined in the regulated domain and encoded in the Mint Authorization (e.g., via funds status and the evidence bundle). The Rulebook defines when a settlement may be treated as final for the purpose of issuing a Mint Authorization.

Principle. The chain enforces authorization integrity (signatures, replay, policy). The Rulebook governs good-funds determination and when ON_LEDGER_FINAL or OFF_LEDGER_FINAL may be asserted for each rail type (wire, ACH, instant, cash, internal). Reversal windows and exception handling are defined in the Rulebook; no Mint Authorization may be issued until the applicable finality trigger and reversal rules are satisfied.

Funds status.

ON_LEDGER_FINAL: Funds are final in the DBIS-controlled ledger domain (e.g., core posting complete, irrevocable per policy). The Rulebook specifies the trigger per rail type (e.g., wire: core posting complete; ACH: settlement date plus return window elapsed).
OFF_LEDGER_FINAL: Funds are final via an external rail plus reconciliation as defined by DBIS policy (e.g., SWIFT confirmation and Nostro reconciliation). Used only where policy permits and reconciliation is complete.

Reversal. Before a Mint Authorization is submitted, reversals or exceptions prevent issuance or require cancellation of the authorization. After mint execution, on-chain settlement is final from the chain’s perspective. Post-mint reversals in the fiat/ledger domain do not automatically reverse the mint; any corrective action (e.g., burn or offset) follows defined procedures in the Rulebook and operational policy.

5. Controls and Safeguards

5.1 Authorization controls

EIP-712 domain separation: Signatures are bound to chain identifier and the Settlement Router contract address. Authorizations signed for another chain or contract do not verify.
Message identifier replay protection: Each message identifier may be used at most once. A second submission with the same identifier is rejected.
Time-bound authorization: Each Mint Authorization carries a validity window (notBefore, expiresAt). Submissions outside the window are rejected.
Required Compliance signer: The signer set must include a signer from the designated Compliance category. This is enforced on-chain.
Signer allowlist and revocation: Only addresses on the Signer Registry may contribute valid signatures. Signers may be removed; procedures govern handling of in-flight authorizations and compromised keys.

5.2 Operational controls

Deterministic accounting reference: The accounting reference is derived from ledger identifiers (system, journal, batch, timestamp, reserve account) so that it can be audited against a unique posting.
Evidence bundle and isoHash: The canonical evidence bundle supporting the settlement is hashed; the hash (isoHash) is included in the Mint Authorization. This links on-chain settlement to the off-chain evidence; procedures require the bundle to reflect actual finality and posting.
One-to-one mapping: Under normal policy, each accounting reference corresponds to at most one Mint Authorization, and each message identifier to one settlement. Exceptions, if any, are documented and auditable.

5.3 Technical controls

Reentrancy protection: The Settlement Router is implemented so that state updates occur before external calls (e.g., to the Mint Controller), and reentrancy guards are used where appropriate.
Cap enforcement before mint: Per-message and per-corridor caps are checked and updated before the mint is invoked. Exceeding a cap causes the transaction to revert.
Router pause: An authorized role may pause the Settlement Router, halting new settlements until the pause is lifted.
Mint controller isolation: The Mint Controller accepts mint instructions only from the Settlement Router. Direct mint paths (e.g., owner or other roles on the token) are removed or revoked so that the rail is the sole mint path.

6. Risk Management and Threat Posture

The DBIS Rail is designed so that unauthorized minting, replay of authorizations, and confusion between chains or contracts are prevented by on-chain checks and operational procedure. A formal threat assessment is maintained (Security Threat Model v1) and is summarized here.

Threat categories.

Authorization layer: Forgery, replay, cross-chain replay, expired or wrong-contract authorizations, signer compromise, quorum or category bypass. Mitigations include EIP-712 domain binding, messageId one-time use, time window, Signer Registry and quorum rules, and operational key protection and role separation.
Ledger and accounting: Fake or misused accounting references, misclassification of funds status, good-funds misrepresentation. Mitigations include the deterministic accountingRef, the Rulebook good-funds matrix, hashing of the evidence bundle into isoHash, and reconciliation and audit procedures.
Settlement Router: Reentrancy, overflow, policy-cap or pause bypass. Mitigations include checks-effects-interactions pattern, guards, strict validation of inputs and caps, and paused-state checks.
Mint Controller: Direct mint or role escalation. Mitigations include restriction of mint to the Router only and revocation of other mint paths; upgrades are subject to governance and timelock.
Validator layer: Collusion, censorship, chain halt. Mitigations include QBFT finality, documented validator governance, and the ability to pause the rail in response to availability or integrity concerns.
Off-chain: ISO Gateway compromise, signer key theft, insider collusion, compliance or accounting failure. Mitigations include HSM or secure storage for signer keys, separation of signer and Gateway roles, quorum design with mandatory Compliance, signer revocation procedures, and monitoring and audit.

Important distinction. The system is designed to prevent unauthorized minting, replay, and domain confusion. It does not independently determine fiat finality. Finality is determined in the regulated ledger and compliance domain; the chain enforces that only properly authorized and policy-compliant instructions result in settlement and mint.

7. Audit and Transparency

On-chain events: Settlement and mint execution produce immutable on-chain events (e.g., SettlementRecorded, MintExecuted) that include message identifier, accounting reference, evidence hash, funds status, and amounts. These events support audit and regulatory reporting.
Anchoring: Each settlement is anchored by messageId and accountingRef, with isoHash linking to the off-chain evidence bundle. Mappings (messageId to evidence, messageId to accountingRef, accountingRef to ledger posting) are maintained for audit and examination.
Registry and status logging: Changes to the signer allowlist and to participant status (e.g., registration, suspension, revocation) are recorded on-chain or in controlled logs, with versioned documentation.
Review cycle: The Rulebook, Threat Model, and related documentation are subject to a defined review cycle (e.g., annual and on material change). Versions are published and retained.

8. Residual Risk Disclosure

The following are relied upon for the intended security and compliance properties of the rail. They are not verified on-chain; their failure is an operational or off-chain risk.

ISO Gateway correctness: The Gateway correctly applies the Rulebook (good funds, finality triggers, reversal windows), builds the evidence bundle, and computes the accounting reference and evidence hash in accordance with the defined rules. The chain does not verify ledger or compliance state.
Ledger integrity: The core (or designated) ledger correctly records postings and the accounting reference is produced only for completed, compliant postings. No tampering or fabrication of postings is assumed.
Signer independence and key security: Signers are distinct from Gateway operators and sign only when preconditions are satisfied. Signer private keys are protected (e.g., HSM or equivalent). Compromise of fewer than a quorum of signers does not by itself yield a valid Mint Authorization.
Validator majority honesty: A sufficient majority of validators (per QBFT) follow the protocol. Finality of blocks is maintained; no reversion of finalized blocks is assumed under normal operation.
Governance and administration: Admin roles and upgrade paths are used in accordance with policy; multisig or timelock is applied where required. No backdoor or unauthorized change to contracts or configuration is assumed.

This disclosure is made to support informed assessment by counterparties, examiners, and risk committees. Mitigation of residual risk is through operational controls, the Rulebook, and independent audit rather than on-chain verification.

9. Governance and Amendment

Technical Spec: Defines contract behavior, data structures, and on-chain validation rules. Changes to the Spec that affect deployed contracts require deployment or upgrade following governance.
Rulebook: Defines operational and compliance rules (good funds, finality, reversal, signer governance, incident controls, audit). Amendments are approved per DBIS policy and take effect on a stated effective date.
Threat Model: Describes threat categories, mitigations, severity, and residual risk. It is reviewed periodically and when design or deployment changes materially affect risks.
Versioning and publication: Documentation is versioned. Current versions are published (e.g., in docs/dbis-rail/ or an official repository); superseded versions are retained for reference and audit.

Document Control

Field	Value
Title	DBIS Rail — Regulator-Facing Brief v1
Network	DBIS Mainnet (ChainID 138)
Audience	Bank counterparties, examiners, counsel, risk committees, integration teams
Companions	Technical Spec v1, Rulebook v1, Security Threat Model v1
Version	1
Status	Active

16 KiB Raw Permalink Blame History Unescape Escape