Tokenized Deposits
Tokenized-deposit programmes represent bank liabilities in a governed workflow with explicit money-form boundaries, release conditions, receiving-institution confirmation, and recredit or redemption close.
Introduction
A tokenized deposit is a bank liability represented in programmable form under a bank-run programme. The public record distinguishes same-bank treasury movement, cross-bank coordination, and tokenized-asset cash-leg support instead of flattening them into one generic digital-cash story.
Within the StableNexus model, the issuing institution, receiving institution, control-account logic, interoperability adapters, and close evidence remain visible as separate roles. StableNexus governs the workflow, policy, evidence, and publication layer around those roles.
Program at a glance
- Instrument family
- Bank-liability tokenized deposit under an issuing-institution programme.
- Primary modes
- Same-bank treasury movement, cross-bank coordination, and tokenized-asset cash-leg support.
- Release basis
- Trigger, condition, and action logic tied to programme rules and operating windows.
- Receiving proof
- Receiving-institution acceptance and destination-credit confirmation where the route requires it.
- Close path
- Return, recredit, redemption, or controlled close depending on the route outcome.
- StableNexus role
- Policy, workflow, evidence, and publication layer around the bank-run programme.
Participant and responsibility map
| Role | Responsible for | Boundary |
|---|---|---|
| StableNexus | Programme workflow state, rule evaluation, evidence capture, and publication layer. | Not the issuing institution, receiving institution, or settlement bank. |
| Issuing institution | Creating and extinguishing the bank-liability instrument, programme terms, and liability-state authority. | Owns the deposit programme and bank-money liability. |
| Treasury / control-account function | Funding recognition, internal reservation state, release readiness, and return or recredit control. | Bank-side balance and control-account authority remain partner-owned. |
| Receiving institution | Destination acceptance, credit confirmation, and route-specific close evidence where applicable. | Needed only where the movement leaves the issuing institution. |
| Interoperability / settlement adapter | Partner-mounted movement, message, or coordination rails between institutions and legacy systems. | Optional adapter layer, not a StableNexus-owned network. |
| Client system / treasury initiator | Instructing the movement or cash-leg action under the programme rules. | Initiation does not override bank-side programme controls. |
Tokenized deposit vs reserve-backed stablecoin
| Question | Tokenized deposit | Reserve-backed stablecoin |
|---|---|---|
| Who issues the instrument | An issuing institution inside a bank-liability programme. | A named issuer under a reserve-backed stablecoin structure. |
| What the holder has | A bank-liability claim under the deposit programme. | A token under the stablecoin issuer and reserve structure. |
| Primary workflow concern | Release conditions, receiving-institution confirmation, and recredit or redemption close. | Reserve recognition, issuance, redemption, and reserve-attestation discipline. |
Read next
- What It Is and How It Works: Bank-liability definition, route types, and close sequence.
- Same-Bank and Cross-Bank Settlement Modes: How same-bank close differs from cross-bank confirmation.
- Programmability and Release Conditions: Controlled release logic tied to operating windows and route state.
- Stablecoin: Reserve-backed stablecoin issuer, reserve, redemption, and legal structure.
- Tokenized Assets: Asset-programme docs for securities, debt programmes, and private-market asset workflows.