Tokenized Deposits

Cari DDA Tokenization (Mint/Burn)

Converting an existing Demand Deposit Account balance into an on-chain token on Prividium. The token is a direct liability of the issuing bank — not a stablecoin. FDIC insurance follows the deposit, not the token.

Vendors

Cari Network · Prividium (ZKsync) · Member Banks

Compliance Center

Existing bank KYC/KYB at Identity — DDA holder already verified. Token creation is a ledger representation change, not a new customer relationship.

Filter by shape:
|
C1 · UNKNOWNCari DDA Tokenization (Mint/Burn)·5 stations(1 compliance, 4 infra)·cari-network · huntington · m-and-t · keycorp · first-horizon · old-national
S1S2IDENTITYS3DISCOVERYS4S5TRANSPORTS6S7FACILITATIONS8FINALITY01Bank Account02Authorization03Mint04Bank Account05Finality
3+5 shape system
GatePre-condition — blocks if it failsMonitorConcurrent — observes without haltingObligationPost-settlement — reports after the factsolid = codedashed = policy
How to read this diagram
Each station on the rail represents a compliance or infrastructure event in the Cari DDA Tokenization (Mint/Burn) path. Hover any station to inspect it. The shape tells you what kind of event it is. The ring tells you how it's enforced.
Gate Monitor Obligation| Ingress Crossing Transform Settlement Venue
This path at a glance
5 stations across 5 of 8 segments. 1 are compliance checkpoints, 4 are infrastructure.
2 code-enforced3 policy-enforced
C1 · CARI DDA TOKENIZATION (MINT/BURN) · PRIVIDIUM (CARI NETWORK ZK SUBSTRATE)
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L5 APPLICATIONCari member bank treasury system + Cari Network onboarding portal — identity inheritance from core-banking CIP file
L4 ACCOUNTCustomer DDA ↔ Prividium party-id (bank-issued wallet credential bound to existing account number)

Step 1 · DDA Holder Identity (Inherited from Bank Onboarding)Policy-Enforced

"An existing bank customer logging into their treasury portal — no new customer-identification program runs because the bank already holds a complete CIP file from the original DDA opening."

The customer relationship sits at the issuing Cari member bank — Huntington National Bank, M&T Bank, KeyCorp, First Horizon, or Old National Bank [VERIFY current consortium roster]. Identity attestation, beneficial-ownership disclosure, OFAC screening, and ongoing transaction monitoring are already in place under existing BSA/AML obligations (12 C.F.R. § 21.21 for national banks; 31 C.F.R. § 1010.230 for beneficial-ownership).

The Cari mint operation is a ledger-representation change on an already-attested customer. No new customer-identification program runs; no new account is created at the bank; the deposit liability remains on the bank's balance sheet exactly as before. The wallet credential is a Prividium party-id provisioned by the issuing bank's treasury system, cryptographically bound to the customer's existing core-banking-system account number.

L4 ACCOUNT and L5 APPLICATION lit. The bank-side KYC inheritance is the structural innovation — every other tokenization pattern in the registry creates a new attestation surface. Cari mints do not. This is why compliance gravity sits at stage 2 (Identity) but the work has already happened off-path.

Honesty marker: FDIC insurance follows the underlying deposit, not the token. The token is a ledger representation; the legal liability that carries FDIC pass-through is the demand deposit account at the issuing bank. If the issuing bank fails, FDIC resolution attaches to the DDA per its standard $250,000 / depositor / institution / ownership-category limits — the token is not a separate insured instrument. Customers should not assume holding a Cari DDA token in a self-hosted wallet creates additional insurance coverage; coverage is bounded by the underlying deposit's category at the issuing bank.
Counterparty
Cari member bank (issuing institution)
Latency
Instant — identity attestation pre-existing
Finality
N/A — no token movement yet
Cadence
Per customer · annual KYC refresh inherited from bank's existing program
Vendors
Cari Network onboarding portal · Issuing-bank core-banking system (Fiserv DNA · FIS IBS · Jack Henry SilverLake patterns — VERIFY bank-by-bank) · Prividium party-id provisioning
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L5 APPLICATIONIssuing bank treasury authorization workflow — dual-control + sanctions re-screen + good-standing check
L4 ACCOUNTCustomer DDA balance state + Prividium wallet eligibility (party-id allowlist)
L3 EXECUTIONCari mint contract — bank-signature verification + per-bank programmatic ceiling enforcement
◆ Enforcement Line — mixed code- and policy-enforced

Step 2 · Bank Authorization (Mint Approval)Mixed EnforcementINGESTDETECTALERT

"A wire-room officer authorizing a debit memo against a customer account — the bank's internal controls validate that the customer holds clear funds and is in good standing before any movement is permitted."

The issuing bank's treasury system authorizes the mint. The bank verifies that the customer's DDA holds sufficient cleared balance, that the customer is not under hold, freeze, or restraint, and that the requested mint amount falls within any per-customer or per-bank programmatic ceilings encoded in the consortium charter.

Authorization is mixed-enforcement: the bank's internal core-banking controls (authorization workflow, dual-control on large amounts) are policy-enforced; the on-chain mint contract enforces the bank's signature and the per-bank programmatic ceiling code-side. Both legs must clear before the mint fires.

L3 EXECUTION (mint contract signature verification + ceiling check) · L4 ACCOUNT (customer wallet eligibility) · L5 APPLICATION (bank treasury system holding the audit trail) all lit. C9 (prudential) applies because the mint creates a ledger entry that must reconcile to the bank's general ledger as a memo entry against the underlying DDA.

Honesty marker: The mint is a ledger representation change, not a new financial instrument. Regulatory clarity on the operational accounting treatment (memo entry vs. sub-account vs. separate liability class) varies by issuing-bank's interpretive position with their primary regulator. National banks under OCC supervision look to OCC Interpretive Letter 1183 (2023) on bank-permissible distributed-ledger activity; state-chartered banks look to their state regulator's guidance. The accounting treatment carries VERIFY at the bank level and is load-bearing for FDIC pass-through opinion.
Counterparty
Issuing bank treasury + Cari mint contract
Latency
Sub-second on-chain after bank approval · bank approval typically real-time for retail amounts; dual-control review for institutional amounts
Finality
Pre-condition — mint blocked if bank withholds authorization or ceiling exceeded
Cadence
Per mint request · ceiling reset cadence per consortium charter (typically daily)
Vendors
Issuing-bank treasury authorization workflow · Cari mint contract (per-bank policy ceilings) · Prividium party-id allowlist
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L4 ACCOUNTCustomer Prividium wallet ↔ DDA token credit (1:1 with bank-side memo debit)
L3 EXECUTIONCari mint contract — atomic mint coordinated with bank GL memo entry
L2 CONSENSUSPrividium BFT consensus among member-bank validator nodes
L1 NETWORKPrividium ZK substrate — proofs settle to Ethereum L1 for finality anchoring
◆ Enforcement Line — code-enforced at this layer

Step 3 · Mint — DDA Token Issued on PrividiumCode-Enforced

"A bank's intraday liquidity transfer between sub-ledgers — the funds do not leave the bank, but their internal accounting representation moves from one books-of-record location to another."

The mint fires on Prividium. The Cari mint contract debits the customer's DDA on the issuing bank's books (a memo entry against the deposit), and credits the customer's Prividium wallet with the equivalent token amount. The on-chain operation is atomic with the bank-side memo entry through a Cari Network coordination message — both sides commit together or both revert.

L1 NETWORK, L2 CONSENSUS, L3 EXECUTION, and L4 ACCOUNT all lit: the full Prividium stack below the application layer processes the mint. The deposit liability remains on the bank's balance sheet exactly as before; the token represents a contractual claim against the deposit, NOT a new liability.

C11 (recordkeeping) attaches to the mint event — the on-chain transaction hash and the bank's general-ledger memo entry together constitute the audit trail. The reconciliation between the on-chain token supply and the bank's outstanding tokenized-DDA balance must clear at end-of-business each day under Cari Network operational rules.

Counterparty
Cari mint contract + issuing bank general ledger
Latency
Sub-second · atomic on-chain mint coordinated with bank GL
Finality
Final on Prividium consensus · reconciled to bank GL same business day
Cadence
Per mint event · daily GL reconciliation under Cari operational rules
Vendors
Cari mint contract (Prividium) · Issuing-bank core-banking GL memo-entry interface · Prividium ZK substrate (Matter Labs prover)
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L5 APPLICATIONIssuing bank treasury system — interest accrual + statement generation continues exactly as for an untokenized DDA
L4 ACCOUNTCustomer Prividium wallet — DDA token balance state

Step 4 · On-Chain Holding (Customer Wallet)Policy-Enforced

"A treasury balance held at the bank earning standard demand-deposit interest — the customer can move it, redeem it, or hold it under existing account terms."

The customer holds the DDA token in their Prividium wallet. The token earns the same demand-deposit interest the underlying DDA earns — the bank does not bifurcate interest accrual between tokenized and untokenized portions of the deposit.

The customer can transfer the token to other consortium-bank customers via path C2 (interbank transfer), use it as the cash leg in a B2B payment via path C3 (commercial payment), participate in automated treasury sweeps via path C4 (liquidity sweep), or burn it back to standard DDA balance via this path's burn operation.

Holding the token does not change the customer's relationship with the issuing bank — the bank remains the deposit liability holder, the regulatory perimeter holder, and the point of customer service. L4 ACCOUNT (token state) and L5 APPLICATION (bank treasury system) lit, both policy-enforced.

Counterparty
Customer wallet · issuing bank
Latency
Continuous
Finality
Final on Prividium · subject to standard DDA terms (offset rights · garnishment exposure)
Cadence
Continuous · interest accrued per bank's standard DDA schedule
Vendors
Customer Prividium wallet · Issuing-bank treasury system (interest accrual + statement) · Cari Network ledger (balance state)
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L5 APPLICATIONIssuing bank GL credit — DDA balance restored from tokenized to standard ledger entry
L4 ACCOUNTCustomer Prividium wallet ↔ token debit (token supply contracts)
L3 EXECUTIONCari burn contract — atomic burn coordinated with bank GL credit
◆ Enforcement Line — code-enforced at this layer

Step 5 · Burn — Redeem Token to Standard DDA BalanceCode-Enforced

"A treasury sweep returning intraday-liquidity-product funds to the standard demand-deposit account — the same money, the same bank, a different ledger representation."

The customer or the issuing bank initiates a burn. The Cari burn contract debits the customer's Prividium wallet by the burn amount and credits the customer's DDA on the bank's books with the equivalent — atomic, coordinated identically to the mint operation in reverse.

The token supply contracts; the underlying deposit balance remains unchanged on the bank's balance sheet. The customer experiences the burn as a ledger representation change: the same dollar amount, now visible in their standard online-banking interface rather than their Prividium wallet.

L3 EXECUTION (burn contract) · L4 ACCOUNT (wallet state) · L5 APPLICATION (bank GL credit) lit. C9 (prudential) attaches because the bank's intraday liquidity exposure adjusts as the tokenized portion contracts; C11 (recordkeeping) attaches to the burn event for the GL reconciliation trail.

Counterparty
Cari burn contract + issuing bank GL
Latency
Sub-second
Finality
Final on Prividium · reconciled to bank GL same business day
Cadence
Per burn event · daily GL reconciliation
Vendors
Cari burn contract (Prividium) · Issuing-bank core-banking GL credit interface · Prividium ZK substrate
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))

Resolved 5 steps across 1 chain(s). 0 threshold(s) triggered. Frameworks: Common Reporting Standard / FATCA.

Coverage notes: 5 disclosed gap(s).

TOOL 01 · 14-DIMENSION COMPARISON

Deposit vs Stablecoin Comparator

Side-by-side compliance comparison of tokenized deposits (bank liability, FDIC pass-through) vs stablecoins (non-bank reserve-backed liability) across 14 regulatory dimensions — the structural distinction GENIUS Act §13 codifies.

TOKENIZED DEPOSITSTABLECOIN= relative strength (3 = strong)REGULATORY PERIMETERFDIC Insurance EligibilityIssuer ClassificationBasel Capital TreatmentPrimary Regulatory FrameworkOPERATIONALKYC / OnboardingAML / Transaction MonitoringProgrammabilityCross-Network InteropSETTLEMENTSettlement AvailabilitySettlement FinalityCounterparty RiskRISK & ACCESSRedemption ModelTransaction PrivacyAccess Model