Files
proxmox/docs/dbis-rail/DBIS_RAIL_STABLECOIN_POLICY_V1_5.md
defiQUG b3a8fe4496
Some checks failed
Deploy to Phoenix / deploy (push) Has been cancelled
chore: sync all changes to Gitea
- 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

5.6 KiB
Raw Blame History

DBIS Rail Stablecoin Policy v1.5

Network: DBIS Mainnet (ChainID 138)
Document type: v1.5 Add-on — Canonical USDC/USDT and stablecoin definition, registry, monitoring
Companion documents: DBIS Rail Technical Spec v1, DBIS Rail Rulebook v1, DBIS Rail Conversion Router Spec v1.5


1. Purpose and Scope

This add-on defines USDC, USDT, and other stablecoins as legally/operationally defined instruments with:

  • A Stablecoin Reference Registry (on-chain and documented) listing token symbol, address, issuer/bridge, legal claim type, redemption path, reserve disclosure, risk tier, pause authority, and status.
  • A Canonical Stablecoin Policy (Rulebook addendum): only allow swaps and routing into canonical stablecoin IDs that are registered and in ACTIVE status.
  • Monitoring for peg deviation, bridge health, and emergency corridor halt when stablecoin risk triggers.

The result is that “USDC/USDT” are defined instruments with redemption standing and routing rules, not merely ERC-20 labels.


2. Stablecoin Reference Registry

2.1 On-Chain and Documented

The registry may be implemented as an on-chain contract (e.g. StablecoinReferenceRegistry) and/or maintained in documented form for audit. The following fields are required for each registered stablecoin:

Field Description
tokenSymbol Symbol (e.g. USDC, USDT, cUSDC).
tokenAddress Contract address on Chain 138.
issuerOrBridge Issuer or bridge entity responsible for redemption or reserve.
legalClaimType Nature of claim (e.g. direct claim on issuer, claim via bridge, custodial).
redemptionPath How the holder may redeem (e.g. issuer portal, designated custodian, bridge withdrawal).
reserveDisclosureRef Reference to reserve disclosure (e.g. URL or document id).
riskTier Policy-defined tier (e.g. 13) for limits or treatment.
pauseAuthority Address or role that can pause the token (if applicable).
stablecoinStatus ACTIVE / SUSPENDED / REVOKED. Only ACTIVE may be used for routing.

2.2 Administration

  • Registration and updates (including status changes) are restricted to a defined admin or role (e.g. STABLECOIN_REGISTRAR or governance).
  • Only tokens that have completed a registration and risk review may be added. Status may be set to SUSPENDED (e.g. during investigation) or REVOKED (removed from use) without removing the record.

2.3 Use in Routing

  • The Conversion Router (and any DEX/aggregator integration governed by this policy) must resolve token by canonical stablecoin ID (registry key or tokenAddress that appears in the registry with status ACTIVE).
  • Swaps or routes into a token that is not in the registry, or whose status is not ACTIVE, must be rejected when this policy applies.

3. Rulebook Addendum — Canonical Stablecoin Policy

3.1 Policy Statement

  • Only allow swaps (and, where policy applies, other flows) into canonical stablecoin IDs registered in the Stablecoin Reference Registry.
  • Require stablecoinStatus = ACTIVE to route. Tokens in SUSPENDED or REVOKED status must not be used as output (or input, where policy so requires) until re-approved.
  • The Conversion Router and any DEX/aggregator integration must resolve token by registry; use of an unregistered or non-ACTIVE address is a policy violation and must be rejected by the system.

3.2 Relation to Good Funds

  • The Rulebooks good funds matrix (Rulebook §2) and finality triggers apply to settlement and mint. This add-on does not change them.
  • The Canonical Stablecoin Policy governs which stablecoin contracts may be used as destinations (or sources) for conversions and routing, ensuring that only defined instruments with disclosed redemption path and status are permitted.

4. Monitoring

4.1 Peg Deviation Thresholds

  • Define alert and, if policy requires, auto-halt thresholds for peg deviation (e.g. ±2% from 1:1 for USD-pegged stablecoins).
  • When a threshold is breached, procedures must define: alerting, escalation, and whether conversion or mint into that stablecoin is temporarily halted until the issue is resolved or the token is suspended in the registry.

4.2 Bridge Health (Bridged Stablecoins)

  • For stablecoins that are bridged (e.g. bridged USDC), monitor bridge health and liquidity.
  • If bridge is degraded or compromised per DBIS policy, the token may be set to SUSPENDED in the registry and routing halted until re-approved.

4.3 Emergency Corridor Halt

  • If stablecoin risk triggers (e.g. depeg, issuer event, bridge failure), a designated role may trigger an emergency corridor halt for that token or corridor.
  • Procedures must document: who may trigger, how (e.g. set status to SUSPENDED, or invoke a pause on the Conversion Router for that token), and the process for resumption (including any required sign-offs or audits).

5. Cross-References

  • Technical Spec — Participant and registry patterns; optional on-chain StablecoinReferenceRegistry follows similar access-control and event patterns.
  • Conversion Router Spec v1.5 — Venue and token allowlist; tokenOut (and tokenIn when required) must resolve to a canonical stablecoin ID in ACTIVE status per this policy.
  • Rulebook — Good funds (§2), compliance (§4.3); this add-on is a Rulebook addendum for canonical stablecoin definition and routing.

6. Document Control

Field Value
Title DBIS Rail Stablecoin Policy v1.5
Version 1.5
Status Active