Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Hyperledger can provide open-source ledger and interoperability components for central bank digital currency (CBDC) experiments, but it does not supply a complete currency or decide its policy. The cited examples range from adoption interest around Besu to FireFly interoperability testing and an Iroha proof of concept. None, on its own, establishes that a platform is production-ready or suitable for a particular central bank.
Start with the CBDC design, not the blockchain
A CBDC is a central-bank liability in digital form, but its architecture depends on the policy goal and payment environment. First decide whether the project targets retail payments used by the public or wholesale settlement among financial institutions, whether it is domestic or cross-border, and whether the immediate goal is a pilot or production service.
For a retail system, the Bank for International Settlements’ 17 December 2024 architecture proposal describes a hybrid model with enrollment, cash-in, cash-out, and transfers within the ledger. In such a model, the central bank and intermediaries can have different responsibilities. The exact division depends on the jurisdiction’s policy objectives, regulation, and existing infrastructure; a ledger choice cannot settle those questions. BIS, “A proposal for a retail central bank digital currency (CBDC) architecture”
- Enrollment: Determine who verifies users, issues credentials, and manages access.
- Cash-in and cash-out: Specify how funds move between commercial-bank or other payment balances and the CBDC, and which institutions perform those conversions.
- Transfers: Define how payments are authorized, recorded, and settled, including the roles of intermediaries and the central bank.
- Connections: Plan integration with banks, existing payment rails, and any other ledgers the system must reach.
These decisions also shape privacy, regulatory access, auditability, identity requirements, and governance of the operators who maintain the system.
#1 Best Overall
What the Hyperledger projects contribute
Hyperledger projects do not all perform the same job. Some are ledger technologies, while others focus on interoperability or identity-related capabilities. The distinction matters: an integration layer is not itself a CBDC, and evidence that a technology appeared in a sandbox does not prove it was the ledger for every network in that test.
| Project | Potential role in CBDC work | What the cited evidence establishes |
|---|---|---|
| Besu | EVM-compatible ledger option for permissioned-ledger experimentation. | Hyperledger’s 2024 Besu annual review reports adoption interest around CBDC pilots. In Swift’s Phase 2 sandbox, a simulated Digital Asset Network ran on Besu; that is distinct from the CBDC networks, which used other technologies. 2024 Besu annual review; Swift Phase 2 technologies report |
| Fabric | Permissioned blockchain option for ledger experimentation. | Swift’s Phase 2 technical report identifies Fabric among the technologies used in the interoperability sandbox. The cited material does not provide a like-for-like performance or privacy comparison. Swift Phase 2 technologies report |
| FireFly | Integration and orchestration across networks. | Hyperledger’s Q2 2024 report says FireFly facilitated interoperability in the Swift CBDC Phase 2 collaboration across networks running Besu, Fabric, and Corda. FireFly is not a currency or a central-bank policy layer. Hyperledger FireFly Q2 2024 report |
| Iroha | Ledger technology used in a documented CBDC-related proof of concept. | Hyperledger’s 2024 Iroha annual review describes a Bokolo-cash proof of concept involving the Central Bank of Solomon Islands and Soramitsu. The described scenarios included domestic and foreign payments and simulated international remittances; this is not evidence of an operational national currency. 2024 Iroha annual review |
| Indy / Indy Besu | Identity-oriented capabilities, rather than a standalone payment-ledger recommendation. | Hyperledger’s 2024 Indy annual review describes Indy Besu as a modular effort to implement Indy capabilities on Besu, including permissioning and validator management. The review also says the Indy SDK was deprecated, so check current project guidance before considering it as a starting point. 2024 Indy annual review |
What the CBDC sandbox figures mean
Hyperledger’s Q2 2024 FireFly report summarizes Swift CBDC Phase 2 interoperability tests involving 38 banks and seven simulated CBDC networks. Those figures describe a sandbox collaboration, not 38 live deployments or seven nationally issued currencies. The work is evidence that interoperability across multiple networks was tested, not proof that any particular platform is ready to issue a CBDC at national scale. Hyperledger FireFly Q2 2024 report
How to evaluate a platform for a CBDC
There is no universal “best blockchain” for a CBDC. Compare candidates against the intended service and the institutions responsible for operating it; the cited sources do not provide comparable benchmarks for throughput, cost, or security rankings.
- Governance and validator control: Identify who can operate validators, approve changes, admit participants, and resolve operational disputes.
- Privacy and access: Specify what counterparties, intermediaries, the central bank, and regulators can see. The BIS’s 2019 technology paper frames the enduring trade-off between privacy and law-enforcement access, but it is not a substitute for current jurisdiction-specific requirements. BIS, “The technology of retail central bank digital currency”
- Identity and onboarding: Define how users and institutions are identified and how permissions are managed. An identity-oriented component may support this work, but it does not replace the payment ledger or the policy framework.
- Interoperability: Map connections to banks, payment systems, and other ledgers. FireFly’s sandbox role is relevant to this integration question, but a sandbox result does not establish production readiness.
- Transaction and resilience requirements: Set jurisdiction-specific service, continuity, and recovery requirements, then test them under the expected operating model. The cited reports do not establish comparative performance figures.
- Smart-contract needs: Decide whether programmable transaction logic is required and how it will be governed, reviewed, and upgraded.
- Operations and maturity: Assess the project’s current maintenance status, upgrade responsibilities, available expertise, and the delivery team’s ability to support the system over time.
What the examples do—and do not—prove
The evidence is at different stages: Besu has reported CBDC-pilot adoption interest; FireFly featured in an interoperability sandbox; and Iroha was used in a proof of concept. These are useful signals for exploration, but they are not equivalent to production issuance. The cited 2024 reports do not establish that these examples are all in production today.
For a procurement or architecture decision, verify current project status and consult primary sources from the relevant central bank and technology project. The 2019 BIS technology paper can frame the choice between distributed-ledger and centrally controlled infrastructure, while the 2024 BIS proposal offers a more recent retail-process framework. Neither replaces a jurisdiction’s own policy, regulatory, and technical requirements.
Quick Recap
Best Value
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
