CASE-01 · tier-1 international bank · prior individual engagement
Multi-currency stablecoin tokenization on a private network
A governed, code-defined platform for issuing stablecoins in more than twenty currencies on the bank's own permissioned network, with institutional key management.
This case reflects work delivered by Squad B's founder in a prior individual engagement. The client is not named.
// challenge
What made it hard
- 01
Many currencies, one platform. Every new currency had to be a configuration step, not a new project.
- 02
Governed environments. Development, test and production had to be reproducible and pass the bank's change controls.
- 03
Institutional key management. Signing keys could not live in application code or pipelines.
// architecture
Layered, and defined in code
// key decisions
What we chose, and why
QBFT on a permissioned Besu network
Immediate finality and a known validator set suit settlement-grade issuance better than probabilistic finality.
Modular IaC with per-environment toggles
One codebase from dev to production; each layer switched on only where it is needed.
Platform asset services over custom code
Using the platform's asset, wallet and workflow services leaves less bespoke code for the bank to own and certify.
Governed secret stores, remote signing
No credentials in repositories or pipeline definitions; signing isolated behind an HSM.
// stack
- platform
- Kaleido
- network
- Hyperledger Besu · QBFT
- middleware
- Hyperledger FireFly
- asset services
- Asset · wallet manager · ERC-20 indexer · workflows
- keys
- HSM remote signer
- iac
- Terraform
- ci/cd
- Azure DevOps
// lessons for your programme
Treat environments as code from day one. Retrofitting it after a pilot costs more than building it in.
Design key management before contracts. Signing architecture shapes everything above it.
Plan the operating model, not just the deployment. Who approves, who monitors and who recovers decides when production happens.