How a tokenized bank deposit moves through the platform, from fiat deposit and issuance through secondary trading, settlement, cross-chain movement, and redemption, and exactly which authorities never leave the regulated core.
This document walks through the operational design for the platform's anchor use case: a regulated Canadian bank deposit, tokenized as DepositToken-CAD, moving through its full life. The architecture treats the KCS platform as the regulated control plane and any blockchain or interoperability provider as a bounded, swappable component underneath it. Eight stages, one canonical ledger, and a supervisory trail the whole way through.
Underneath those eight stages sit six architectural layers, and the order matters. KCS governance, compliance with the canonical ledger, and the canonical token registry sit on top and never move. Below them, an interoperability abstraction layer speaks to swappable chain adapters (Ethereum, Polygon, or any provider network), which in turn touch the underlying blockchains. The result is 1:1 backed regulated deposit representation, cross-chain usability through provider-agnostic interoperability, capital efficiency across ecosystems, and an end-to-end auditable trail.
The detailed capability inventory behind this lifecycle is document 03.1, and the build sequence that delivers it is documents 03.5 and 03.6.
After issuance, DepositToken-CAD may trade within the regulated exchange environment. The design point investors should notice is the deliberate separation at the end of the chain: market execution logic and compliance authority are architecturally distinct, so the compliance authority remains independent of market execution at all times.
| STAGE | WHAT THE ARCHITECTURE DOES | POSTURE |
|---|---|---|
| Platform validation | Before any trade executes, the platform validates participant eligibility, jurisdictional restrictions, custody mappings, transfer restrictions, concentration limits, and market participation rules. Trades execute only after compliance approval succeeds | GATED |
| Order types | Limit, market, IOC (immediate-or-cancel), FOK (fill-or-kill), iceberg, and stop orders are supported in the exchange design | SUPPORTED |
| Matching engine | Deterministic price/time priority with partial-fill support and supervisory auditability built into the match path | DETERMINISTIC |
| Architectural separation | Market execution logic is separated from the compliance authority, which stays independent of execution | SEPARATED |
The net effect: secondary trading happens in a fully regulated exchange environment where eligibility, compliance, custody, and market controls are enforced at every stage, which is what fair, orderly, and auditable institutional markets require.
Settlement is treated as an embedded platform capability rather than an external service. The treasury and settlement workflow coordinates five things: cash-leg confirmation, token-leg confirmation, custody validation, reconciliation, and ledger commitment.
Settlement finality occurs only after treasury confirmation, custody confirmation, and canonical ledger commitment, together. Blockchain confirmation alone does not represent institutional finality.
The platform supports future bounded interoperability while preserving institutional governance. Cross-chain movement is treated as a supervised extension of the platform, not an independent bridge ecosystem, and broader omnichain interoperability is intentionally deferred until later operational phases.
Before any cross-chain operation occurs, the platform validates destination-chain eligibility, custody mappings, jurisdictional rules, transfer restrictions, and compliance policies. Depending on the interoperability design, source-chain tokens are either locked or burned, and destination representations are then wrapped, mirrored, or canonically reissued under platform governance.
| WHAT INTEROPERABILITY FRAMEWORKS NEVER BECOME | WHAT KCS RETAINS AUTHORITY OVER |
|---|---|
| The ledger of record | Reconciliation |
| The compliance authority | Ownership state and compliance enforcement |
| The settlement authority | Treasury governance and supervisory auditability |
That is the whole posture in one table. Providers move messages and value between approved chains. They do not get to define what is true, who may hold what, or when settlement is final.
Redemption runs the lifecycle backward, with the same gates. The investor initiates redemption; if assets exist on a secondary chain, wrapped or mirrored representations are first burned or reconciled; treasury then verifies ownership, validates payout instructions, burns the redeemed source-chain assets, and coordinates fiat payout through banking rails. The redemption lifecycle concludes only after treasury confirmation, banking confirmation, reconciliation, and the canonical ledger update.
| WHAT THIS PRESERVES | WHY IT MATTERS |
|---|---|
| Supply integrity | Redeemed assets are properly extinguished and total supply remains accurate, so the 1:1 backing claim stays true |
| Ownership traceability | A clear, complete record of ownership from issuance to redemption |
| Supervisory auditability | A transparent audit trail for regulators and internal oversight |
| Regulated payout governance | Fiat payouts execute under institutional and regulatory requirements, not protocol convenience |
The platform incorporates institutional operational controls in three groups, and together they define the operating environment for institutional digital asset lifecycle management.
| CORE OPERATIONAL CONTROLS | ARCHITECTURE SUPPORT | REGULATORY & INSTITUTIONAL ALIGNMENT |
|---|---|---|
| Reconciliation; settlement exception handling; custody verification; smart-contract governance; operational runbooks; incident escalation; audit evidence preservation | Immutable audit trails; deterministic replayability; regulator-facing reporting; supervisory traceability | Canadian securities expectations; FINTRAC obligations; institutional custody standards; regulated market infrastructure principles |
Two of these deserve a sentence each. Deterministic replayability means any disputed state can be reconstructed step by step from the record, which is what turns an audit from an argument into a lookup. And audit evidence preservation is listed as a control in its own right, because in a regulated venue the evidence is part of the product.
The tokenized bank-deposit workflow demonstrates the core strategic position of the platform: KCS owns and governs compliance, settlement orchestration, treasury coordination, issuer governance, token registry management, canonical ledger authority, and supervisory auditability. Everything else operates as a bounded integration domain under platform governance.
| KCS OWNS AND GOVERNS | BOUNDED INTEGRATION DOMAINS | RESULTING ARCHITECTURE SUPPORTS |
|---|---|---|
| Compliance; settlement orchestration; treasury coordination; issuer governance; token registry management; canonical ledger authority; supervisory auditability | Blockchain networks; interoperability providers; custodians; KYC vendors; banking rails; swappable interoperability-provider adapters | Regulated issuance; policy-controlled liquidity; institutional settlement discipline; bounded interoperability; supervisory auditability |
The middle column is the moat logic. Each external dependency operates as a bounded integration domain under platform governance rather than as an authoritative control environment, so any provider can be swapped without surrendering ownership of the regulated operational core. This is the same posture the room's competitive documents argue from; the head-to-head is Polymath Competitive Scope, document 02.5.
This room labels what is decided and what is not, and this document is no exception. The lifecycle mechanics above are designed. A set of product and policy definitions is deliberately unresolved, because they are legal and regulatory decisions to be made with counsel and regulators during the build, not engineering defaults to be assumed now.
| UNRESOLVED QUESTION | WHAT HAS TO BE DECIDED | STATUS |
|---|---|---|
| Legal wrapper & claim structure | Is the token holder's right against a bank, a custodian, an SPV, a trust, or some other vehicle | UNSPECIFIED |
| Instrument classification | Is the bank-deposit token an RWA claim, a tokenized security, a payment token, or a special class | UNSPECIFIED |
| Minting trigger | Minting against pre-funded reserve balances, only against investor subscriptions, or both | UNSPECIFIED |
| Redemption rights | On-demand, batched, windowed, or queue-based redemption | UNSPECIFIED |
| Fee schedule | Exact issuance, trading, custody, settlement, bridge, and redemption amounts | UNSPECIFIED |
| Bridge proof & dispute model | Light-client proofs, attestation, multisig, or other design; challenge windows and reversal rules | UNSPECIFIED |
| Destination-chain policy mirroring | How whitelist status, identity attestations, freezes, and jurisdiction flags transport and revalidate cross-chain | UNSPECIFIED |
| AMM / DeFi eligibility | Controlled AMMs and DeFi adapters are allowed for eligible tokenized instruments; whether a bank-deposit token qualifies is unspecified | UNSPECIFIED |
Source: KCS architecture working sessions, tokenized bank deposit use case (June 2026). The unresolved items above are design gates, not omissions; each is assigned to the regulatory and counsel workstreams tracked on the Path to Revenue page.
Prepared for approved data room members. This document does not constitute an offer to sell securities or a solicitation of an offer to buy securities. 4orm Finance Holdings Inc. is the parent entity of 4orm OpCo, 4ormEx OpCo, and 4orm Trust Co; technology is developed by KCS Capital, an independent research and development firm.