DemonstrationCommercial bank
Tokenized deposits with core-banking control, private settlement and policy-based access
A tokenized deposit platform, built to three banks’ RFPs. One run: 400K held in the core and issued on a private ledger, 120K transferred, 45K redeemed, supply reconciled. Privacy is Miden. Access is decided by policy.
1:1Backing, enforcedHeld in the core, not asserted by the platform
2Approvals per issuanceBound to bank staff identities
0Ledger credentials held by the platformEvery write carries a scoped permit
Per contractAuthorization granularityNot per method
3Bank RFPs answeredThe same control questions; 182 requirements in the set shown here
6Boundaries checkedEach one scripted against the live estate
A bank buying a tokenized deposit platform is buying control, not a ledger. Gateway built the platform that delivers it, specified against three banks’ RFPs rather than one. It connects a core banking system, a message bus and a staff directory to a deposit platform running on Miden, and the demonstration below runs that path end to end. The next institution is a matter of configuration, not another build. There is no customer deployment behind it yet.
Controls
The controls the RFP asked about
01
The money cannot be promised twice
- Issuance places a hold in the bank’s own core system, not in the platform.
- The customer’s balance is unchanged; the available amount falls to zero.
- A withdrawal against the held amount is refused at the branch terminal.
- The hold lifts only in proportion to what has been redeemed.
02
Two approvals, bound to bank identities
- Issuance requires a maker and a checker, resolved against the bank’s own staff directory.
- The maker is refused approval of her own instruction — enforced on the identity, not the browser session.
- The platform holds no ledger credential; each write carries a permit bound to one operation.
- A valid bank session with no entitlements can reach nothing at all.
03
Authorization per contract, not per method
- Grants are authored by an administrator in Open Privacy Suite, not in application code.
- A treasurer holding a read permission is refused another customer’s contract while holding that same permission.
- Each registered contract carries the groups that may reach it; one with no group is reachable by nobody.
- Registration and readability are separate properties: being in the register does not confer sight.
04
Private state, disclosed only under authority
- Corporate account balances are not present in the public index — the ledger holds a commitment.
- A supervisor asking without a grant is refused, holding the role that lets them ask.
- Disclosure is requested with a reason and a legal basis, approved by name, and carries an expiry.
- Revocation closes the window; the supervisor keeps a digest of what they were shown.
Access
What each caller may reach
CallerRequestOutcome
TreasurerTheir own company’s accountReturned
TreasurerAnother customer’s account, same permission heldRefused
Bank staff, no entitlementsAny platform functionRefused
SupervisorA deposit, before a grant existsRefused
SupervisorThe same deposit, under an approved grantReturned, with expiry
SupervisorThe same deposit, after revocationRefused
Each row is decided at request time by policy an administrator authored, not by application code.
Orchestration
One contract, where a bank would otherwise sign four
What the bank needsBought separatelyDelivered here
A ledger that keeps balances privateA ledger vendor, evaluated on cryptography the bank cannot easily assessMiden private accounts, integrated and demonstrated
Access control fine enough for a supervisorA policy product, and an integration project to put it in the request pathOpen Privacy Suite, already in the path
Sign-in against the bank’s own staff directoryAn identity integration, scoped and billed on its ownThe same policy layer, reading the bank’s directory
Core banking and message bus integrationA systems integrator, and a seam nobody owns end to endGateway orchestration, which is the part that carries the instruction
Evidence a supervisor and an auditor will acceptAssembled after the fact from whatever each vendor loggedReconciliation read from the ledger, and every decision recorded as it is made
Four procurements, four contracts and four defences of the same seam become one. The seams are where these programmes stall, and they are the part a bank cannot buy from a component vendor.
Architecture
Three tiers, and what each part provides
Gateway platformDelivered by Gateway, on Miden
Open Privacy Suite
Orchestration
Permissioned explorer
Miden networkMiden
Private accountsMiden
Policy decisions and scoped permits ↓ · ledger reads ↑
Deposit platformThe RFP answer, running on the platform above
Issuance, maker / checker
Treasury portal
Reconciliation
ISO 20022 messages ↑ · holds, releases and settlement ↓
Bank estateThe customer’s own systems, integrated with rather than replaced
Core banking
Integration bus
Staff directory
Branch terminal
Gateway built the deposit platform and the orchestration. Miden supplies the ledger and its private state. Bank is the institution’s own estate. It is integrated with, not replaced. Who runs each tier in a pilot is agreed per engagement.
- Gateway delivered every part of this estate except the bank’s own systems, using Miden components for the ledger and its private state.
- Three tiers, deployed separately: the product, the tenant platform that runs on it, and the bank being integrated with.
- The product starts on its own — neither the tenant nor the bank estate needs to be present.
- Orchestration carries every instruction through policy to the ledger, holding no standing credential for either.
- Identity is the bank’s own: Open Privacy Suite integrates the staff directory every console signs in against.
What each part provides
Miden
Operator privacyMiden components, integrated by Gateway- Accounts are private: the ledger holds a commitment, not balances, holdings or contract state.
- The operator co-signs every movement and can enumerate holders on request, which prudential treatment requires.
- Other participants on the same network see neither amounts nor holdings.
- The transaction graph remains visible; the measured limits are stated below.
Open Privacy Suite
Granular access control and identityGateway product- Grants are authored by an administrator, not compiled into the application.
- Authorization is per contract, not only per method: holding a permission does not grant sight of every contract.
- The bank’s own identity provider is integrated here, so every console signs in against the staff directory the bank already runs.
- Supervisory disclosure is a grant like any other: requested with a reason, approved by name, expiring, revocable.
Gateway orchestration
Integration between the twoBuilt by Gateway for this engagement- Carries the tenant’s instructions through policy to the ledger; no route bypasses the decision.
- Mints a permit scoped to a single operation, so an instruction cannot be replayed or widened.
- Holds no standing ledger credential of its own, and no access to the bank’s core database.
- Reconciles by reading the ledger rather than its own database.
The RFPs
Three banks asked the same five questions
- What stops the same deposit backing both a token and a withdrawal?
- Who approves an issuance, and can one person do it alone?
- What can the vendor reach on its own authority?
- What is a supervisor shown, and who authorises it?
- What can other participants on a shared ledger see?
AreaSelected requirementsWhat the demonstration shows
ArchitectureSeparate the source, control and settlement layersThree tiers, each with its own deployment and its own proof; the product imports nothing from the tiers above it
IntegrationIntegrate with the core banking system and the institution’s message busISO 20022 camt.054 leaves the core, crosses the bus, and arrives at the platform — which never touches the core’s database
IntegrationExtracts proving token supply matches the core ledger one to oneThe core’s own liability figure compared against supply read from the ledger, end to end
IntegrationIdempotency and duplicate prevention on submission and replaySingle-use permits per operation; at-least-once delivery met with idempotent observation
PermissioningRestrict which identities may transact, administered as policy rather than codeGroup grants in Open Privacy Suite decide every call, authored by an administrator
PermissioningRole granularity and separation of dutiesSeven roles with distinct grants; maker and checker cannot be the same person
PermissioningNegative tests proving the unauthorized cannot actA refused call at the gate, with evidence the ledger never received it
ReliabilityReconcile authoritative totalsDouble-entry core, trial balance asserted at zero, liability compared against supply
Selected requirements, restated in our own words: eight of the 182 in the one set we can describe. Neither the institution nor any wording from its RFP is reproduced.
Checked end to end
- The deposit is booked as double entry and reaches the platform only as a message.
- Issuance requires two named officers, and the maker cannot approve her own instruction.
- The funds block holds in the core, and a withdrawal against it is refused.
- A claim is issued, transferred, redeemed in parts, and settled to whoever holds it.
- A caller is refused another customer’s account while holding the same permission.
- A supervisor is refused, granted under an approval, and refused again on revocation.
One run, in order
A deposit through the whole lifecycle
Every screen below was captured from one run of the estate: a 400,000.00 deposit booked at the branch, tokenized in full, 120,000.00 paid to a second customer, 45,000.00 brought back.
1 · The deposit is bookedA teller posts the entry in the bank’s own core. Two legs, and the trial balance stays at zero. 
2 · It reaches the platform as a messagecamt.054 is written to the outbox, collected by the integration fabric, published to a topic and observed by the platform. One correlation identifier joins every hop; the platform never reads the bank’s database. 
3 · The platform sees a deposit it may tokenizeMarked available because it is a credit that has not been tokenized. The platform learned of it by message, not by query. 
4 · Two people, then the ledgerRaised by one bank subject and decided by another — the maker cannot approve her own instruction. The only “done” is a transaction reference. 
5 · The record names both peopleRaised, approved and settled, each against the bank identity that performed it. 
6 · The money is held, not movedThe balance stays on the bank’s books. What falls to zero is the amount the customer can draw. The second account shows what a redemption paid out. 
7 · The claim moves between customers120,000.00 has gone to another company. The bank’s books did not move: the whole 400,000.00 is still held. 
8 · Whoever holds it can bring it backThe recipient redeemed 45,000.00 of what it was paid, and the bank released that much to the recipient’s own account — not to the original depositor. 
9 · The books agree, on the ledger’s evidenceSupply is read from the ledger and compared with what the bank holds. The platform’s own record is shown beside both, and is not the evidence.
Operator privacy
The chain records that it happened, not what happened
The issuance, on the public explorerThe transaction that put 400,000.00 into issue. The explorer has its identifier, its account and its block. It does not have the amount, because the chain never held it. 
The account behind itType: private. State: a commitment. There is no balance field to redact — the node never received one. 
The same page, signed in and entitled280,000.00 and 75,000.00 against a public faucet supply of 355,000.00. The balances are read live from the Guardian and are not written into the explorer’s index.
The balances are private and the supply is public, so the arrangement is checkable without being readable. Miden supplies the account privacy; the disclosure above it is decided by policy.
Identity and access
The bank decides who you are; policy decides what you reach
Every console signs in at the bankThe platform issues no sessions of its own. It sends the browser to the bank’s identity provider and receives a subject back, as any other application in the estate would. 
Groups carry methods, authored not compiledCompliance officers carry nine methods, a corporate treasury fifteen. An administrator sets that; none of it is a constant in the application. 
And each contract grants groups backThe register holds on-chain contracts, by address. A group that carries a method still reaches only the contracts that name it, and a contract naming no group is reachable by nobody. 
A refusal names the grantThe same page, a different identity. Signed in is not entitled, and the answer says which grant was missing rather than returning an empty result.
Outcome
What the demonstration establishes
- The bank cannot promise the same money twice: the hold lives in the core, and a withdrawal against it is refused.
- Redemption pays whoever holds the claim, in parts, with the hold lifting by exactly that amount.
- Reconciliation reads supply from the ledger and reports “unknown” rather than a false green when it cannot.
- Every refusal on the page is a live decision by an authored policy, not a screenshot.
- One build answers three requirement sets. A fourth institution changes configuration, not code.
Confidential RFP evidence is available under NDA
The bank’s RFP, our written answers to it, and the evidence this page leaves out are all confidential. Sign an NDA and we will show you the three of them. Then we scope a bounded pilot: what it would take, and what it would prove.
Evidence boundary
- This is a demonstration. There is no customer deployment behind it and no production reference.
- All three RFPs are confidential. The requirements shown are a selection from the one set we can describe at all.
- The bank estate is a clean-room simulation written for this build: no vendor code, no vendor data, no customer data.
- Both settlement orders leave a one-sided state, with no owner and no repair queue yet.
- Value has not been moved between two separate institutions. Both customers bank in the same simulated estate.
- Amounts and balances are private; the counterparty graph and per-redemption amounts are not.
- Throughput, latency and failover were not measured. This is one functional run, not a performance test.
- Reversals, disputes and sanctions holds were out of scope, as was the legal structure of the claim.