Native financial-market functions.
Bantu suits traditional banking because it provides financial-market functions natively rather than requiring a bank to construct all of its logic from general-purpose smart contracts. This chapter documents what that means for a commercial bank, for a central bank operating a two-tier currency model, and for a cross-border corridor.
Fourteen capabilities, none of them a contract.#
Bantu positions the protocol for commercial-bank stablecoins, payment service providers, trade-finance platforms, asset managers, government bonds and CBDC pilots. The following are protocol capabilities, available without deploying or auditing bespoke code.
- Native issuance of regulated assets
- Trustline-based account and asset controls
- Issuer authorization and revocation
- Freeze and clawback capability
- Multisignature treasury governance
- Atomic payments and multi-leg settlement
- Cross-asset conversion through path payments
- Built-in order-book liquidity
- Asset trading and market-making
- Real-time ledger auditability
- Account, signer, trustline and transaction history
- Sponsored wallet and trustline onboarding
- Conditional claimable balances
- API-based integration with banking, wallet, compliance and reporting systems
A two-tier model, with issuance retained.#
Bantu can support a two-tier central-bank model in which the central bank controls monetary issuance and policy while commercial banks, PSPs, national switches and regulated wallet providers distribute and service the currency.
- Issuance
- Monetary policy
- Allow-list
- Supply visibility
- Distribution
- Customer onboarding
- KYC / AML
- Servicing
- Payments
- Savings
- Merchant settlement
- Disbursements
- Issuance and redemption authority
- Participant allow-list
- Account-level freeze
- Clawback under legal instruction
- Real-time supply visibility
- Validator and quorum policy
Requirement to capability.#
Eleven central-bank requirements, and the Bantu mechanism that answers each.
Issuer accounts, separate distribution accounts, multisignature treasury
Trustlines plus authorization-required assets
Revocable authorization and account-level freezes
Optional clawback controls under disclosed policy
Weighted multisignature thresholds and separated keys
HFBA consensus with 3–5 second finality
Path payments and built-in order-book liquidity
Immutable ledger history, API-based reporting, account and asset visibility
Sponsored reserves and wallet-provider integration
Anchor and regulated financial-institution model
Atomic conversion and settlement between issued assets
Who operates the quorum.#
HFBA is non-mining and non-staking. Validators establish trust through declared quorum relationships rather than hash power or token ownership, and settlement becomes final after externalisation in approximately three to five seconds. For a domestic or regional payment network, validators could be operated by any of the following.
- Central bank
- National payment switch
- Commercial banks
- Securities depositories
- Licensed settlement institutions
- Government treasury
- Regional payment-system operators
- Designated technical infrastructure operators
One atomic flow, or nothing.#
Bantu is strong for cross-border settlement because it supports native multi-asset issuance, exchange and routing. A cross-border payment can use a path payment that debits the sender in one asset, routes through available order-book liquidity, converts, and credits the receiver in the required asset — settling at the acceptable rate or not settling at all.
- 01Debit the sender in one asset
- 02Route through order-book liquidity
- 03Convert at the quoted rate
- 04Credit the recipient
If the required exchange rate or liquidity is not available, the entire transaction fails. There is no partial settlement, no stranded leg, and no intermediate position to reconcile or fund.
- Multiple nostro and vostro accounts
- Manual reconciliation
- End-of-day batch settlement
- Correspondent-bank routing per corridor
- The hard-currency intermediary leg
What you can build on top.
Chapter 05 documents the programmable surface — the native operations that express financial workflows without general-purpose contract code, and the integration stack a production banking system would use.