CBDC - Project Garuda

Proof of Concept (PoC) Report
Wholesale Rupiah Digital

Cash Ledger
December 2024
Project Garuda: Proof of Concept (PoC) Report
Wholesale Rupiah Digital Cash Ledger
BANK INDONESIA
Jalan M.H. Thamrin No.2
Jakarta - 10350
Indonesia
This publication is available at Bank Indonesia website (www.bi.go.id).

Jakarta, December 2024
© Bank Indonesia 2024. All rights reserved.
Design and Layout by Setyo Kuncoro, Bagas Aji Pratama, Kevin Eza Rizky,
Timothy Thamrin Andrew H. Sihombing, Sirria Panah Alam, Dewi Septina Br Pelawi,
Bijak Antusias Sufi, Faradilla Azranur, Dian Nofitri, Annisa Muzdalifa
Contents i
Figures iii
I Preface Governor of Bank Indonesia v
II Preface Deputy Governor of Bank Indonesia vi
III Preface Deputy Governor of Bank Indonesia vii
Executive Summary 1
1 Overview
1.1. Background
2
2
1.2. Objective 4
1.3. Business Model 5
2 PoC Methodology 6
2.1. PoC Stages 6
2.2. PoC Scenario 6
2.3. Scope and Assumptions 6
3 PoC Development
3.1 Use Case Layer
8
8
3.1.1 Money Supply Process 8
3.1.1.1 Issuance 8
3.1.1.2 Redemption 9
3.1.1.3 Fund Transfer 10
3.1.2 System Policy 11
3.1.2.1 Limit Feature 11
3.1.2.2 Administrative Features 11
3.1.3 Supervision 12
3.2. Digital Asset Layer
3.3. Execution Layer
12
12 Contents
3.3.1. Container 13
3.3.2. Smart Contract 13
3.3.3. Application Programming Interface (API) 13
3.3.4. Web Application (Web App) 13
3.3.5. Messaging 13
3.3.6. Integration, Interoperability, and
InterConnection (3i) 14
3.4. Data Layer 14
3.4.1. Storage in the Database 14
3.4.2. Structure of DLT 15
3.5. Consensus Layer 15
3.6. Network Layer 15
3.7. Security Aspects 16
4 PoC Testing & Result 17
4.1. Implementation of DLT in Money Supply Process of
Wholesale Rupiah Digital 17
4.2. Implementation of Smart Contract on Rupiah Digital
Wholesale Platform 18
4.3. Integration, Interoperability and Interconnection of
wRD with Other Financial Market Infrastructure 19
5 Finding and Next Step 20
5.1 Finding 20
5.2 Next Step 20
Abbreviations 21
Appendix A. Detail Evaluation of DLT 22
B. Implementation Details of the Use Case Layer 24
C. Implementation Details of the Execution Layer 26
D. Implementation Details of the Data Layer 31
E. Implementation Details of the Consensus Layer 33
F. Implementation Details of the Network Layer 35
G. Liquidity Management and Privacy Concepts for
Advanced Exploration 36
H. PoC Scenario Topics 38
I. Load Test 39
List of Authors 42
Contents
Figure 1. Three Goals of the Rupiah Digital 2
Figure 2. Project Garuda Stages 3
Figure 3. Project Garuda Activities 4
Figure 4. wRD Membership Registration 5
Figure 5. Money Supply Process at wRD 5
Figure 6. wRD PoC Configuration 7
Figure 7. wRD PoC Architecture 7
Figure 8. Issuance and Redemption wRD Platform Integrated
with BI-RTGS 8
Figure 9. (a) RTGS Triggered Issuance Process
(b) Platform Triggered Issuance Process 9
Figure 10. Redemption Flow Platform Triggered 10
Figure 11. Fund Transfer Process with Queue Mechanism 10
Figure 12. Observer Node Solution 12
Figure 13. Web App View on R3 Corda Solution 14
Figure 14. Web App View on Kaleido Hyperledger Besu Solution 14
Figure 15. Design of Data Layer on R3 Corda 15
Figure 16. The Process of Identifying New Members in
the Network
(a) In the Implementation of R3 Corda;
(b) In the Implementation of Kaleido Hyperledger Besu 16
Figure 17. Creation on R3 Corda UTXO 24
Figure 18. Creation on Kaleido Hyperledger Besu Account Based 24
Figure 19. Destruction on R3 Corda UTXO
Figure 20. Destruction on Kaleido Hyperledger Besu
24
24
Figures
Figure 21. Redemption Process RTGS Triggered 25
Figure 22. Bank Indonesia’s R3 Corda Cluster Configuration
on AWS Infrastructure 26
Figure 23. Participant’s R3 Corda Cluster Configuration
Figure 24. Kaleido Hyperledger Besu Cluster Configuration
of Bank Indonesia’s and Participant’s Node
Figure 25. CordApp Component 28
Figure 26. Rupiah Digital and Digital Securities Illustration at
Wholesale Wallets R3 Corda 28
Figure 27. Firefly Event Bus (Hyperledger Firefly, 2024) 29
Figure 28. R3 Corda Based PoC Solution Design:
BI-RTGS Integration 30
Figure 29. Database Design on R3 Corda 31
Figure 30.Database Design on Kaleido Hyperledger Besu 31
Figure 31. Directed Acyclic Graph on R3 Corda 31
Figure 32. Kaleido’s Asset Platform Digital Data Layer
(Kaleido, 2024) 31
Figure 33.Blockchain on Kaleido Hyperledger Besu 32
Figure 34. Consensus Mechanism in R3 Corda 33
Figure 35.Consensus Mechanism in Kaleido Hyperledger Besu 33
Figure 36.Illustration of the Use of CENM (Corda, 2024) 35
Figure 37. Queue Management Flow for Further Exploration 36
Figure 38. Kaleido’s Privacy Model Concept for Further Exploration 37
Figure 39. R3 Corda Infrastructure on AWS for Wholesale
Participant Clusters 39
Figure 40. Kaleido Hyperledger Besu Infrastructure on AWS for
Wholesale Participant Clusters 40
Figures
PREFACE
Governor of Bank Indonesia
Assalamu’alaikum Warahmatullahi Wabarakatuh,
Greetings to all of us, Shalom, Om swastiastu, Namo buddhaya, Greetings of virtue.
Currently, Bank Indonesia through the Project Garuda has completed the first phase of the Rupiah
Digital exploration journey, known as the Immediate State, which is marked by the completion of the
proof of concept wholesale cash ledger Rupiah Digital. This achievement is a manifestation of Bank
Indonesia’s commitment to the development of the Rupiah Digital in response to the rapid growth of
the digital financial economy and in its position as the sole authority in issuing legal currency in the
Republic of Indonesia.
The development of the Rupiah Digital is carried out by prioritizing the public interest while carrying
out the mandate of the effectiveness of the implementation of Bank Indonesia’s duties. This makes the
Rupiah Digital critical to complement the digitalization of the payment system, especially in supporting
the development of an increasingly decentralized digital financial economy in the future. The Rupiah
Digital is also directed to be integrated, interoperable, and interconnected with the current payment
system and financial market infrastructure, both domestically and cross-border.
The proof of concept stage of wholesale cash ledger Rupiah Digital is taken to ensure the use of the
right technology in meeting the design needs of the Rupiah Digital which has also considered various
views and public inputs. We see the proof of concept as an essential step to evaluate the feasibility
of the technology that will be the basis for the operationalization of the Rupiah Digital in the future,
including identifying potential risks. We hope that the proof of concept will not only serve as a means
of technical testing, but also as a tool to ensure the long term adoption and success of implementing
the Rupiah Digital in Indonesia.
The publication of this report is a manifestation of Bank Indonesia’s transparency in every stage of the
development of the Rupiah Digital. Bank Indonesia will continue to advance with the Project Garuda
initiative in responding to future payment system challenges. We hope that this project will have a
great impact and benefit the entire nation, especially in maintaining the sovereignty of the Rupiah in
the digital era.
Wassalamu’alaikum warahmatullahi wabarakatuh

Perry Warjiyo
Governor of Bank Indonesia
v Project Garuda: Proof of Concept Report | DECEMBER 2024

PREFACE
Deputy Governor of Bank Indonesia
Bank Indonesia, through the Project Garuda, has completed the proof of concept for Rupiah Digital
in the first phase of the wholesale cash ledger, known as the Immediate State. This proof of concept
is a strategic step in testing the feasibility of technology that supports the development of the Rupiah
Digital business model. The testing was done comprehensively, covering critical technical aspects,
transaction security, and interoperability with existing payment systems and financial infrastructure.
The proof of concept design, deeply focused on these three aspects, aiming to ensure that the
developed system can deliver efficient, secure, and reliable services.
Each stage of the technology testing is a crucial element in the process of enriching ideas, exploring
innovation, and validating previously formulated concepts. This testing was conducted using 2 (two)
potential technology platforms based on distributed ledger technology (DLT), which underwent
thorough technical evaluations and were aligned with the projected needs of the Rupiah Digital
business model in the future. The results of the testing show that both technology platforms have
different characteristics and advantages, especially in terms of resilience, privacy, speed, scalability,
and fault tolerance. The overall results of the proof of concept were able to meet all test scenarios and
prove that distributed ledger technology-based solutions can meet the business and technical needs of
the wholesale Rupiah Digital cash ledger.
This initial phase of the proof of concept marks an important milestone in the development of the
Rupiah Digital. The success and various insights from this proof of concept will form the foundation for
strengthening the business and technical aspects of the Rupiah Digital in the future.
Moving forward, we are committed to continuing the exploration of the Rupiah Digital through the
Intermediate State phase in Project Garuda. We hope that the exploration of the Rupiah Digital can
support Bank Indonesia’s efforts to maintain the sovereignty of the Rupiah and provide an innovative
and inclusive solution to address various challenges arising from the development of digital economy
and finance in the future.

Juda Agung
Project Garuda: Proof of Concept Report | DECEMBER 2024 vi

PREFACE
The Rupiah Digital, as one of the five initiatives (4 I + 1 RD) in the Indonesia Payment System Blueprint
2030, is currently being explored under the Project Garuda. Each stage of the Project Garuda is carried
out through an ongoing iterative process, starting from design drafting to testing the technological
feasibility through proof of concept. Bank Indonesia has received various constructive public inputs
regarding the design of the wholesale Rupiah Digital cash ledger, which will be tested in the proof of
concept.
Collaboration with the public is a key element in the development of the Rupiah Digital. We have
conducted a series of consultations and received valuable input from industry, associations, ministries/
institutions, academics, and the community. The results of the consultative paper that we received until
July 15, 2023, provide in-depth insights and become constructive inputs in improving the design of
the Rupiah Digital. Active participation of various stakeholders enriches the development process and
ensures that the resulting Rupiah Digital meets the needs and expectations of all stakeholders.
Proof of concept for the wholesale Rupiah Digital cash ledger is focused on testing the business
model, particularly related to the processes of issuance, redemption, and fund transfer. We explore a
range of use case scenarios and the potential economic benefits that could be gained. This approach
ensures that the proposed business model is not only financially sustainable but also adds value to all
stakeholders, including banks, financial institutions, and the public.
Overall, this proof of concept plays a crucial role in laying a strong foundation for the Indonesia
Payment System Blueprint 2030 initiative, which aims to further integrate digital payment systems into
the national economy, facilitate financial inclusion, and promote sustainable economic growth. The
proof of concept report is one of the milestones in the early development of the Rupiah Digital, part of
the Indonesia Payment System Blueprint 2030’s efforts to provide a secure, efficient, and responsive
payment solution that meets the needs and expectations of all stakeholders in the digital era.
The involvement and contributions of various stakeholders are key elements
in enriching insights to design a Rupiah Digital that best fits the needs of
Indonesia’s industry and society. Therefore, Bank Indonesia is committed
to continuously engaging the public in every iteration of the Rupiah
Digital’s development.
"Innovation thrives when people come together and collaborate."
— Chris Anderson

Filianingsih Hendarta
Deputi Gubernur Bank Indonesia
vii Project Garuda: Proof of Concept Report | DECEMBER 2024

EXECUTIVE
SUMMARY
Central bank digital currency answering 3 (three) key

(CBDC) is one of the potential uses questions (KQ):
of distributed ledger technology (DLT)
by central banks, which combines the 1 How can distributed
ledger technology be
capabilities of distributed ledger technology
leveraged to implement the
with the central bank’s mandate to issue fiat
wRD business model?
currency. Bank Indonesia is striving to explore the
Rupiah Digital as a form of Indonesia’s CBDC through 2 What are the potential benefits and added
the Project Garuda. value of integrating smart contracts into
wRD?
The White Paper “Project Garuda: Navigating the
Rupiah Digital Architecture” divides the exploration 3 How can wRD connect to conventional systems,
of the Rupiah Digital into 3 (three) stages: Immediate Bank Indonesia’s internal systems, cross-border
State, Intermediate State, and End State. This proof transactions, and other distributed ledger
of concept (PoC) report is part of the Immediate technologies, in alignment with the principles of
State, focusing on the exploration of the wholesale integration, interoperability, and interconnection
Rupiah Digital (wRD) Cash Ledger.3 (three) business (3i)?
processes were tested: issuance, redemption, and
fund transfer. Both platforms successfully developed all scenarios
according to the characteristics of their respective
This proof of concept report is a continuation of the technologies. Corda uses a consensus mechanism
Project Garuda’s activities. The design and business where a central party validates transactions (“notary”)
model tested in the proof of concept were established and transaction data is stored in a connected
through previous phases of the Project Garuda, manner from one transaction to another (“directed
including public consultations via the “Consultative acyclic graph”). Hyperledger Besu uses a consensus
Paper of the Project Garuda Wholesale Rupiah Digital mechanism where transaction validation is carried
Cash Ledger” and the outcomes of these consultations out by several predetermined validators (“proof-
in the “Public Consultation Report.” of-authority”), and transaction data is stored in
The design and business model, resulting from public interconnected transaction blocks (“blockchain”).
consultations, will be developed and tested using Both platforms were able to meet all testing scenarios
2 (two) distributed ledger technology platforms, and address all key questions. First, distributed ledger
namely Corda and Hyperledger Besu. To ensure technology can effectively support the implementation
the sustainability of the solution, the development of a wholesale Rupiah Digital cash ledger. Second,
was conducted by the principal developers of each smart contracts offer added value in terms of flexibility
technology: Corda, developed by R3, and for the Rupiah Digital development and transaction
Hyperledger Besu, developed by Kaleido. efficiency. Third, distributed ledger technology can
In addition to detailing the 3 (three) business connect with conventional systems using existing
processes, technical evaluations were conducted on standards and with other systems using the ISO 20022
both platforms, focusing on resilience, privacy, standard.
and performance aspects of each distributed The PoC results indicate that there are potential areas
ledger technology. These evaluations were that can be further explored regarding privacy, liquidity
carried out through 55 test scenarios aimed at management, and multi-validator deployment.
Project Garuda: Proof of Concept Report | DECEMBER 2024 1

CHAPTER 1
OVERVIEW
The proof of concept (PoC) Report for wRD is a follow-up to the Project Garuda, aiming to
identify the most suitable technology solutions according to the needs and characteristics
of Indonesia’s payment ecosystem. The exploration of these needs and characteristics was
previously conducted through the publication of a White Paper,
a Consultative Paper, and a Public Consultation Report.
1.1. BACKGROUND The Rupiah Digital’s potential to strengthen

Indonesia’s payment ecosystem depends on
Technological advances are driving innovation achieving 3 (three) goals, as illustrated in
in the payment ecosystem through distributed Figure 1:
ledger technology (DLT) 1 . Central banks 1. Becoming a legal digital payment instrument in
worldwide recognize the potential of DLT and are the Republic of Indonesia;
actively exploring its applications. One significant
2. Supporting Bank Indonesia’s objectives in
potential use of DLT by central banks is the creation
monetary policy, Financial System Stability
of central bank digital currency (CBDC), which
(SSK), and Payment System (SP) sectors in the
leverages DLT to fulfill the central banks mandate to
digital era; and
issue fiat currency.
3. Increasing the inclusion, innovation, and
While central banks share similar views on the efficiency of the financial system.
potential of CBDC, their specific objectives vary.
Some central banks regard CBDC as a means to Bank Indonesia is exploring the Rupiah Digital to
maintain relevance amid the steady decline in cash achieve these goals through the Project Garuda
usage or as a strategy to enhance financial inclusion. initiative.
CBDC could bolster Indonesia’s existing The Project Garuda is an initiative by Bank
payment ecosystem. Indonesia to explore a digital version of the
Rupiah, complementing existing paper and
Figure 1. Three Goals of the Rupiah Digital
1. Distributed ledger technology is a database distributed across multiple locations or institutions and is typically public. One well-known form of DLT implementation
is ‘Blockchain’.
2 Project Garuda: Proof of Concept Report | DECEMBER 2024
Figure 2. Project Garuda Stages
coin forms used so far. This exploration aims to cross-border transactions. Each stage prioritizes the
preserve the Rupiah’s sovereignty in the digital era, sustainability of the money supply process, aligning
in accordance with Act No. 4 of 2023 concerning with Bank Indonesia’s policies.
Financial Sector Development and Strengthening
At each stage of the Rupiah Digital project,
(P2SK), specifically section six titled ‘Rupiah Digital’.
3 (three) series of activities were conducted,
Similar to how banknotes in different countries as illustrated in Figure 3. The first activity is the
feature distinct designs and security elements, publication of the Consultative Paper (CP), which
the Rupiah Digital’s design must be tailored to serves as a form of communication and public
the Indonesian payment ecosystem’s needs and consultation to gather input on the business model
characteristics. At the end of 2023, Bank Indonesia at each stage. The second activity involves issuing
began exploring the design, impact, and benefits of a Public Consultation Report, summarizing the
the Rupiah Digital for Indonesia. The findings from public input that will be tested. The third activity
these explorations were subsequently published in 3 is the implementation of a proof of concept (PoC)
(three) documents: the White Paper, the Consultative to evaluate the feasibility of technology solutions
Paper, and the Public Consultation Report. based on the business model outlined in the Public
Consultation Report. These activities ensured that
The White Paper published in November 2023
the Rupiah Digital was developed with an optimal
outlines the exploration of the Rupiah Digital in
design.
3 (three) stages, as depicted in Figure 2. The first
stage is the Immediate State that involves exploring This proof of concept (PoC) report continues
a cash ledger wholesale Rupiah Digital. The second the Rupiah Digital’s exploration of technological
stage is the Intermediate State, which expands the solutions for the Rupiah Digital wholesale cash
wholesale Rupiah Digital use case to include Digital ledger (wRD) business model. The high-level
Assets. The third stage is the End State, which design of wRD is outlined in the Project Garuda
examines interconnection with other DLTs, including White Paper, the Consultative Paper published

Figure 3. Project Garuda Activities
in January 2023, which included public input on 1.2. OBJECTIVE

the design of the cash ledger, and the Public
Consultation Report published in October 2023. The primary objective of the PoC is to identify
These documents also define the business model, the most suitable solution for the wRD platform.
including the design of the money supply process Based on the evaluation results (see Apendix A), 2
and the arrangement of wRD membership. (two) potential DLT platforms have been identified
The wRD money supply process tested in the for further exploration: Corda2 and Hyperledger
PoC encompasses issuance, fund transfer, Besu3 . The development of both platforms during
and redemption. In the Immediate State, these the PoC was supported by the respective principals,
processes did not create new monetary value (no R3 for Corda and Kaleido for Hyperledger Besu.
money creation), as they utilized the conversion Support from these principals will ensure the
of funds in reserve accounts for the issuance and sustainability of the solutions developed during the
redemption of the Rupiah Digital. Membership PoC. The solution in the PoC was developed by
arrangements defined the roles of wRD participants, the principal specifically to meet the needs of Bank
enabling the establishment of a distributed wRD Indonesia.
ecosystem by delegating transaction validation To address the primary objectives of the PoC, 3
authority to these participants. (three) key questions have been developed:
The Immediate State of the Rupiah Digital PoC
1
report is presented with the following structure:
How can DLT be leveraged to implement
1. Overview, this section includes the the wRD business model?
background, objectives, and business model of
wRD;
2
2. PoC Methodology, this section explains the What are the potential benefits and added
implementation of the PoC, including the value of implementing smart contracts on
stages, scenarios, scopes, and assumptions wRD?
used during the PoC;
3. PoC Development, this section describes the How can wRD connect to conventional
development of the wRD platform;
3
systems, Bank Indonesia’s internal
4. PoC Testing and Results, this section systems, cross-border systems, and
addresses the objectives of the PoC based on other DLTs, based on the principles
the test results; of integration, interoperability4 , and
interconnection (3i)?
5. Findings and Next Step, this section explains
the findings from the PoC results and outlines
future exploration plans.
2. A blockchain platform that shares transaction data only with the parties involved in the transaction. It is available in an open-source version and an enterprise
version called Corda Enterprise.
3. An open-source blockchain protocol and platform established by Linux Foundation. Hyperledger Besu is a Java-based Ethereum client. Hyperledger Besu adheres
to the specifications of the Enterprise Ethereum Alliance (EEA).
4. The ability of 2 (two) or more systems to exchange information or conduct transactions without middleware.

Figure 4. wRD Membership Registration
1.3. BUSINESS MODEL
wRD’s primary business model encompasses
its money supply process and membership
arrangements. The money supply process in ��
the Immediate State is conducted through the ��
- ��
conversion of current accounts (no-money creation).
Concurrently, the wRD membership structure is
designed to delegate transaction validation authority
to participants (node5). ��
– ��
��
Figure 4 outlines the membership arrangements
for wRD participants. Transaction validation
authority will be delegated to appointed participants
(wholesalers), who can act as validating nodes 6
alongside Bank Indonesia. Meanwhile,
��
– ��
non-wholesaler participants can become ��
non-validating nodes7 or no-nodes8 .
The White Paper illustrates the wRD money
supply process in Figure 5, detailing the cycle
and interconnectedness of the Rupiah Digital. facilitate this conversion. Unlike a traditional
This cycle begins with issuance and concludes treasury that stores money, KDR acts as a facilitator
with redemption through the conversion of current and does not hold the Rupiah Digital. Instead, KDR
accounts in BI-RTGS. will maintain a zero balance and solely distribute
money to participants. Participants possessing the
The Rupiah Digital Treasury, or Khazanah Digital Rupiah Digital can transact with other participants
Rupiah (KDR), owned by the central bank, will on the web platform.
Figure 5. Money Supply Process at wRD
5. A node is a representation of a participant or party in a DLT network.

6. Validating node: a participant authorized to manage/store wRD tokens and validate transactions (Public Consultation Report, Project Garuda, 2024).
7. Non-validating node: a participant authorized to manage/store wRD tokens (Public Consultation Report, Project Garuda, 2024).
8. No-node: a participant authorized to manage/store wRD tokens but does not have a node and only needs to provide a network connection to access
multitenancy services (Public Consultation Report, Project Garuda, 2024).

CHAPTER 2
poc METHODOLOGY
The PoC methodology outlines a systematic approach to achieving the objectives of the
PoC. It encompasses the stages, test scenarios, and scope necessary to ensure
comprehensive execution of every aspect of the PoC.
2.1. POC STAGES ,, wRD PoC involves Project Garuda Workstream,
,,
The wRD PoC is structured into 3 (three)
divided into 3 (three) stages: Pre PoC, Main PoC, and
stages to clearly define the scope, focus on
the objectives of each stage, and mitigate the Post PoC.
risks associated with PoC implementation. The
implementation of the wRD PoC involves the Project
Garuda Workstream (WS) 9 . The details of the 3 2.3. SCOPE AND ASSUMPTIONS
(three) stages are as follows:
To optimize time and resources, the scope of
1
Pre PoC developing and executing test scenarios has
been determined. In this PoC, the model and
This stage explores and transforms 3 configuration utilized are illustrated in Figure 6.
(three) key questions in this PoC into test The wRD platform is designed as a permissioned
scenarios. These activities are conducted network, with Bank Indonesia regulating the access
through workshops and requirements and roles of participants.
gathering sessions with stakeholders.
The wRD platform encompasses various roles
During this stage, Bank Indonesia
and permissions, including:
shortlisted 2 (two) technology platforms
based on its needs and considerations. 1. Master Node (Bank Indonesia)
2
Main PoC a. KDR Node: responsible for the creation,
issuance, redemption, and destruction of the
This stage focuses on building and Rupiah Digital.
executing test scenarios on both
b. Regulator Node: determines the rules and
technology platforms. Both platforms are
policies for managing the Rupiah Digital and
developed and tested in parallel using agile
oversees smart contract management (see
and iterative approaches.
Subchapter 3.3.2).
3
Post PoC c. Observer Node: collects and supervises all
This stage involves a detailed analysis of the transaction activity data on wRD without active
test results from the Main PoC stage, which participation in the transactions.
are then documented in a comprehensive d. Administrator Node: manages participant
report. access on the wRD platform.
e. Provider Node: supplies multitenant
2.2. POC SCENARIO infrastructure for participants who lack
infrastructure within the wRD network.
The 3 (three) critical questions of the PoC will
be addressed through 55 test scenarios (see 2. Node Participants (Members)
Appendix H). Building and executing these test
a. Validating Node (Full Node): engages
scenarios provides a solid foundation for answering
in transaction activities of the wRD and
key questions and gaining insights for the future
possesses the right to validate transactions.
development of the Rupiah Digital. The test
scenarios are divided into 2 (two) aspects: b. Non-Validating Node (Light Node): engages in
transaction activities of the wRD but lacks the
1. Business aspect (functional): focusing on “what”
right to validate transactions.
the system/platform should do;
c. No-Node (Multitenancy): participates in
2. Technical aspect (non-functional): focusing on
transaction activities of the wRD but does not
“how” the system/platform should perform its
have infrastructure within the wRD network.
functions.
9. Project Garuda is continuously managed by 3 (three) Workstreams (WS), each with a specific focus: WS1 (business), WS2 (technology), WS3 (regulation).

Figure 6. wRD PoC Configuration
Bank Indonesia Bank Indonesia Participant
KDR Node Validating Node

Validating the creation WSr A dan WSr C
KDR Administrator Observer Regulator Provider
and destruction of Rupiah Node Node Node Node Node Executing and validating
Digital transaction
Administrator Node Non-Validating Node

WSr B
Configuring the wRD WSr D
membership Smart Multi-Assets Executing transaction
Contract Cash Securities
Observer Node Ledger Ledger No-Node
Monitoring of wRD WSr E WSr D dan WSr E
transaction Executing transaction
without providing node
Regulator Node
The configuration of wRD WSr A Validating Validating WSr C
using Policies (Capping Node WSr A Node WSr C
and Smart Contract)
Provider Node
Non-Validating
Multi-tenancy services
Node WSr B
for participants
WSr B Membership
Given the complexity of the DLT system, the

concept of the layered architecture, as depicted
,, Bank Indonesia together with participant
in Figure 7, has been adopted to facilitate
,,
understanding, development, and maintenance. (wholesaler) of wRD platform will have different roles
In DLT, there are 6 (six) layers of abstraction and to support operational resilience of wRD platform.
1 (one) supporting aspect:
1. Use Case Layer: Describes the use cases of
applications built on top of the DLT platform; Figure 7. wRD PoC Architecture
2. Digital Asset Layer: Describes digital assets

developed on top of the DLT platform;
3. Execution Layer: Describes how the DLT
platform serves as an environment for
executing computer programs;
4. Data Layer: Describes how data is stored and
managed;
5. Consensus Layer: Describes how nodes
communicate to reach agreement on adding
transaction blocks to the ledger;
6. Network Layer: Describes how nodes connect,
the protocols used, and the connectivity
between nodes and their respective ledgers;
7. Security Aspect: Explains how security
is implemented in the DLT platform,
encompassing an aspect that is integral to all
6 (six) layers mentioned above.

CHAPTER 3
POC DEVELOPMENT
As outlined in the methodology section, the wRD technology architecture layer, which
consists of 6 (six) layers of abstraction and 1 (one) supporting aspect (security), was
developed in the implementation of PoC using 2 (two) DLT platforms, namely R3 Corda
dan Kaleido Hyperledger Besu version 24.3.0. Both DLT platforms have characteristics that
meet the objectives of the Rupiah Digital. R3 developed Corda using the Corda Enterprise
DLT platform version 4.10, while Kaleido developed Hyperledger Besu using a DLT platform
based on Hyperledger Besu.
3.1 USE CASE LAYER of the Rupiah Digital into BI-RTGS current
accounts. Through this conversion process, there
The use case layer is the uppermost layer of the is no addition/decrease in the amount of money
wRD platform, where users interact directly with in circulation so that in the PoC phase Immediate
the platform. The business process in wRD is built State there is no creation of new money value.
on the use case layer, which includes the money
supply process, system policy, and supervision. 3.1.1.1 ISSUANCE
Implementing the wRD business processes
involves smart contracts that allow various Issuance process can be initiated through the
business processes in the network to be carried out wRD platform (Platform Triggered) or BI-RTGS
automatically, minimizing human intervention. (RTGS Triggered). Both trigger types involve
the omnibus account10 on the BI-RTGS system
3.1.1 MONEY SUPPLY PROCESS to complete the settlement on the BI-RTGS side
and the KDR node on the wRD platform to make
The Rupiah Digital is designed with the settlements on the wRD side. Figure 9 illustrates
principle of no harm to monetary stability and the process of issuance carried out by Bank 1 using
financial system stability. The money supply both types of triggers.
process consists of issuance, redemption, and
transfer. As explained in Figure 8, issuance is carried On the BI-RTGS settlement, refer to
out through the conversion of current accounts in Figure 9 (a) RTGS triggered issuance; the
BI-RTGS into the Rupiah Digital while the process process begins with debiting the current
of redemption is carried out through the conversion account and crediting the omnibus account.
Figure 8. Issuance and Redemption wRD Platform Integrated with BI-RTGS
10. The account in BI-RTGS that holds all the participants’ funds converted into Rupiah Digital, therefore the giro balance in the omnibus account will be equal to the total Rupiah Digital in
circulation. In the omnibus account, all participants’ funds are pooled together.

Figure 9. (a) RTGS Triggered Issuance Process (b) Platform Triggered Issuance Process
Then, BI-RTGS sent MT202 along with MT910 to Settlement on the wRD side is also known
indicate that the settlement on the BI-RTGS side as the process of creating the Rupiah Digital
had been completed. Meanwhile, referring to Figure with the implementation according to each
9 (b) Platform triggered issuance, Bank 1 initiated technology (see Appendix B.2). On R3 Corda, the
the issuance of the Rupiah Digital through the wRD creation process will create a new Rupiah Digital
platform, which was carried out both when the token owned by participants. In contrast, in Kaleido
bank wanted to increase the stock of the Rupiah Hyperledger Besu, the creation process will add
Digital and when it occurred auto-issuance11. Next, a a balance of the Rupiah Digital to the accounts of
message is exchanged between the KDR node and participating banks through new token minting. R3
BI-RTGS using the MT202 standard format. Corda and Kaleido Hyperledger Besu validate the
creation of transactions through the consensus layer
(see Subchapter 3.5).
,, Issuance process can be initiated through the wRD
3.1.1.2 REDEMPTION
platform (Platform Triggered) or BI-RTGS (RTGS Redemption is done through the wRD platform
Triggered). Both trigger types involve the omnibus (platform triggered) 12 and initiated by the
participating banks to Bank Indonesia. The
,,
account on the BI-RTGS system to complete the
redemption process engages the omnibus account
settlement on the BI-RTGS side and the KDR node
BI-RTGS system to complete settlements on the BI-
on the wRD platform. RTGS side and the KDR node on the wRD platform
to make settlements on the wRD side. Figure 10
shows an example of the redemption process by
Bank 1.
11. Auto-issuance occurs when the balance at a participant’s bank falls below a threshold set by each bank.
12. Initiation of the redemption process from BI-RTGS was technically tested but could not be executed commercially due to regulations on the BI-RTGS side (see Appendix B.4).

Figure 10. Redemption Flow Platform Triggered
The bank can initiate redemption when it needs 2. A queue mechanism, especially for high
to reduce the Rupiah Digital stock and during priority transactions.
the auto-redemption13 process. Both begin with
sending a request to the KDR node, as shown in The transaction processing feature in the wRD
the Figure 10 (number 1). Furthermore, in process platform will be completed in real-time and gross if
number 2, messages are exchanged between the the sender has sufficient funds/liquidity and queued
KDR node and BI-RTGS using the standard MT if liquidity is insufficient.
format. Transaction processing features and queue
When BI-RTGS receives MT202, the settlement mechanisms will be facilitated through smart
(number 3) occurs on the BI-RTGS side, then contracts, as shown in Figure 11. An additional
when the process is completed (number 4), MT900 component outside the smart contract for the
(success) or MT296 (failed) is sent to the KDR queue mechanism was developed for each
node. Furthermore, the KDR node initiates the participant’s application. In contrast to issuance and
settlement on the wRD side, also called destruction redemption, which require KDR node for current
process, with the implementation according to each account conversion validation, fund transfers can
technology (see Appendix B.2). be validated by any validating node. Distribution of
validation allows fund transfer to no longer depend
On the destruction process in the R3 Corda on a central authority, which is made possible by
platform, the KDR node makes a transaction using consensus (see Subchapter 3.5).
that destroys the Rupiah Digital token. In
contrast, in Kaleido Hyperledger Besu, the KDR A decentralized queue mechanism in which
node redeems the Rupiah Digital, thus reducing participants are responsible for managing their
the account balance by sending it to the burn respective queues is expected to distribute the
address14 . The validation process of the transaction queue processing load on each node, making the
involves the consensus layer, which is explained decentralized queue process more resilient than the
in more detail in Subchapter 3.5. If the KDR node conventional system.
receives a failed message in MT296 format, then Figure 11. Fund Transfer Process with Queue Mechanism
the KDR node does not follow up on the redemption
request belonging to the participating bank.
3.1.1.3 FUND TRANSFER

The fund transfer process on the wRD platform
replicates the practices that apply to the current
wholesale payment system. Some of the features
of the wholesale payment system include:
1. Transaction processing occurring in real-time

and gross;
13. Auto-redemption occurs when the balance at a participant’s bank exceeds a threshold set by each bank.
14. Specific address used by Kaleido Hyperledger Besu to burn tokens is 0x000000000000000000000000000000000000.

The optimal queue solution for the R3 Corda 4. Transfer limit between participants, sets the
platform is a First In First Out (FIFO) queue. maximum value of the Rupiah Digital that can
In FIFO, transactions earlier in the queue are be transferred between participants;
processed first when the participant’s balance has
fulfilled the transaction. 5. Maximum participant balance, sets the
maximum balance that a participant can hold
Meanwhile, the optimal queue solution for at any given time;
the Kaleido Hyperledger Besu platform is a
First Available First Out (FAFO) queue, where 6. Minimum participant balance, sets the
transactions with sufficient balance are processed minimum balance that a participant must hold
first. at all times.
Besides decentralized queue, there are model The participant limit aims to manage the
options for queue centrality, which can be liquidity of each participant according to their
further explored (see Appendix G). A centralized needs. If the limit set by the participant is exceeded,
queue will manage the queue from all participants an automated conversion process (auto-issuance
by an entity, making it easier to resolve gridlock and auto-redemption) will be triggered. 2 (two)
problems, which causes a transaction not to be limits have been developed for participants:
completed between participants.
1. Maximum balance, regulates the maximum
balance each participant can hold, which
3.1.2 SYSTEM POLICY cannot exceed the maximum participant
balance set by Bank Indonesia.
The wRD platform must implement transaction and
The auto-redemption process will be initiated
activity management features to support central
automatically if this limit is exceeded.
bank policies. The limit feature regulates the Rupiah
Digital transactions, while the administration feature 2. Minimum balance, regulates the minimum
oversees participant activities. balance each participant must hold, which
cannot be lower than the minimum participant
3.1.2.1 LIMIT FEATURE balance set by Bank Indonesia. If this limit is
exceeded, the auto-issuance process will be
The limit on wRD is divided into 2 (two) initiated automatically.
categories based on the regulating party. The
first category is the limit set by Bank Indonesia, ,,
,,
which applies to all wRD participants. The second
category is the limit that each participant can set for The limit feature is parameterized to allow
themselves. adjustments as needed...
The limit feature is parameterized to allow

adjustments as needed. However, Bank Indonesia To avoid a continuous conversion process, the PoC
has not yet committed to implementing this feature; also includes a buffer value feature, which acts as an
its development is currently intended for testing additional value during the automated conversion
purposes only. process.
Bank Indonesia’s limit aims to regulate the In its implementation, R3 Corda and Kaleido
amount of the Rupiah Digital in circulation and Hyperledger Besu have incorporated the limits
prevent the concentration of the Rupiah Digital set by Bank Indonesia into smart contracts/
ownership among a few participants. Bank CorDapps. This approach ensures that the
Indonesia sets these limits through regulator node. limits set by Bank Indonesia are distributed and
6 (six) limits have been developed: checked by each participant. Meanwhile, the
limits set by participants are implemented within
1. Total circulation limit, regulates the total each participant’s application using R3 Corda and
amount of the Rupiah Digital that can be Kaleido Hyperledger Besu.
circulated at any given time;
2. Limit per issuance per participant, sets the 3.1.2.2 ADMINISTRATIVE FEATURES
maximum conversion value from a current
account to the Rupiah Digital that a participant The permissioned DLT network wRD platform
can perform; requires an administrative feature to manage
participant memberships. As a result, 4 (four)
3. Limit per redemption per participant, sets administrative features were developed for this
the maximum conversion value of the Rupiah purpose:
Digital to a current account that a participant
can perform; 1. On-boarding, allows Bank Indonesia to add
new participants to the wRD platform;
2. Freeze, Bank Indonesia to stop funds from specific features for supervision. This specific
entering and exiting participant nodes; node is the observer node, which receives a copy
of the transaction between participants, as shown
3. Unfreeze, allows Bank Indonesia to revoke the
in Figure 12. The observer node can only be owned
frozen status of participants;
and operated by Bank Indonesia.
4. Off-boarding, allows Bank Indonesia to
remove participants from the wRD platform. In R3 Corda, supervision is implemented by utilizing
the broadcast feature to the observer node to
Bank Indonesia can manage these 4 (four) send transaction data upon settlement finality.
administrative features on the wRD platform Meanwhile, Kaleido Hyperledger Besu implements
using the administrator node. This ensures that observer nodes by utilizing the emit event feature on
Bank Indonesia has the final authority over who can smart contracts.
participate in the wRD. Figure 12. Observer Node Solution
R3 Corda utilized Business Network
Membership (BNM) tools to implement
membership feature. Kaleido Hyperledger Besu
managed membership features via Hierarchical-
Deterministic (HD) Wallets. The membership data
for both wRD platforms is accessible through smart
contracts.
3.1.3 SUPERVISION
For more effective and efficient policy making
and to protect participants and customers, Bank
Indonesia, as the regulator of the wRD platform, 3.2. DIGITAL ASSET LAYER
must be able to supervise transactions in
real-time. The distribution of transaction data on The digital asset layer represents the digital
the DLT platform does not inherently hinder Bank assets transacting on the wRD platform. In the
Indonesia’s supervisory process. However, it is wRD technology architecture, Bank Indonesia can
necessary to balance the need-to-know basis15 manage 2 (two) types of digital assets: the Rupiah
principle in wholesale transactions with the interest Digital and the digital securities. The existence
in supervision. of various digital assets on a single platform is
known as a unified ledger. The use of a unified
,, ...it is necessary to balance the need-to-know basis
ledger optimizes automation and customization of
asset (programmability), integration of one asset
,,
with another (composability), and simultaneous
principle in wholesale transactions with the interest settlement of multiple assets (atomic settlement).
in supervision.
The Immediate State phase PoC focuses on
developing the Rupiah Digital (cash ledger)
R3 Corda and Kaleido Hyperledger Besu have assets across all test scenarios. Digital securities
distinct characteristics when implementing assets are developed in a limited manner within
transaction recording. R3 Corda uses the concept the Delivery Versus Payment (DVP)16 scenario.
of shared facts, where no singular ledger contains Further exploration of digital securities assets will be
all transaction data. Transaction data on R3 Corda conducted at a later stage.
is shared with and stored only by the involved
participants. In contrast, on Kaleido Hyperledger
Besu, participants have identical data on the ledger,
,, In the wRD technology architecture, Bank
,,
but this data is stored in encrypted form. Only
Indonesia can manage 2 (two) types of digital
the parties involved can decrypt and access the
transaction data. Therefore, a monitoring solution assets: Rupiah Digital and digital securities.
that can be implemented on both platforms while
maintaining the confidentiality of participant
transactions is necessary. 3.3. EXECUTION LAYER
Monitoring solutions to maintain transaction The execution layer comprises components
confidentiality involve adding a node with that facilitate the execution of transactions and
computing processes on the wRD platform.
15. Need-to-know basis is a principle where only participants involved in a transaction can access the transaction data.
16. A securities settlement mechanism that links transfer of securities and transfer of funds in such a way that the delivery of securities occurs only if the
corresponding payment has been made.

1. Container, as the development environment for Hyperledger Besu, smart contracts are created
the wRD platform; using the Solidity programming language, which
runs on the Ethereum Virtual Machine (EVM) 20 (see
2. Smart Contract, as a form of business
Appendix C).
functionality implementation on the wRD
platform;
3.3.3. APPLICATION PROGRAMMING
3. Application Programming Interface (API), as
a communication protocol to execute smart INTERFACE (API)
contract functions; Application Programming Interface (API) 21 on
4. Web Application (Web App), as an interface to R3 Corda solutions utilize the
access the wRD platform; HTTP-REST protocol and are built using
Java Spring Boot. The API on R3 Corda serves
5. Messaging, as a communication method
as an intermediary to execute functions on smart
between nodes on the wRD platform;
contracts operating within the blockchain, off-
6. Integration, Interoperability, and chain22 transactions, and facilitate communication
Interconnection (3i), as the communication between the back-end and front-end.
standard between wRD and BI-RTGS.
Similarly, Kaleido Hyperledger Besu solutions
employ the HTTP-REST protocol, built using
3.3.1. CONTAINER the Golang programming language. In Kaleido
Hyperledger Besu, the HTTP-REST interface can be
The use of containers17 allows the wRD platform generated automatically based on the predefined
to run consistently across various operating smart contract functions, simplifying the integration
systems. Containers minimize compatibility issues with other platforms.
that can affect performance test results. Additionally,
containers simplify the scalability of the wRD
platform by enabling the creation and management
3.3.4. WEB APPLICATION (WEB APP)
of multiple application instances for performance A web application (web app) serves as the user
testing under varying loads. Containers also interface for executing business processes. In
promote modular application development by R3 Corda-based solutions, web apps are developed
packaging all application dependencies within using HTML and JavaScript, with the Angular.js
the containers, thereby reducing development framework, and are stored in cloud storage AWS S3
complexity. Both platforms utilize Kubernetes18 as a Bucket. An example of a web app developed with R3
container orchestration tool. Corda is shown in Figure 13.
R3 Corda and Kaleido Hyperledger Besu use a In Kaleido Hyperledger Besu-based solution
Kubernetes cloud service on AWS called AWS as shown in Figure 14, web apps are developed
Elastic Kubernetes Service (EKS). The platforms, using HTML and JavaScript. These web apps are
however, have different Kubernetes cluster then packaged into a container, designed to run
configurations (see Appendix C). after deployment on a Kubernetes cluster.
3.3.2. SMART CONTRACT
3.3.5. MESSAGING
Smart contracts are computer programs that
run on blockchain technology and contain the Both DLT platforms employ messaging queues23
rules and functions of business processes. The to facilitate asynchronous communication
use of smart contracts supports the money supply between application components within the
process, system policy, and supervision of the web platform. R3 Corda utilizes Apache Artemis as
Rupiah Digital. its messaging system, whereas Kaleido Hyperledger
Besu uses the Firefly Event Bus (see Appendix C).
Each platforms has a different implementation of
smart contracts.Smart contract in the R3 Corda,
resides within a CorDapp file written in the Java
programming language, which operates on the
Java Virtual Machine (JVM)19 . Meanwhile, in Kaleido
17. A container is a virtualization method used to run and distribute applications consistently across various computing environments (portability), which is required by both DLT platforms to be
developed.
18. Kubernetes is a container orchestration tool used to automatically scale applications up and down based on demand.
19. JVM (Java Virtual Machine) is responsible for executing Java bytecode programs.
20. EVM (Ethereum Virtual Machine) is a program responsible for executing smart contracts on the Ethereum blockchain network.
21. API (Application Programming Interface) is a protocol that allows one software application to interact and communicate with other software applications.
22. Off-chain transactions are processes that occur within the wRD platform without involving DLT database, such as limit policies, user management, file transfers, etc.
23. Messaging queue is a mechanism for communication through messages using a queue. It works by placing a message generated by a producer into the queue, and then the message is
retrieved from the queue to be processed by a consumer.

Figure 13. Web App View on R3 Corda Solution
Figure 14. Web App View on Kaleido Hyperledger Besu Solution
3.3.6. INTEGRATION, platform, data is stored in a relational database. The

data structure outlines the DLT structure, which
INTEROPERABILITY, and meets the requirements of the use case layer
INTER CONNECTION (3i) (see Subchapter 3.1).
In the PoC, BI-RTGS is integrated with the 3.4.1. STORAGE IN THE DATABASE
wRD platform for issuance and redemption. In
R3 Corda, this integration is achieved through file In the wRD PoC, both R3 Corda and Kaleido
exchange using AWS S3 Bucket, a cloud file storage Hyperledger Besu utilize the Relational
service. Conversely, Kaleido Hyperledger Besu Database Management System (RDBMS) 24 for
utilizes a web based interface to transmit BI-RTGS data storage. Participants with nodes (wholesalers
messages (see Appendix C). and non-wholesalers) are responsible for managing
their respective databases. For participants
3.4. DATA LAYER categorized as no-node, the database management
is handled by the provider node.
The data layer encompasses both data storage
methods and data structures. On the wRD Data storage in R3 Corda is categorized into
24. RDBMS technology used is PostgreSQL, provided through AWS Relational Database Service (RDS) (see Appendix D).
25. On-chain refers to the environment within the wRD platform that specifically uses DLT.

2 (two) types: on-chain25 data storage, known The DLT structures also shapes how the defined
as the Corda Vault, and off-chain data storage policy are stored (see Subchapter 3.1.2). In R3
(Figure 15). The on-chain database comprises Corda, the configuration policy wRD is stored as a
tables that represent the decentralized ledger. This state within CorDapp, while in Kaleido Hyperledger
data is immutable and distributed across nodes Besu, policy wRD is stored as an attribute in a
based on the need-to-know principle, ensuring smart contract.
a consistent schema throughout the network.
Conversely, the off-chain database consists of
tables related to access management for the wRD
,,
,,
The DLT structures used in PoCs are directed
web application. This data is mutable, allowing for
acyclic graph (DAG) for R3 Corda and Blockchain
changes, and can have different schemas across
nodes. For example, tables storing interconnection for Kaleido Hyperledger Besu.
data with BI-RTGS are only available on the KDR
node.
3.5. CONSENSUS LAYER
Data storage, both off-chain and on-chain, on
Kaleido Hyperledger Besu utilizes Kaleido’s The consensus layer incorporates a method to
Digital Asset Platform26 . This platform provides achieve agreement among nodes when a block
a range of off-chain services, such as the Smart of transactions is added to the ledger. This
Contract Manager, Private Data Manager, and Key consensus scheme on DLT is designed to enhance
Manager, as well as on-chain services, including the operational resilience by distributing transaction
Hyperledger Besu node, block indexer, and IPFS validation process, one of which is transfer.
node. Each service within the Digital Asset Platform
R3 Corda employs a unique consensus
stores data and manages its own database. While
mechanism that involves a notary27 (see
the database schema is consistent across all nodes,
Appendix E). In the PoC, the designated notary
the number of schemas varies depending on the
is a non-validating notary28 implemented by Bank
services required by each node.
Indonesia.
Figure 15. Design of Data Layer on R3 Corda Kaleido Hyperledger Besu employs proof-of-
authority (PoA) 29 consensus mechanism. In the
PoC, the selected PoA is Quorum Byzantine Fault
Tolerance (QBFT), involving Bank Indonesia and all
full nodes (see Apendix E).
,, R3 Corda employs a unique consensus mechanism
,,
that involves a notary... Kaleido Hyperledger
Besu employs proof of authority (PoA) consensus
mechanism.
3.4.2. STRUCTURE OF DLT
Despite the similarities in using RDBMS in R3
Corda and Kaleido Hyperledger Besu, the
3.6. NETWORK LAYER
2 (two) DLT platforms have significantly The most basic layer of the DLT Layer
different structures. The DLT structures used in Framework is the network layer30 , where data
PoCs are directed acyclic graph (DAG) for R3 Corda exchange communication within the network
and Blockchain for Kaleido Hyperledger Besu (see is determined based on network access. In the
Appendix D). PoC, according to the design of the Whitepaper and
In R3 Corda, the Rupiah Digital is stored as Consultative Paper, the chosen network access is
a token within a state on CorDapps, with permissioned network.
attributes such as nominal value, issuer (Bank There is a difference in network creation
Indonesia), and owner. Conversely, in Kaleido between R3 Corda and Kaleido Hyperledger
Hyperledger Besu, the Rupiah Digital is stored via Besu, as illustrated in the Figure 16 below.
a smart contract that contains the participant’s
account and balance.
26. Digital Asset Platform is a middleware service from Kaleido that provides services related to DLT platform.
27. A notary is an entity responsible for preventing double-spending (money being spent twice) by validating the input state of a transaction.
28. A notary that checks transactions to prevent double-spending (uniqueness validation) but does not verify the correctness of the transactions (transaction validation).
29. A consensus algorithm in which participants know and trust each other. A central authority designates participants who can perform transaction validation (delegates).
30. Network Layer is a set of interconnected nodes that adhere to a technology standard (protocol) and actively participate together in storing, exchanging data, and processing information within
an integrated communication channel.

Figure 16. The Process of Identifying New Members in the Network (a) In the Implementation of R3 Corda;
(b) In the Implementation of Kaleido Hyperledger Besu
R3 Corda relies on an additional component called must be unique to ensure that participants of
Corda Enterprise Network Manager (CENM)31, the wRD platform can be identified through the
which is responsible for identifying participants, as certificate.
well as adding them to the network map32.
In Kaleido Hyperledger Besu, adding a new node
Meanwhile, Kaleido Hyperledger Besu involves to the network involves utilizing the genesis
creating a network by using bootnode33 and file owned by the bootnode, as illustrated in
genesis files34 for new participants, subsequently Figure 16 (b). The bank initiates the creation of a
adding those participants to the configuration of new node based on the genesis file and modifies
each node. Both CENM and bootnode are under the the network configuration accordingly. Additionally,
authority of Bank Indonesia (see Appendix F). synchronizing the network configuration across all
nodes requires establishing a communication link
In R3 Corda, the node must have an identity
with the new node.
encapsulated in a digital certificate (which
contains public and private keys) issued by
CENM, as depicted in numbers 1 and 2 in 3.7. SECURITY ASPECTS
Figure 16 (a). The identity registered on CENM
The security aspects in the implementation of
,, The network layer is where data exchange
the wRD PoC have been tested and follow the
applicable security standards at Bank Indonesia.
communication within the network is determined
,,
based on network access. In the PoC, the chosen
network access is permissioned network.
31. R3’s commercial service, Corda Enterprise, allows for the operation of a Corda network with full control, including consensus management.
32. A network map is a component that stores information about all nodes connected to the network and functions like a directory.
33. Bootnode is node that initially creates the network.
34. Genesis file is a file that contains the network configuration.

CHAPTER 4
POC TESTING & RESULT
Based on 3 (three) key questions, tests have been conducted to address all scenario
topics, encompassing both business and technical aspects.
KQ# 1:
4.1. Implementation of the burden of transaction
processing and validation
DLT in the Money Supply Process across multiple participants
of Wholesale Rupiah Digital in the DLT network, rather than
relying solely on the central bank.
The implementation of wRD on the DLT platform Kaleido Hyperledger Besu, using the Quorum
involves a series of processes related to money Byzantine Fault Tolerance (QBFT) consensus
supply. The issuance and redemption processes algorithm, decentralizes validation rights to DLT
adhere strictly to the principle of no-money creation participants predetermined by the central bank.
through conversion. This conversion process is Conversely, R3 Corda employs a unique consensus
executed by transferring the participant’s current method involving notary nodes and transaction
account balance to/from wRD in real-time, participants.
orchestrated by KDR node. Additionally, the DLT
Through smart contracts and consensus
platform supports the transfer of funds between
mechanisms, the DLT platform ensures the
participants within the network through the fund
confidentiality of transaction data. The Kaleido
transfer process. This process is designed to
Hyperledger Besu-based solution guarantees
enhance liquidity efficiency, particularly through the
confidentiality through encryption methods, while
transaction queue function.
R3 Corda applies the need-to-know principle for
The wRD incorporates features designed to every transaction.
support the implementation of monetary and
For Kaleido Hyperledger Besu, in addition to
macroprudential policies. These policies are
the encrypted privacy model, the confidential
enforced through system controls, such as setting
unspent transaction output (UTXO) model
limits on circulating wRD and utilizing administrative
with a notary is also implemented in the PoC.
features to manage participant eligibility. An
In further exploration, there is a possibility to apply
observer node is employed to monitor participant
Zero Knowledge Proof (ZKP) privacy model (see
activities, as well as track the position and changes
Appendix G).
of wRD on the DLT platform.
Access management plays a crucial role in
Money supply processes, policy settings, and
supporting privacy aspects and regulating
monitoring on the DLT network are regulated by
participant authorization on the DLT platform.
smart contracts. These smart contracts, with their
By leveraging smart contracts and consensus, the
automation capabilities, are a novel aspect of the
DLT platform has significantly increased the speed
system that streamlines transactions.
of money circulation, with each platform capable of
Besides the reliability of smart contracts, processing more than 30 transactions per second
the DLT finalizes wRD transactions through (see Appendix I).
a consensus mechanism that differs from
conventional systems. This mechanism distributes

Smart contract composability
capabilities allow atomic settlement in
payment systems, particularly in Delivery
Versus Payment (DvP) transactions. In DvP
transactions, the transfer of digital asset ownership
and transaction funds occur simultaneously. Atomic
settlement reduces settlement risk because the
transaction is only completed if both parties meet
KQ# 2: the requirements.
4.2. Implementation of Smart Contract Tokenization enables the conversion of
on Rupiah Digital Wholesale BI-RTGS current accounts to wRD, allowing the
implementation of smart contracts in Rupiah
Platform
currency. Additionally, tokenization helps the wRD
Implementing smart contracts on the wRD platform manage the Rupiah Digital assets and
platform increases the efficiency of business digital securities.
processes by automating transaction Each DLT platform has a different tokenization
execution based on predetermined rules, method. R3 Corda’s Token SDK supports the
leveraging programmability, composability, and issuance and management of digital tokens,
tokenization advantages. The programmability while Kaleido Hyperledger Besu uses the ERC20
capabilities of smart contracts provide the ability standard for the Rupiah Digital token base and
to program the Rupiah currency with specific ERC1400 for digital securities tokens. Use cases
functionality to determine how the currency can be for DvP transactions and digital securities are not
used. For example, a Rupiah Digital could be issued the primary focus of the Immediate State phase
and explicitly programmed for tax payments. of PoC but will require further exploration for the
Programmability implies that Bank Indonesia Intermediate State phase.
can add or modify smart contracts to enhance ,,
the functionality of the wRD platform. In
R3 Corda-based solutions, smart contract Implementing smart contracts on the wRD platform
customization on the network can be achieved increases the efficiency of business processes
through CorDapp (Corda Distributed Application). by automating transaction execution based on
,,
Meanwhile, Kaleido Hyperledger Besu provides a
predetermined rules, leveraging programmability,
Contract Management service accessed through
the Asset Platform to deploy new smart contracts composability, and tokenization advantages.
into the blockchain.

KQ# 3: Furthermore, the observer node enables wRD
to accommodate the needs of data centers by
4.3. Integration, Interoperability and
capturing transactions in a granular, private,
Interconnection of wRD with and secure manner. This supports monetary policy
Other Financial Market analysis, financial system stability, and payment
systems, while also helping to prevent fraudulent
Infrastructure transactions and support the AML/CFT process.
To future proof payment system initiatives, wRD
In this PoC, interconnection focuses on the
will adopt ISO 20022 as a messaging standard.
interoperability of existing Financial Market
ISO 20022 has been recognized and adopted
Infrastructures (FMIs) through connectivity to
globally to facilitate the harmonization of
the Bank Indonesia Real Time Gross Settlement
cross-border and cross-industry transactions.
(BI-RTGS) system during issuance and
redemption. R3 Corda builds a mock system that
replicates the current BI-RTGS system based on
ISO 150022. The mock system is designed to read
,, In this PoC, interconnection focuses on the
input files from BI-RTGS and trigger the appropriate
R3 Corda API. It can also generate output files that interoperability of existing Financial Market
can be processed by the BI-RTGS system. Infrastructures (FMIs) through connectivity to the
,,
Bank Indonesia Real Time Gross Settlement
Meanwhile, in Kaleido Hyperledger Besu, the
interconnection simulation with BI-RTGS is (BI-RTGS) system during issuance and redemption.
conducted through the RTGS Bridge (using API).
Data exchange in the form of files with BI-RTGS is
performed through a user interface in accordance
with ISO 150022.
3 2 1
CHAPTER 5
FINDING AND NEXT sTEp
In the Rupiah Digital PoC, findings and considerations for future steps have been
identified. Aspects not implemented in the PoC will be explored further, taking into
account feedback from the industry, the community, and the current PoC results.
5.1 FINDING 5.2 NEXT STEP

Bank Indonesia and technology experts This PoC is a milestone in achieving Project
successfully achieved the objectives and Garuda’s goals. Project Garuda will proceed with a
addressed 3 (three) key questions in this PoC. broader exploration of securities ledger. This includes
Based on the development and execution of the test feasibility analysis, development of utilization and
scenario, the following conclusions can be drawn: business processes, interoperability with other digital
assets, and the exploration of potential advantages
The implementation of the wholesale offered by the implementation of digital securities.
1
Rupiah Digital (wRD) business model,
including the money supply process and Based on the PoC results, several exploration
governance of its implementation, can be topics can enhance the next phase of Project
effectively carried out on distributed ledger Garuda, specifically in liquidity management (e.g.:
technology (DLT) using smart contracts Liquidity Saving Mechanism (LSM)) and privacy
and consensus mechanisms; technology (e.g.: Parallelism of Zero Knowledge
Proof). This ensures that the implementation of
business models and technology will provide the
2
The added value of smart contracts in market with more efficient liquidity and information
DLT, compared to conventional systems, data privacy in accordance with Bank Indonesia’s
lies in their capabilities to support criteria.
programmability, composability, and
tokenization;
The implementation of wRD on DLT
3
facilitates connectivity with Bank
Indonesia’s internal systems, domestic
financial market infrastructure, cross-border
initiatives, and other payment system
projects through API connections and the
ISO 20022 messaging standard.

abbreviations
Integration, Interoperability, and International Organization for
3i ISO
Interconnection Standardization
Anti-Money Laundering and
AML/CFT Combating the Financing of JMS Java Message Service
Terrorism
Advanced Message Queuing
AMQP JVM Java Virtual Machine
Protocol
Application Programming
API KDR Khazanah Digital Rupiah
Interface
App Application (Software) KQ Key Question
AWS Amazon Web Service LSB Non-Bank Institutions
BFT Byzantine Fault Tolerance LSM Liquidity Saving Mechanism
BI Bank Indonesia MT Message Type
Bank Indonesia Real Time
BI-RTGS MTO Make-to-Order
Gross Settlement
Neural Autonomic Transport
BNM Business Network Membership NATS
System
Indonesia Payment System
BSPI NKRI Republic of Indonesia
Blueprint
Financial Sector Development
CBDC Central Bank Digital Currency P2SK
and Strengthening
Corda Enterprise Network
CENM PoA Proof of Authority
Manager
CorDapp Corda Distributed Application PoC Proof of Concept
Quorum Byzantine Fault
CP Consultative Paper QBFT
Tolerance
Relational Database
DAG Directed Acyclic Graph RDBMS
Management System
DLT Distibuted Ledger Technology RDS Relational Database Service
DvP Delivery Versus Payment REST Representational State Transfer
EDA Event-driven Architecture RTGS Real Time Gross Settlement
EEA Enterprise Ethereum Alliance S3 Simple Storage Service
EKD Digital Financial Economy SDK Software Development Kit
EKS Elastic Kubernetes Service SP Payment System
ERC Ethereum Request for Comment SSK Financial Stability System
EVM Ethereum Virtual Machine TLS Transport Layer Security
FAFO First Available First Out TPS Transaction per Second
FIFO First In First Out UTXO Unspent Transaction Output
HD Hierarchial-Determinitic UU Act, Law
Wholesale Cash Ledger Rupiah
HSM Hardware Security Modules wRD
Digital
HTTP Hypertext Transfer Protocol WS Workstream
ID Identity WSr Wholesaler
IPFS InterPlanetary File System ZKP Zero Knowledge Proof
APPENDIX
A. DETAIL EVALUATION OF DLT
In the series of PoC activities, 2 (two) DLT platforms ensure that the DLT platforms can be used as a
were selected through a technical evaluation with solution for central bank digital currency (CBDC).
the objective of ensuring the suitability of the DLT There are 3 (three) track record criteria used, based
platform characteristics with the needs of Bank on the exploration roadmap for the Rupiah Digital
Indonesia. The technical evaluation was conducted in the White Paper: the use of the DLT platform as a
through 3 (three) stages: the preparation of a long CBDC solution for wholesale cash ledger, wholesale
list, a short list, and the final selection. securities ledger, and retail (the option remains
open for either DLT or a centralized system). The
1. Long List short list evaluation was conducted by matching the
DLT platforms on the long list with those used by
The long list is a compilation of all potential DLT central banks and international financial institutions
platforms that can be tested in the PoC. The in the exploration of CBDC wholesale cash ledger,
potential DLT platform candidates were sourced wholesale securities ledger, and retail, as published.
from web searches, news, and correspondence with The assessment results for the short list showed
both national and international DLT practitioners. that, out of the 39 DLT platforms in the long list, 5
Based on the evaluation results (as of October 2023), (five) DLT platforms had been used by central banks
39 potential DLT platforms were identified, each or other international financial institutions (as of
with its own characteristics as shown in Table 1. October 2023) and became candidates for the final
selection.
2. Short List
3. Final Selection
The short list is the result of selecting DLT platforms
The selection of the 2 (two) DLT platforms to be
from the long list based on each platform’s track
tested in the PoC was based on 3 (three) selection
record. The purpose of creating the short list is to
criteria. The first is mandatory requirements, where
Table 1. List of Potential DLT Platform

the DLT platform must be supported by a company/ R3 Corda and Kaleido Hyperledger Besu meet the
legal entity to ensure the sustainability of the 3 (three) focus areas of the Bank Indonesia PoC,
technology and is a permissioned network. where both have different characteristics in terms of
ledger structure, privacy solutions, and consensus
The second is the track record of each DLT platform,
methods, as shown in Table 2.
DLT platform that have been used more frequently
in CBDC or digital securities projects receive higher R3 Corda uses a UTXO ledger structure, which
scores. The third is the compatibility of the selected can be simply described as recording transactions
DLT platform with the 3 (three) focus areas to be based on the transfer of token ownership. Kaleido
explored during the PoC, which are: Hyperledger Besu uses an account-based ledger
structure, which can be simply described as
1. The difference in ledger structures between
recording transactions based on changes in account
token/unspent transaction output (UTXO)
balances.
based and account-based DLT platforms;
Privacy solutions on R3 Corda use a vault that
2. The data privacy solutions used by each
only stores transactions relevant to its owner.
DLT platform to ensure the confidentiality of
Kaleido Hyperledger Besu has a global ledger that
transaction information;
records all transactions and distributes them to all
3. The consensus methods used by the DLT participants, data privacy is achieved through a
platforms. private data manager, which performs encryption
and decryption of data on the global ledger. Only
Corda and Hyperledger Besu were selected as
participants involved in a transaction can decrypt
the DLT platforms with the highest potential
the data on the global ledger.
based on the 3 (three) final selection criteria to be
developed and tested according to the needs of R3 Corda uses a unique consensus method
Bank Indonesia. As per the mandatory selection called ‘Notary,’ which acts as a central authority to
criteria, both platforms have supporting companies/ verify the uniqueness of transactions (uniqueness
legal entities. Corda is supported by R3, while consensus). Kaleido Hyperledger Besu uses a
Hyperledger Besu is supported by Kaleido. proof of authority (PoA) consensus method, where
several validators pre-determined by participants are
authorized to validate transactions.
Table 2. PoC Focus Detail

APPENDIX
B. IMPLEMENTATION DETAILS of the use
case layer
1. Integration of wRD Platform with illustration of the transaction creation process in
Kaleido Hyperledger Besu is depicted in Figure 18.
BI-RTGS for Issuance and
Redemption 3. Destruction Detail
There are 4 (four) types of MT used for In R3 Corda, which utilizes the Unspent Transaction
communication of the wRD platform with the BI- Output (UTXO) model, destruction is a transaction
RTGS system in Table 3. intended to delete a token. The transaction is
Table 3. The Use of MT File executed through the redemption flow call in the
Rupiah Digital CorDapps application. The illustration
of the destruction flow in R3 Corda is depicted in
Figure 19.
Figure 19. Destruction on R3 Corda UTXO
2. Creation Detail
In R3 Corda, which utilizes the Unspent Transaction In Kaleido Hyperledger Besu, which utilizes
Output (UTXO) model, the creation process involves accounts, destruction is a transaction that reduces
a transaction that produces the Rupiah Digital an account’s balance through an update world state.
token. This transaction is executed by invoking the Transactions are made by calling the redemption
issuance flow on the Rupiah Digital CorDapps. The function in Rupiah Digital smart contract. The
illustration of the transaction creation process in R3 illustration of the destruction flow in Kaleido
Corda is depicted in Figure 17. Hyperledger Besu is depicted in Figure 20.
Figure 17. Creation on R3 Corda UTXO
Figure 20. Destruction on Kaleido Hyperledger Besu
4. Redemption with RTGS Triggered

Figure 18. Creation on Kaleido Hyperledger
Besu Account Based Redemption initiated from BI-RTGS is explored in
the PoC using a mock-up of the BI-RTGS system.
However, implementing further processes requires
developing BI-RTGS capabilities that are beyond the
scope of the Rupiah Digital PoC. The illustration of
the RTGS triggered redemption flow is depicted in
Figure 21.
Participants registered in the BI-RTGS system
In Kaleido Hyperledger Besu, which utilizes the initiate requests to credit their current accounts and
account model, the creation process involves debit the CBDC omnibus account. Upon completion
a transaction that adds balance to an account of the settlement in RTGS, the KDR node on
by updating the world state. This transaction is the wRD platform receives MT202 and MT900
executed by invoking the issuance flow through the messages as confirmation.
KDR node to the Rupiah Digital smart contract. The

Figure 21. Redemption Process RTGS Triggered Subsequently, KDR node initiates the crediting of the
omnibus account and debits participants’ balance
on the wRD platform to finalize the settlement on the
Rupiah Digital side. In R3 Corda, KDR node initiates
a flow on CorDapps that receives the Rupiah Digital
token input and destroys the token. In Kaleido
Hyperledger Besu, KDR node triggers a function in
the smart contract to transfer the balance from the
participant’s account to the burn address.

APPENDIX
C. IMPLEMENTATION DETAILS of the
execution layer
1. Kubernertes Cluster Configuration Bank Indonesia Kubernetes cluster, as illustrated in
Figure 22, and 3 (three) participant bank Kubernetes
In R3 Corda solutions, the Kubernetes cluster clusters, as depicted in Figure 23.
configuration is separated into 2 (two) types: the
Figure 22. Bank Indonesia’s R3 Corda Cluster Configuration on AWS Infrastructure
Figure 23. Participant’s R3 Corda Cluster Configuration on AWS Infrastructure

In Kaleido Hyperledger Besu solution, there are 4 Composability allows multiple smart contracts to
(four) entities: Bank Indonesia, Bank 1, interact with each other, enabling the bundling
Bank 2, and Bank 3. This configuration employs of multiple transactions into one. Tokenization
a single Kubernetes cluster, with a Kubernetes facilitates the creation and management of various
Namespace separating the entities within it. The digital assets, including both the Rupiah Digital and
cluster configuration for Kaleido Hyperledger Besu the digital securities.
is shown in Figure 24.
The use of smart contracts introduces new features
such as access restrictions, cryptography, and the
2. Smart Contract separation of on-chain and off-chain data. These
features are tested in this PoC to enhance the
Smart contracts are computer programs that
current transaction privacy model. In the long term,
operate on blockchain technology, offering several
as transaction data accumulates and the demand
unique capabilities: programmability, composability,
for improved transaction methods increases, smart
and tokenization. Programmability refers to the
contracts can be further developed to meet these
ability to automatically execute, control, or document
evolving needs.
events and actions according to predetermined
rules, eliminating the need for human intervention.
Figure 24. Kaleido Hyperledger Besu Cluster Configuration of Bank Indonesia’s and Participant’s Node
on AWS Infrastructure

In R3 Corda, a smart contract resides within a as illustrated in Figure 26. Both platforms implement
CorDapp (Corda Distributed Application). data separation using on-chain and off-chain
As depicted in Figure 25, a CorDapp is a file with storage. Transaction records, such as transaction ID,
jar extension containing classes written in Java or sender-receiver details, and transaction amounts,
Kotlin, which typically include: are stored on-chain, while other data, such as
participant profiles, are stored off-chain.
1. State: Contains data and facts that will be
agreed upon by all parties; Kaleido Hyperledger Besu supports smart contracts
written in Solidity or any other programming
2. Contract: Contains rules that regulate the
language that can be compiled into Ethereum Virtual
parties involved in a business process and the
Machine (EVM) bytecode. These smart contracts are
transactions that can be carried out;
deployed onto the blockchain and executed within
3. Flow: Contains flows of a business process and the EVM. The execution of a smart contract function
how transaction data is modified or updated. occurs when a new transaction is written into a
Figure 25. CordApp Component
R3 Corda supports the issuance and management block within the DLT network. Kaleido Hyperledger
of digital tokens using the Token SDK, which Besu provides a contract management service that
facilitates tokenization, including the Rupiah Digital facilitates the deployment and customization of
and the digital securities tokens. Each token is open-source smart contract standards on EVMs,
governed by smart contracts that control its status such as ERC20, ERC721, and ERC1400. The ERC20
and data, and manage the MTO process from standard is used as the basis for the Rupiah Digital
issuance to settlement according to specified token, while ERC1400 is utilized for digital securities
business processes. tokens. Kaleido Hyperledger Besu stores all
transaction details (transaction ID, sender, recipient,
R3 Corda does not implement a global ledger.
timestamp, etc.) on-chain in encrypted form,
Instead, its architecture utilizes bilateral/point-to-
ensuring that only authorized parties can access the
point data sharing. In R3 Corda, only approved
transaction details.
parties can join the network, and only relevant
parties have access to transaction information,
Figure 26. Rupiah Digital and Digital Securities Illustration at Wholesale Wallets R3 Corda

3. Messaging Components In R3 Corda 4. Integration of the wRD platform
and Kaleido Hyperledger Besu with BI-RTGS
Event-driven architecture (EDA) is a software R3 Corda and Kaleido Hyperledger Besu, in general,
development approach where system components have built-in interoperability features that enable the
interact through the exchange of events. An event wRD platform to communicate with other payment
signifies a state change within the system, such systems, such as BI-RTGS, through standard
as user input, data updates, or notifications from communication protocols. This capability directly
an external system. This pattern contrasts with the supports the creation of an integrated, interoperable,
traditional request/response architecture, where and interconnected (3i) digital ecosystem.
services must wait for a reply before proceeding to
In the PoC, both solutions were connected to
the next task.
the BI-RTGS using standard communication
In EDA, components or services communicate protocols and message formats defined by the
asynchronously by reading or sending events, existing BI-RTGS messaging standard. The wRD
allowing them to react to changes flexibly and platform demonstrated that message formats and
independently. Messaging is a crucial component in communication protocols could be configured to
EDA, facilitating the sending and receiving of events. meet user requirements. Adjustments from the
current message format standard to the ISO 20022
R3 Corda employs the Advanced Message
standard are feasible, leveraging the Bank Indonesia
Queuing Protocol (AMQP) 1.0 via Transport Layer
3i standard of integration, interoperability and
Security (TLS) 1.2 between nodes. This is currently
interconnection.
Figure 27. Firefly Event Bus (Hyperledger Firefly, 2024)
implemented using Apache Artemis, a message The mapping of the current message format
broker built on top of the MQ protocol. R3 Corda to the ISO 20022 format was carried out in the
uses Artemis for communication across the DLT PoC and will serve as a reference point for future
network, such as when executing transactions developments. Bank Indonesia chose ISO 20022
between nodes. Similarly, Kaleido Hyperledger because it is a globally recognized communication
Besu utilizes the FireFly Event Bus, a messaging standard for financial transactions, including
system developed by Kaleido, enabling applications payments, remittances, and other transactions that
to receive events from all back-ends connected to support financial inclusion.
FireFly, as illustrated in Figure 27.
For R3 Corda solutions, a parser and file generator
Applications that subscribe to these events use were developed, compatible with the current
protocols such as websocket and webhook. standard format, as illustrated in
Additionally, plugins can connect to other transport Figure 28. The application, built using Java Spring
protocols, including NATS, Kafka, and Java Message Boot, processes BI-RTGS message files and triggers
Services (JMS) Server. an R3 Corda API in response. This application also
generates message files for the emulated BI-RTGS
systems, which are then uploaded into AWS S3.
This approach simulates the existing file messaging
exchanges in BI-RTGS.

Figure 28. R3 Corda Based PoC Solution Design: BI-RTGS Integration
The BI-RTGS Bridge was developed to connect websocket. Transaction triggers are executed by
the Kaleido Hyperledger Besu platform with the sending data in standard format through a form on
BI-RTGS system, handling business scenarios of the web app. Subsequently, this data becomes an
issuance and redemption. Data exchange with event sent through websocket to be executed as an
BI-RTGS, using the standard format, is conducted on-chain transaction on the DLT.
through a user interface (web app).
The BI-RTGS Bridge is developed using HTML
and JavaScript, connected to the Firefly service via

APPENDIX
D. IMPLEMENTATION DETAILS of the data
layer
1. Relational Database Management on
Figure 31. Directed Acyclic Graph on R3 Corda
R3 Corda
R3 Corda utilized 10 (ten) instances of AWS RDS: 9
(nine) for different on-chain databases and 1 (one)
dedicated to managing 8 (eight) off-chain databases,
as illustrated in Figure 29.
Figure 29. Database Design on R3 Corda
The image depicts various entities forming

interconnected nodes, each representing a single
transaction. For instance, a Transaction (Command)
signed by a party processes a state and generates
2. Relational Database Management on a new state. This transaction remains indirectly
Kaleido Hyperledger Besu connected, producing a new state that can be
traced back to its origin.
Figure 30. Database Design on Kaleido Hyperledger Besu
4. Kaleido Hyperledger Besu: Asset

Platform and Blockchain
In addition to blockchain, Kaleido Hyperledger Besu
has a data modeling layer that is divided into 3
(three) segments, as depicted in Figure 32.
Figure 32. Kaleido’s Asset Platform Digital Data Layer

Kaleido Hyperledger Besu utilizes 4 (four) AWS (Kaleido, 2024)
RDS instances, with each instance connected to its Application
Member Instance / Node Private Off-Chain
Execution
corresponding Asset Platform and the middle-layer External

Users
UI API
Member-Specific State
Rules / Policies
App Stack. Participants who own nodes manage Connected

Keys Private Datastore
Agreed Off-Chain
Execution
their own databases and Asset Platforms.

Systems
Selective Disclosure Tasks / Flow
Confidential UTXO Data Hashing Zero Knowledge Proofs

DApps
3. R3 Corda: Directed Acyclic Graph Rollups Data Signing
Shared On-Chain
Execution
(DAG)
Shared Global State
Smart Contracts
Blockchain Notary-controlled DLT Shared Database
Graph data consists of nodes, or points,

interconnected by edges. Nodes represent entities
or instances of data, while edges represent the The top layer is the Member-Specific State, which
relationships between nodes. Together, connected contains specific data from network participants,
nodes and edges form graphs, a model that such as Public and Private Keys. The second
illustrates the interconnectedness of data. layer contains additional data modeling to store
confidential transaction data that remains connected
A directed acyclic graph (DAG) is a specific type of to global data.
graph characterized by 2 (two) main properties:
1) Each edge has a single direction, from an origin At the bottom layer, known as the Shared Global
node to a destination node, and 2) There are no State, a distributed ledger forms a fundamental
cycles, meaning no nodes form a loop. A more component of Kaleido’s technology. In the current
precise illustration can be seen in the following PoC, the selected blockchain stores transaction data
image. that is shared globally.

Figure 33. Blockchain on Kaleido Hyperledger Besu functions as a chain linking one block to the previous
block. Each block can contain zero to n transactions,
with the maximum number of transactions
determined by the network configuration.
Using a DLT structure such as blockchain,
transactions can be traced back to the creation of
the first block. Transactions can be referenced by
their index within a block and traced through the
hash of the previous block stored in the block header.
5. Confidential UTXO Implementation

The implementation chosen for the PoC is the
Confidential Unspent Transaction Output (UTXO). In
this approach, the amount and owner data of a token
Blockchain technology is distinguished by its unique
are stored off-chain in the Member-Specific State.
characteristic of storing data in a connected block
The blockchain transaction data only stores the ID of
structure. As illustrated in the Figure 33, 1 (one) block
the token being transacted.
comprises 2 (two) categories of information: header
blocks and transaction data. The header block

APPENDIX
E. IMPLEMENTATION DETAILS OF THE
CONSENSUS LAYER
1. Consensus Mechanism in R3 Corda 2. Consensus Mechanism in Kaleido
The consensus mechanism in R3 Corda can be Hyperledger Besu
divided into 2 (two) main components: transaction
validation and transaction uniqueness. QBFT is a proof of authority (PoA) consensus
algorithm recommended for private networks in
i. Transaction Validation Kaleido Hyperledger Besu. In QBFT, participants
Transaction validation ensures that all designated as validators (referred to as trusted
conditions required for a transaction are met validators) are authorized to validate transactions
(e.g., sufficient balance, participants acting and take turns in block creation within the network.
within their authority). This process is performed A supermajority (more than 2/3) of the trusted
by smart contracts (when executed) and the validators who are not assigned to block creation
transaction participants. Every transaction must sign the transactions before the “created
must comply with the smart contract terms. block” can be added to the blockchain.
Before sending the transaction to the notary
(explained in section ii: Transaction Uniqueness), Figure 35. Consensus Mechanism in
the participants must sign the transaction, Kaleido Hyperledger Besu
indicating it has been validated. Before signing,
participants review the transaction to ensure it
adheres to the smart contract terms and meets
all necessary requirements for validity.
ii. Transaction Uniqueness
Transaction uniqueness prevents double-
spending by verifying that each transaction
input has not been used in another transaction
(ensuring uniqueness). This verification is
performed by the notary. Once the transaction
is signed by all relevant participants, it is sent
to the notary. After the notary confirms the
transaction’s uniqueness, it is considered final.
This finality ensures that the transaction cannot
be canceled or altered.
Figure 34. Consensus Mechanism in R3 Corda

Furthermore, QBFT is designed to tolerate Byzantine ii. BFT-based
failures, meaning it can handle up to f “faulty” nodes, Consensus with vote/Byzantine Fault Tolerance
provided the total number of nodes n meets the (BFT)-based algorithms is generally used in
condition n ≥ 3f + 1. This ensures that the network permissioned DLTs. BFT-based consensus
will continue to reach consensus as long as the is achieved through a series of deterministic
number of failed trusted validators does not exceed communications between nodes. Contrary to
the tolerated threshold. proof-based, BFT-based has better performance
but tends to be lower in decentralization (BFT-
3. Findings: Consensus based tends to be more centralized).
iii. DAG-based
When adding a block to a DLT, each node in
Consensus with DAG-based algorithms is
the system must reach an agreement. This is
used by distributed ledgers that employ graph
accomplished in the consensus layer. Most
structures rather than blocks, as typically
consensus algorithms today fall into 3 (three)
used in blockchain. In DAG-based systems,
categories: i) proof-based, ii) BFT-based, and iii)
transactions form nodes in a graph that refer
DAG-based.
to each other, creating a series of graphs. This
graph structure allows transactions to occur
i. Proof-based in parallel, resulting in high scalability and
Consensus with proof-based algorithms is the throughput. However, DAG-based systems
most commonly used in public/permissionless tend to have lower security. Some DAG-
DLTs. Proof of work in Bitcoin and proof of based systems also use the concept of trusted
stake in Ethereum are well-known proof-based validators, which reduces decentralization.
consensus mechanisms that provide high levels
In conclusion, there is no “one-size-fits-all”
of security, scalability, and decentralization
consensus. Therefore, it is necessary to delve into
in trustless systems. However, proof-based
the specific needs of each case to determine which
consensus, especially traditional proof of work,
consensus is most suitable.
requires a significant amount of energy and has
low throughput and transaction confirmation
speed. Despite this, innovations and
modifications in proof-based methods continue
with the aim of achieving better performance
while maintaining the same level of security.

GAMBAR 36. ILUSTRASI PENGGUNAAN CENM (R3 CORDA, 2024)
APPENDIX
F. IMPLEMENTATION DETAILS of the
NETWORK LAYER
1. Illustration of the Use of CENM 3. Signing Service
The Signing Service is responsible for signing
Corda Enterprise Network Manager (CENM) several things: Identity Certificates, Revocation
manages and operates the R3 Corda DLT network. lists, Network Parameters, and Network Maps.
CENM provides a set of functions that can be used R3 recommends storing each key in Hardware
by operators to manage DLT networks, including Security Modules (HSMs) to keep that critical
node configuration, network map management, and security by adding a configuration to the
certificate authority services. Signing Service.
CENM is supported by 3 (three) main components

to carry out its functions, including: 2. Permissioned Network Kaleido
1. Identity Manager
Hyperledger Besu
The identity manager performs 2 (two) main
functions to manage the identity of nodes in There are 3 (three) networks that connect the
the R3 Corda network: 1) Issuance of node Kaleido Hyperledger Besu nodes: the blockchain
identities through the issuance of certificates network, the private transaction network, and the
that associate legal names with public keys. InterPlanetary File System (IPFS). The blockchain
2) Revoking the certificate when needed. The network on Kaleido Hyperledger Besu operates
Certificate Issuance and Revocation service using a permissioned network with 2 (two) types of
in Identity Manager supports using plugins35 access controls: node-based and account-based.
to model the approval process workflow for Node-based access control manages a node’s
certificate issuance and revocation. ability to connect to the network, while account-
based access control governs the onboarding
Figure 36. Illustration of the Use of CENM (Corda, 2024) process, account freezing, and the limitation of
transaction activities within the network.
In the blockchain network, there are 2 (two) levels
of access control: local and on-chain. Local access
controls are stored on individual nodes and contain
a whitelist of nodes approved for communication.
This level of control primarily focuses on protecting
nodes connected to the network. On the other
hand, on-chain access controls are stored in smart
contracts and regulate the roles of individual
accounts in performing transactions on the network.
To meet privacy standards, Kaleido Hyperledger
2. Network Map Besu employs a private data manager, which
The Network Map serves as a location service connects to the private transaction network using
for nodes once they obtain the identity mutual TLS protocols for secure point-to-point data
assigned by CENM. In addition, by joining the transmission.
network, a node agrees on a set of parameters
The InterPlanetary File System (IPFS) network
that define the rules for reaching a consensus
facilitates file exchanges between nodes.
on the zone. One of the most important is the
list of trusted notary services.
A zone can host several consensus rule sets,

each forming a different sub-zone within the
main zone.
35. Plugins are software components that add specific features or functions to a computer program.

APPENDIX
G. Liquidity Management and Privacy
Concepts for Advanced
Exploration
1. Liquidity Management: Liquidity Unlike the PoC implementation that distributes
queue management among participants, a
Saving Mechanism centralized queue relies on a single entity, such
In the implementation of the Rupiah Digital proof as the observer node, to manage the queue. In
of concept (PoC), both the R3 Corda and Kaleido this case, the observer node, which is aware of
Hyperledger Besu solutions adopted gross each participant’s transactions, is delegated to
settlement mechanisms equipped with queueing manage the queue and resolve gridlocks. When
mechanisms to simplify and reduce the need for multiple participants experience gridlocked
a complex liquidity-savings mechanism (LSM). transactions, they can submit these transactions to
The queueing mechanism is implemented in a the centralized queue, encapsulated as an event.
decentralized manner, where participants are The centralized queue then waits for additional
responsible for managing their own queues. A transactions that can be resolved within a
transaction enters the queue if it does not meet the predefined time limit. If this time limit is exceeded,
transaction criteria: 1) Low Priority, and the transactions are canceled to prevent ongoing
2) Sufficient Balance. gridlock.
The R3 Corda solution processes queues using a 2. Privacy: Zero Knowledge Proof
First In, First Out (FIFO) approach, meaning that the
earliest transaction in the queue is processed first In the BI-RTGS system, only the transaction parties
once the participant’s balance is sufficient to cover have information about their own transaction
the transaction. On the other hand, the Kaleido data. There are several DLT solutions that can
Hyperledger Besu solution applies a First Available, accommodate this policy. R3 Corda, which is built
First Out (FAFO) method for queue processing, on a need-to-know principle using a directed acyclic
where transactions with sufficient balance are graph (DAG), directly meets the privacy criteria
processed first. set by Bank Indonesia. On the other hand, Kaleido
There are aspects of the queueing mechanism for Hyperledger Besu, which utilizes EVM blockchain
LSM that can be further explored, as illustrated technology, adopts Ethereum’s global state36
in the diagram below. In general, the queue model with a transparent and “trustless” ledger
management process remains consistent with the design. Due to its public blockchain foundation,
PoC implementation results. The criteria applied can EVM inherently provides transparency between
be tailored to the business process, ensuring that participants. Privacy concepts are added on top
transactions meeting these criteria are settled on a of the public blockchain layer of EVM with various
gross basis. The primary difference lies in the queue solutions depending on the specific requirements. In
management approach, which involves a centralized the proof of concept (PoC), in addition to on-chain
queue. transaction data, Confidential UTXO with Notary,
which fundamentally resembles the working method
Figure 37. Queue Management Flow for Further
of R3 Corda, was also explored. Confidential UTXO
comprises off-chain components and a UTXO
Exploration
pattern layered on top of EVM. Integrated privacy
solutions using Zero-Knowledge Proofs (ZKP) will
also be explored in further detail below.
The privacy criteria tested in the PoC are: 1) Only
the sender and receiver should be aware of the
transaction, and 2) Other parties should not be able
to detect the transaction being added to a block
from any particular party. To meet the first criterion,
Kaleido Hyperledger Besu leverages a combination
of Besu nodes processing encrypted data and a
private data manager that sends decrypted data on
a peer-to-peer basis. However, since the blockchain
36. Global state model is a model in which all system components have access to the same set of data.

generates an event for each transaction, the details Validators will validate transactions without knowing
of the encrypted transactions in the block can still the contents of those transactions. To ensure that
be seen through event subscriptions, thereby failing the tokens added comply with the rules, verification
to meet the first criterion in this model. is stored in smart contracts relying on the ZKP
principle.
The privacy model explored in the PoC is
Confidential UTXO utilizing a Notary, which In Figure 38, the fund transfer conducted by the
conceptually aligns with R3 Corda. However, this Bank relies on an additional component, the ZK
model requires an enterprise version of the EVM Prover, to generate components ‘a’ and ‘b’, which are
blockchain and additional processes to ensure the encryption of tokens 1 and 2 respectively, known
transactions occur. The difference between R3 only to the sender. The sender will create new
Corda and Kaleido Hyperledger Besu in this model components that are known only to the receiver and
lies in the connectivity between nodes, which is observer, allowing both parties to know the value of
point-to-point in R3 Corda and distributed in Kaleido the transaction that occurred.
Hyperledger Besu. Both have their respective
With this solution, Party B cannot determine the
strengths and weaknesses.
number of tokens and their respective values used
Confidential UTXO (whether in R3 Corda or Kaleido by Party A. Party B only knows the new tokens
Hyperledger Besu) uses a Notary to validate the received.
balance update of participants in a transaction.
According to experiments conducted by Kaleido,
However, the centralized role of the Notary
this process adds approximately 2 seconds to each
introduces a single point of failure, leading to the
transaction. Additionally, there are components that
proposal of an alternative solution, Zero-Knowledge
need to be added according to the variables that
Proof (ZKP), which has emerged within the EVM
require verification and the parties involved.
community. The ZKP privacy model can meet both
privacy criteria (points 1 and 2) while maintaining An essential component of this solution is the
the multi-validator concept within the blockchain zero-knowledge circuit, implemented through a
network. This model is relatively new and continues combination of mathematical operations. This
to evolve in industry practices. component generates an output in the form of a
hash of the data, which is then processed into a
The ZKP method under consideration still uses
block.
the UTXO structure to store participants’ tokens.
Figure 38. Kaleido’s Privacy Model Concept for Further Exploration

APPENDIX
H. poc SCENARIO TOPICS
Table 4. PoC Scenario Topics

APPENDIX
I. load test
1. Scope and Results of Load Test node, non-validating notary node, and network map
node. Each wholesaler bank cluster consists of 1
The load test results were obtained using the (one) wholesaler node. Due to the non-validating
Locust Dashboard and AWS CloudWatch. Due to nature of the notary, it is not required to validate
the limitations and time constraints of the PoC, the transactions, resulting in improved performance.
load test primarily focused on meeting the threshold Similarly, the Kaleido Hyperledger Besu network
consistent with the typical traffic of wholesale consists of 1 (one) Bank Indonesia node cluster
payment systems, approximately 30 transactions and 3 (three) wholesaler bank clusters. However, in
per second (tps). Both technologies successfully the Kaleido Hyperledger Besu network, the Bank
met this threshold, with R3 Corda recording 37 Indonesia cluster does not include notary or network
tps and Kaleido Hyperledger Besu achieving 39 map nodes. Instead, the wholesaler bank clusters
tps. It is important to note that further exploration serve as validators. Kaleido Hyperledger Besu also
with additional time and resources is necessary employs a combination of off-chain and on-chain
to fully assess the maximum capabilities of both processing when executing logic on the network,
technologies. Additionally, the load test results are which can positively impact performance.
influenced by multiple factors, including the type of
distributed ledger technology (DLT) used, as well as For load testing, the minimum configured AWS
other elements such as middleware, infrastructure cloud infrastructure was utilized, as depicted in
capacity, and configuration settings. Figures 39 and 40. The on-premise configuration
was not explored in the PoC. In the future,
infrastructure configurations should be designed
2. R3 Corda and Kaleido Hyperledger according to specific performance requirements,
Besu Load Configuration when whether on-premise or cloud-based.
Performing Load Test
In the proof of concept (PoC), the R3 Corda network
comprises 1 (one) Bank Indonesia node cluster
and 3 (three) wholesaler bank clusters. The Bank
Indonesia cluster includes observer node, KDR
node, provider node, regulator node, administrator
Figure 39. R3 Corda Infrastructure on AWS For Wholesale Participant Clusters

Figure 40. Kaleido Hyperledger Besu Infrastructure on AWS For Wholesale Participant Clusters
Both platforms require further optimization to handle to refinement of consensus methods, application
the potential for increased transaction loads. This architectures, and potential scalability solutions
can be done in synergy across various components (such as channels, data sharding, and others).
ranging from network design and hardware specs

list of AUTHORs
Coordinator:
Endang Trianti (Assistant Governor/DPID),
Dicky Kartikoyono (Assistant Governor/DKSP)
Contributor:
Rohadi Triatmono (Executive Director/DPID),
Ryan Rizaldy (Director/DKSP),
Yudi Muliawirawan Sugalih (Deputy Director/DPID)
Writer Team:
Setyo Kuncoro, Bagas Aji Pratama, Kevin Eza Rizky, Timothy Thamrin Andrew H. Sihombing,
Sirria Panah Alam, Dewi Septina Br Pelawi, Bijak Antusias Sufi, Faradilla Azranur, Dian Nofitri,
Annisa Muzdalifa
Technical Team:
Workstream 1 Project Garuda:
Novi Maryaningsih, Kusuma Ayu Kinanti, Nenden Endah Sari, Akhmad Ginulur Pangersa,
Moh. Nuryazidi, Yudha Wastu Prawira, Ivan Devara, Najibullah Ulul Albab, Abhirama Budiawan,
Adinda Diyah Ayu Permata Sari, Ridha Nur Huzaifah, Ruth A Cussoy Intama, Afaf Munawwarah,
Angga Puspa Hapsari, Yoga Aroyandi

Setyo Kuncoro, Bagas Aji Pratama, Kevin Eza Rizky, Timothy Thamrin Andrew H. Sihombing,
Sirria Panah Alam, Dewi Septina Br Pelawi, Bijak Antusias Sufi, Faradilla Azranur, Dian Nofitri,
Annisa Muzdalifa, Ngadino, Muhammad Arif Sultoni, Prihantojo, Istianto Utomo,
Suryo Pranoto Utomo, Johannes Andrew Kristiandi

Lisa Rienelda Irsal, Faried Caesar Nugroho, Charvin Lim, Berly, Renold Abdi
Acknowledgements and appreciation were also conveyed to Consultant, Technology Partner,

Cloud Provider, and Cloud Implementator
BANK INDONESIA
Jalan M.H. Thamrin No.2, Jakarta – 10350, Indonesia


CBDC - Project Garuda

Uploaded by

Copyright:

Available Formats

CBDC - Project Garuda

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CBDC - Project Garuda

Uploaded by

Copyright:

Available Formats

Proof of Concept (PoC) Report

Wholesale Rupiah Digital

This publication is available at Bank Indonesia website (www.bi.go.id).

© Bank Indonesia 2024. All rights reserved.

Wassalamu’alaikum warahmatullahi wabarakatuh

Jakarta, December 2024

v Project Garuda: Proof of Concept Report | DECEMBER 2024

Wassalamu’alaikum warahmatullahi wabarakatuh

Jakarta, December 2024

Project Garuda: Proof of Concept Report | DECEMBER 2024 vi

Wassalamu’alaikum warahmatullahi wabarakatuh

Jakarta, December 2024

vii Project Garuda: Proof of Concept Report | DECEMBER 2024

Central bank digital currency answering 3 (three) key

Project Garuda: Proof of Concept Report | DECEMBER 2024 1

1.1. BACKGROUND The Rupiah Digital’s potential to strengthen

Project Garuda: Proof of Concept Report | DECEMBER 2024 3

in January 2023, which included public input on 1.2. OBJECTIVE

4 Project Garuda: Proof of Concept Report | DECEMBER 2024

Figure 5. Money Supply Process at wRD

5. A node is a representation of a participant or party in a DLT network.

Project Garuda: Proof of Concept Report | DECEMBER 2024 5

2.1. POC STAGES ,, wRD PoC involves Project Garuda Workstream,

6 Project Garuda: Proof of Concept Report | DECEMBER 2024

Bank Indonesia Bank Indonesia Participant

KDR Node Validating Node

Administrator Node Non-Validating Node

Given the complexity of the DLT system, the

2. Digital Asset Layer: Describes digital assets

Project Garuda: Proof of Concept Report | DECEMBER 2024 7

Figure 8. Issuance and Redemption wRD Platform Integrated with BI-RTGS

8 Project Garuda: Proof of Concept Report | DECEMBER 2024

Project Garuda: Proof of Concept Report | DECEMBER 2024 9

3.1.1.3 FUND TRANSFER

1. Transaction processing occurring in real-time

10 Project Garuda: Proof of Concept Report | DECEMBER 2024

The limit feature is parameterized to allow

12 Project Garuda: Proof of Concept Report | DECEMBER 2024

Project Garuda: Proof of Concept Report | DECEMBER 2024 13

Figure 14. Web App View on Kaleido Hyperledger Besu Solution

3.3.6. INTEGRATION, platform, data is stored in a relational database. The

14 Project Garuda: Proof of Concept Report | DECEMBER 2024

,, R3 Corda employs a unique consensus mechanism

Project Garuda: Proof of Concept Report | DECEMBER 2024 15

16 Project Garuda: Proof of Concept Report | DECEMBER 2024

Project Garuda: Proof of Concept Report | DECEMBER 2024 17

18 Project Garuda: Proof of Concept Report | DECEMBER 2024

5.1 FINDING 5.2 NEXT STEP

The implementation of wRD on DLT

20 Project Garuda: Proof of Concept Report | DECEMBER 2024

Table 1. List of Potential DLT Platform

22 Project Garuda: Proof of Concept Report | DECEMBER 2024

Table 2. PoC Focus Detail

Project Garuda: Proof of Concept Report | DECEMBER 2024 23

Figure 19. Destruction on R3 Corda UTXO

4. Redemption with RTGS Triggered

24 Project Garuda: Proof of Concept Report | DECEMBER 2024

Project Garuda: Proof of Concept Report | DECEMBER 2024 25

Figure 22. Bank Indonesia’s R3 Corda Cluster Configuration on AWS Infrastructure

Figure 23. Participant’s R3 Corda Cluster Configuration on AWS Infrastructure