Monetary Authority of Singapore (MAS): Introducing Purpose-Built-Blockchain (PBB) Technology Whitepaper

Introduction

Digital assets refer to the digital representation of value, such as ownership of financial or real-world assets. The digital asset ecosystem has the potential to facilitate more efficient trading, increase financial inclusivity, and unlock economic value. Central bank digital currencies (CBDCs), tokenized bank liabilities, and potentially well-regulated stablecoins, along with a well-designed set of smart contracts, can act as the exchange medium for this new digital asset ecosystem. While initial experiments have shown promise, these new forms of digital currencies, which have gained popularity in blockchain and peer-to-peer currency flow, still need to prove their practicality in surpassing the functionality offered by existing domestic instantaneous payment systems and other electronic payment systems. One major advantage of digital currency is its support for programmability. However, this is an ongoing discussion and debate. Operators need to ensure that programmability does not come at the expense of the ability of digital currency to serve as an exchange medium. The singularity of currency should be maintained, programmability should not restrict the distribution of currency, and lead to the fragmentation of liquidity within the system. This paper provides a technical overview of the concept of purpose-bound money (PBM), which allows money to be directed to a specific purpose without the need to program the money itself. PBM adopts a universal protocol designed to work with different ledger technologies and forms of currency. Through standardized formats, users will be able to access digital currency using their chosen wallet provider. This paper builds upon the PBM concept introduced in MAS’s Orchid project and describes how to extend it to a wider range of use cases.

Background and Motivation

In recent years, digital initiatives aimed at improving operational efficiency and enhancing user experience have gained significant momentum. However, digitization efforts in the financial sector are not without challenges.

Market Diffusion and Fragmentation

The proliferation of payment schemes and platforms adds complexity and challenges that users may face when adopting digital financial services. For example, payment operators often run distribution channels with different characteristics for different schemes. Allowing scheme owners to onboard merchants onto their proprietary platforms is resource-intensive. Meanwhile, integrating with other platforms increases the operational effort of merchants, who will have to train their retail staff to handle and accept different payment schemes.

• Conversation with Ken, Partner at Electric Capital: We are a product-driven VC with a majority of tech-savvy team members.
• Vitalik answers everything: personal interests, AI technology and RWA, encryption narratives such as Layer2
• Reversing the technology? Aptos and Sui are actually consortium chains, their survival depends on the patience of capital.

Private, independent efforts have attempted to integrate these plans into a single platform to simplify the user experience and realize the potential for digitization. However, further efforts are needed to ensure that they are open and interoperable across all plans. These platforms should not be limited to consumers and merchants who subscribe to their ecosystems. Interoperable payment systems will provide greater flexibility and a seamless payment experience for businesses and consumers.

Programmability and substitutability of currency

Unlike traditional account-based ledger systems, digital currencies provide the possibility of programming unique attributes into individual bearer assets and determining how digital currencies are used. However, implementing programming logic directly on digital currencies would modify their properties and acceptance as exchange media. While this approach extends the functionality of digital currencies, it can limit their use as a viable exchange medium if their usage conditions are diverse and dynamic. It also requires the reprogramming of all circulating digital currencies each time new conditions or use cases are required.

Another approach is for digital currency issuers to provide multiple versions of digital currencies, each with different logic programmed into them. However, this approach may not be practical as these digital currencies cannot be interchangeable, which would fragment market liquidity. To understand how to maintain the substitutability of digital currencies and make them freely exchangeable, this paper examines different programming models.

Programming Models

Programmable payments refer to payments that are automatically executed once a set of predefined conditions are met. For example, daily spending limits or periodic payments can be defined, similar to direct debits and regular orders. Programmable payments are typically implemented by setting database triggers or in the form of an application programming interface (API) gateway that sits between accounting ledgers and client applications. These programming interfaces interact with traditional ledgers and adjust bank account balances according to programming logic.

Programmable currency refers to rules embedded within the value store itself that define or restrict the possibility of its use. For example, rules can be defined to make the value store only send to whitelisted wallets or transfer after transaction-level filtering is completed. The implementation of programmable currency includes tokenized bank liabilities and central bank digital currencies. Unlike programmable payments, where programming logic and value are decoupled, programmable currency is self-contained, containing programming logic as well as value storage. When programmable currency is transferred to another party, logic and rules are also moved.

One advantage of programmable payments is that they enable a set of programming logic or conditions that can be applied to different forms of currency. Additionally, programmable currency is self-contained and has the benefit of allowing point-to-point conditional logic transfers between parties. As central banks, commercial banks, and payment service providers around the world explore different central bank digital currencies, tokenized bank liabilities, and stablecoin designs, it is expected that the future financial landscape will be more diverse. Therefore, there is a growing need to ensure that there is a universal framework for interacting with different forms of digital currency and ensuring interoperability with existing financial infrastructure.

The third model, Purpose-Bound Money (PBM), was explored in the initial stages of MAS’s Orchid project, based on the concepts and capabilities of programmable payments and programmable currency. PBM refers to a protocol that specifies the conditions under which underlying digital currency can be used. PBM is an anonymous tool that can be transferred on a peer-to-peer basis without intermediaries. PBM contains digital currency as a value store, as well as programming logic that identifies its purpose based on programming conditions. Once the conditions are met, the digital currency is released, making it unconstrained again.

This can be illustrated by the example of PBM being used as a digital coupon. A coupon comes with a predefined set of usage conditions. The holder of the coupon can present it to a participating merchant in exchange for goods or services (programmable payment function). In some cases, the terms of the coupon scheme allow for transfer between people (programmable currency function). Therefore, a consumer can purchase gift vouchers based on PBM and transfer them to another person who may use it at a participating merchant.

However, unlike regular coupons, PBM restricts how the payer can use PBM, but there are no restrictions on the payee. When a consumer pays for a purchase using PBM, if the usage terms are met, the digital currency is released from the PBM and transferred to the merchant. After that, the merchant can use the digital currency unconstrainedly for other purposes (such as paying suppliers).

Purpose-Bound Money

This section will examine the lifecycle of PBM and the different components that make up PBM. In this section, the key entities and their interactions are outlined, emphasizing their roles in the PBM lifecycle.

System Architecture Overview

The PBM protocol references a four-layer model to describe the technology stack used in digital asset-based networks. The components of the network can be classified into four different layers: access layer, service layer, asset layer, and platform layer, as shown in Figure 2. The programming logic of PBM can be viewed as a service, while digital currency is located in the asset layer. When digital currency is bound to PBM, it spans the service layer and the asset layer.

The design of PBM is technology-neutral and is intended to work across different types of ledgers and assets. PBM is expected to be implemented on both distributed and non-distributed ledgers.

Access layer

The access layer is the layer where users interact with different services through various interfaces.

Service layer

The service layer provides various services related to digital assets. It usually runs on top of the asset layer, enabling users to manage and leverage their digital assets.

Asset layer

The asset layer supports the creation, management, and exchange of digital assets.

Platform layer

The platform layer provides the underlying infrastructure for executing, storing, and achieving transaction consensus.

Components

As shown in Figure 3, PBM consists of two main components: a wrapper that defines the expected use; and a underlying value store that serves as collateral. This design allows existing digital currencies to be deployed for different purposes without changing their native attributes. Once PBM is used for its intended purpose, the digital currency can be used without any conditions or restrictions. The issuer of the digital currency retains control over the digital currency, preventing fragmentation and ensuring ease of maintenance.

PBM Wrapper

The PBM wrapper, implemented in the form of smart contract code, specifies the conditions under which the underlying digital currency can be used. The PBM wrapper can be programmed to allow PBM to be used only for its intended purpose, such as being valid within a specific time period, for specific retailers, or in specific denominations. Once the conditions specified in the PBM wrapper are met, the underlying digital currency will be released and transferred to the recipient. For example, the PBM wrapper can be implemented as an ERC-1155 multi-token smart contract. Section 3.5 shows a possible sequence flow of a PBM design.

Cryptocurrency

Underlying cryptocurrencies are tied as collateral to PBM. When the conditions of PBM are met, the underlying cryptocurrency is released, and ownership is transferred to the target recipient. Cryptocurrencies must fulfill the functions of currency, namely good storage of value, accounting unit and medium of exchange. Cryptocurrencies can exist in the form of CBDCs, tokenized bank debt, or well-regulated stablecoins. For example, cryptocurrencies can be implemented in the form of ERC-20 compatible fungible token smart contracts.

Roles and Interactions

Roles, as a flexible abstraction, can be implemented in many ways. An entity can hold multiple roles, or a role can be performed by different entities.

PBM Creator

This entity is responsible for defining the logic within PBM, minting and distributing PBM tokens.

PBM Holder

This entity holds one or more PBM tokens. The entity can redeem unexpired PBM tokens.

PBM Redeemer

When PBM tokens are transferred, this entity receives the underlying cryptocurrency.

Lifecycle

Regardless of the programming language or network protocol used, PBM design has consistent lifecycle stages to ensure compatibility across different technical implementations. This section provides an overview of the expected functionality of PBM and its related lifecycle stages. Figure 4 shows the different stages in the PBM lifecycle.

Issuance

The PBM lifecycle starts with the issuance stage. Here, the PBM smart contract is created and PBM tokens are minted. Ownership of the cryptocurrency is transferred to the PBM smart contract. The cryptocurrency is now subject to the constraints of the PBM smart contract, which can be implemented using ERC-1155 or equivalent. Use of the cryptocurrency is constrained by the conditions specified in the PBM smart contract, and it is only released when all conditions are met.

Distribution

After PBM tokens are minted, they are distributed by the PBM creator to the intended entities (i.e., PBM holders) for use. PBM holders receive PBM tokens in their wrapped form and can only redeem tokens according to the original conditions set by the PBM creator.

PBM Logic

This component allows users to create complex business conditions while keeping the PBM wrapper streamlined. In our example, this component stores and manages a list of whitelist and blacklist addresses. Here are some of the main features of this component:

1. Add or remove addresses from the whitelist.

2. Add or remove addresses from the blacklist.

3. Check if PBM tokens can be transferred.

4. Check if PBM tokens can be unwrapped.

PBM Wrapper

This component contains the conditions that constrain the underlying cryptocurrency usage. The cryptocurrency can be ERC-20 compatible and may take the form of central bank digital currencies, tokenized bank liabilities, or stablecoins. For illustrative purposes, we assume that the ERC-1155 multi-token standard is used to implement the PBM wrapper. Other standards such as ERC-20, ERC-721, or their equivalents can also be used for implementation. Here are some of the main features of this component:

1. Mint PBM tokens.

2. Burn PBM tokens.

3. Transfer PBM tokens.

4. Interact with the PBM logic component for additional validation.

5. Interact with the PBM token manager for PBM token type management.

Figure 6 shows the interaction between different PBM smart contracts. In the following sections, we present detailed sequence flows for each phase of the PBM life cycle.

PBM Life Cycle: Issuance Phase > Initialize PBM

Figure 7 illustrates the steps to initialize the PBM smart contract. At this stage, the PBM creator provides different parameters to initialize the PBM and set up the connections between different PBM components.

PBM Life Cycle: Issuance Phase > Create PBM Token Type

Figure 8 illustrates the steps to create a new PBM token type. At this stage, the PBM creator can create different token types that represent different values.

PBM Life Cycle: Issuance Phase > PBM Token Minting

After completing the above steps, the PBM creator can begin minting PBM tokens for distribution. Figure 9 shows the steps for minting PBM tokens.

Before the coin minting process, the PBM creator must approve the PBM wrapper smart contract to transfer the right of the digital currency on behalf of the PBM creator. This is a necessary step to run step 7 of the coin minting process.

• Step 1: The PBM creator initiates the batch minting process.

• Step 2: Because coin minting and distribution may occur in a single transaction, the PBM wrapper must call the PBM logic to check if the recipient is blacklisted.

• Steps 4 to 6: Calculate the total number of digital currency tokens required to mint PBM tokens.

• Steps 7 to 10: Transfer ownership of all digital currency tokens to the PBM wrapper as collateral.

• Steps 11 to 14: Increase the supply balance of PBM token type.

• Step 15: Mint PBM tokens.

Whitelist/Blacklist Addresses

PBM can use conditional logic programming to check the set of addresses allowed to receive tokens and which addresses are not allowed to receive tokens. In our example, if the recipient is on the blacklist, PBM tokens cannot be transferred. If the recipient is not on the whitelist, PBM tokens cannot be unwrapped. PBM creators can access the following features throughout the PBM lifecycle. It is important to note that technically, the distribution and transfer phases are the same process, only involving different roles. If PBM is distributed to a whitelist address, PBM will be unwrapped and release digital currency.

PBM Life Cycle: Distribution/Transfer

In the distribution or transfer phase, PBM tokens are transferred in an encapsulated form. The only difference between these two phases is the roles involved. Figure 11 illustrates the steps involved.

The following outlines some key steps and considerations during the transfer of PBM tokens.

• Steps 3 to 5: Check if PBM tokens can be transferred. Additional conditions can be added here. In our example, check whether the recipient has been blacklisted.

• Steps 6 to 8: Check if the PBM can be unwrapped to release the underlying digital currency tokens. Additional conditions may be added here. In our example, the recipient needs to be on a whitelist.

• Step 9: Transfer the PBM token in wrapped form.

PBM Lifecycle: Distribution/Transfer – Transfer Failed

Figure 12 illustrates the steps when PBM token transfer fails. The PBM token is not transferred and remains in wrapped form.

PBM Lifecycle: Redemption Phase

When transferring PBM tokens, if all conditions are met, the PBM token will be unwrapped and release the underlying digital currency tokens to the recipient.

The following outlines some key steps and their considerations:

• Steps 6 to 8: Check if the PBM token can be unwrapped to release the underlying digital tokens. If all conditions are met, the PBM token can be unwrapped. In our example, check if the recipient is already on the whitelist.

• Steps 9 to 11: Calculate the amount of digital currency tokens to be transferred to the recipient.

• Step 12: Burn the PBM token. This step is optional and depends on the requirements of the PBM creator. In some cases, PBM tokens may be retained as memorabilia.

• Steps 13 to 16: Reduce the amount of PBM tokens. In our design, validation of the token expiration date is done in Step 14 instead of Step 7. This is because the token manager is designed to manage all aspects of PBM tokens, according to our design. Others may implement validation in Step 7.

• Steps 17 to 20: The PBM wrapper transfers its ownership of the digital currency tokens to the recipient.

• Step 21: Issue the PBMUnwrap event.

PBM Lifecycle: Expiration Phase > Redeeming Expired PBM Tokens In this phase, a PBM holder attempts to redeem a PBM token where at least one condition has indisputably been violated or has expired, resulting in transfer failure. In our example, the token has expired. The following outlines some key steps and their considerations:

• Steps 6 to 8: Since token expiration validation is implemented in Step 14 of the redemption phase, the PBM token is considered unwrappable.

• Step 14: Validation fails due to token expiration.

PBM Lifecycle: Expired Phase > Revoke PBM

If at least one condition has been indisputably violated or expired, the PBM holder cannot use the PBM token, and the underlying digital currency token remains locked. In our example, the token has expired. The PBM creator can choose to revoke the expired PBM token to recover the underlying digital currency token.

• Step 1: PBM creator initiates the revoke operation.

• Steps 2 to 4: Calculate the amount of digital currency tokens to be retrieved.

• Steps 5 to 8: Revoke and set the token balance to 0.

• Steps 9 to 12: Transfer the digital currency token to the PBM creator.

• Step 13: Issue a PBM revocation event.

Design Considerations

This section discusses some design choices and factors that may affect how PBM is implemented. Interoperability is crucial to ensure that the implementation of PBM by different service providers does not lead to fragmentation of the payment ecosystem. PBM provider running their own proprietary network may create “walled gardens” within their own closed partner ecosystem, which could lead to monopolistic and rent-seeking behavior among PBM providers. If unchecked, this could have adverse effects on consumers who either need to access multiple different systems or pay high intermediary fees to complete transactions. Therefore, PBM technology should be designed from the outset to be interoperable across different platforms, wallets, payment systems, and rails. This will enable PBM recipients to access and use their PBM tokens from government-provided or commercial wallet providers of their choice.

Adopting common standards ensures that PBM tokens are compatible with different wallet service providers. This will enable digital assets to be transferred across different platforms and stakeholders. In addition, implementing efforts and costs can be reduced because the same infrastructure can be reused in multiple use cases. The PBM design in this article is intended to be applicable to various ledger types, including blockchain-based and non-blockchain-based ledger systems. To illustrate the concepts in this article, we provide specific technical implementations as examples. We envision that future PBM implementations may be based on ledger systems that differ from the systems referenced in this article. Service providers need to choose the supported ledger types that best suit their business models and expected use cases.

Digital Currency

In concept, regardless of the type of underlying digital currency, PBM provides a universal framework.

As PBM derives its value from underlying digital currencies, its acceptance, perceived value, and usability are strongly related to the relevant digital currencies. Therefore, it is crucial to consider the reserve assets that support digital currencies as well as their relevant regulatory impacts and compliance requirements. CBDCs, tokenized bank debt, and stablecoins provide different levels of guarantees and are subject to different regulatory oversight. A variant of PBM may exist in the form of purpose-bound tokens, where the underlying digital currency is replaced with tokens representing payment obligations rather than value storage. Although this may serve a similar role in representing claims on debt, settlement is done on a deferred basis rather than on an atomic and real-time basis, thereby carrying the risk of settlement failure.

As the regulatory environment for global digital currencies is still evolving, the regulatory treatment of PBM may differ among jurisdictions. Privacy The composability of PBM design means that PBM wrappers smart contracts can be developed by private sector entities, while using CBDCs issued by central banks as the underlying digital currency. Conversely, government agencies may develop PBM wrappers smart contracts and use tokenized bank debt in the form of private currency as collateral for PBM to support government payments. By separating the roles of PBM creators and digital currency issuers, an arrangement can be established whereby no entity can oversee both the issuance of currency and the manner and location of its use.

As a result, the amount of data held by each institution is limited to the information required to carry out its authorized functions. As an additional safeguard, arrangements may be set up to allow fund transfers to be carried out anonymously by authorized entities. For example, prior to the transfer, PBM conditions can be set to check individual registers separately to ensure that the individual initiating the transfer has the authority to do so. However, in this example, the registration system neither supervises the nature of the transfer nor designates who the recipient is. The registration merely notifies whether one party is authorized or not.

Policy Considerations

PBM can be used by both official and private entities. Although the technical implementation of PBM may be similar across various use cases, additional policy considerations may be required when developed, managed, and used by official entities.

There are different views globally on what constraints should be placed on how individuals spend money. For example, during the distribution of relief money during the pandemic, some jurisdictions allow relief money to be used to purchase financial products and services, while others restrict their use. Meanwhile, some central banks have indicated that they will not impose any restrictions on the use of digital currencies. Therefore, when designing PBM-based solutions, policymakers need to consider who should issue and distribute digital currencies, as well as the conditions for designating their use.

Numerical Preparedness

The introduction of new forms of payment tools may change the user experience and require some adjustment and adaptation. This may be positively viewed by some users and seen as a disruption by others. For example, some merchants and citizens may be more accustomed to using paper coupons and may not be familiar with mobile applications. This may hinder the adoption of PBM by merchants and citizens.

Therefore, the digital proficiency of stakeholders should be taken into account in the design of the PBM scheme. It is particularly important to keep the user experience intuitive and accessible for vulnerable populations.

One approach is to provide a simplified user experience from the outset, while abstracting away the complexity of the need for users to manage their own keys to access digital currency or PBM. In addition, PBM can be designed to interoperate with existing payment rails, reducing the friction of last-mile statutory settlement and merchant acceptance.

Secure Programming

Given the heavy reliance on smart contract code, establishing a governance framework to ensure code safety as part of the software deployment process is critical. This can be achieved through participation by trusted entities responsible for verifying logic correctness, assessing and preventing potential vulnerabilities and providing standardized oracle data.

This framework should be applied both at the digital currency layer and at the PBM wrapper smart contract level. This is especially important when PBM creators desire to integrate complex logic into components, such as delayed transfer or supply chain payment management. To proactively mitigate potential system security risks, such as the introduction of malicious code, independent audits are strongly recommended. In addition, for distributed ledger-based networks, a trusted third-party agency can be hired as an “oracle” to provide reliable external data inputs to the network.

Potential Uses of PBM

This section provides some examples of how PBM might be used.

Prepaid Packages

Consumers may lose their already prepaid deposits because payment is made to purchase goods and services that will be delivered in the future if the merchant they are dealing with goes out of business. PBM can be used when companies need to collect fees as a guarantee before manufacturing goods or providing services. PBM can solve the risk of undelivered goods by including payment conditions, ensuring that companies fulfill their obligations before “taking” the amount committed by consumers in advance. After the service is completed, the withdrawal of funds can be automatically triggered (directly deducted from the consumer’s PBM e-wallet). Although companies cannot obtain fees in advance, they have a guarantee that they will receive payment once the service has been provided.

Online Business

When shopping online, consumers usually need to pay for the products they want to purchase in advance. After the payment is completed, the product will be sent to the consumer. To mitigate the risk of non-delivery or non-payment, consumers and merchants can use various arrangements. Forms of credit card and prepayment can protect merchants, but not consumers. Meanwhile, cash on delivery arrangements may be beneficial for consumers, but not guaranteed for merchants, especially for perishable items such as food that cannot be reused. PBM provides an alternative solution and provides guarantees to both merchants and consumers, with funds transferred when service obligations are fulfilled.

Contract Agreements

When a home buyer begins the process of applying to purchase a property, there are different milestone events that require payment. A PBM can be created based on the property sales terms. The terms can be defined to release funds when milestones are met during different stages of the property development or sales process. In practice, a PBM can be based on a standard template that is commonly used by home buyers.

Commercial Leasing

When leasing a property, landlords may require tenants to provide a security deposit as a form of protection against any damage or unpaid rent. This deposit is held by the landlord during the lease and returned to the tenant at the end of the lease, provided the tenant has fulfilled all obligations under the lease agreement. If the tenant causes damage to the property beyond normal wear and tear, or they fail to pay fees under the lease agreement, the landlord can deduct the cost of repairs or unpaid rent from the security deposit before returning any remaining funds. A PBM can fulfill the role of a security deposit when it is possible for all parties to fully refund the security deposit. In case of dispute, the PBM can be suspended until the dispute is resolved.

Trade Finance

Trade finance products help businesses manage the risks and complexities of international trade transactions. To facilitate trades involving multiple parties, different borders, and currencies, trade finance providers offer a range of services such as letters of credit, bank guarantees, and bill collection. These services help ensure secure and efficient payments, while also providing protection against payment defaults or fraud. Trade finance instruments can be modeled as a PBM, with payments automatically made when service obligations are fulfilled. They may become negotiable instruments that can be transferred between parties.

Donation

Potential donors may hesitate to contribute to social causes because they are unsure if their donations will reach the intended beneficiaries and be used for the intended purposes. Additionally, donating to overseas beneficiaries in remote areas is likely to involve multiple intermediaries since economically viable options for remittance are limited. As a result, the beneficiaries may end up receiving only a small portion of the original donation value. PBM can be used to increase transparency and accountability. For example, PBM can be used to ensure that only intended beneficiaries are able to use the money and only under certain conditions.

Cross-border payments

Cross-border payments are subject to policy and regulatory requirements, such as capital flow management and macro-prudential policy measures, as well as anti-money laundering (AML) and countering the financing of terrorism (CFT) standards. Compliance with these measures and standards can entail high costs and processing delays. By embedding existing policy requirements as conditions into PBM, compliance checks can be automated, which significantly reduces costs and improves the efficiency of cross-border payments. This design-for-compliance approach may help achieve regulatory and policy interoperability in the context of the G20 High-Level Principles for Cross-Border Payments.

Future work

The development of digital currencies is evolving rapidly. In this section, potential future research areas will be discussed.

Account abstraction

Currently, most retail users are not familiar with the use of digital asset wallets, which may increase the risk of being exploited by malicious actors. To mitigate this risk, account abstraction, also known as smart contract wallets, can be used to improve the user experience and security of digital asset transactions. This technology enables features such as account recovery, transaction restrictions, and freeze of lost accounts without requiring users to understand the underlying technology.

Offline payments

Future research may include exploring the use of PBM for non-smartphone forms (e.g., cards) and offline payments to reduce reliance on network connectivity. This is aimed at improving financial inclusion, allowing people to participate without the need for smartphones or digital payment services.

Name Addressing

Currently, phone numbers can be used as proxies for bank account numbers for fund transfers. In cases where there is no bank account number, name addressing services provide a proxy for a wallet address by mapping it to a meaningful identifier. This can provide a better user experience and ensure that transfers are sent to the intended recipient.

Conclusion

This article presents the concept of PBM as a universal protocol for interacting with different forms of exchange media and emphasizes how digital currencies can support business and policy objectives without modifying their native attributes. Although PBM was originally introduced through the Orchid project of the Monetary Authority of Singapore, we envision that the technical design concept may be applicable to a wider international audience.

To achieve wider adoption, the PBM technology framework is designed and developed in an open-source manner with participants from different organizations. This work is based on the foundational work that began with the Orchid project and is the collective contribution of central banks, financial institutions, and fintech companies from around the world.

It is worth noting that this article does not seek to advance any specific policy objectives or endorse any particular technical solution. The authors of this article make no representation or warranty as to the performance or adequacy of the proposed solution. The examples provided in this article are purely for illustrative purposes. As policy considerations and environments are unique to each jurisdiction, decision makers need to evaluate combinations of financial infrastructure and technology that best meet their objectives.

It is foreseeable that additional opportunities may be introduced in the future in the digital currency and digital asset ecosystems and bring risks that need to be addressed in future work. Members of the global fintech community are encouraged to build based on the concept introduced in this article and provide feedback to the global fintech community.

References

1. Monetary Authority of Singapore (MAS). (2022, October 31). Project Orchid: Programmable Digital SGD [PDF]. Retrieved from https://www.mas.gov.sg/-/media/mas-medialibrary/development/fintech/project-orchid/mas-project-orchid-report.pdf

2. Lee, A. (2021, June 23). What is Programmable Money. Retrieved from https://www.federalreserve.gov/econres/notes/feds-notes/what-is-programmable-money20210623.html

3. Repubblica Italiana [Republic of Italy]. (2019, April 19). Decree 19 aprile 2019: Utilizzo della Carta Reddito di Cittadinanza [Decree 19 April 2019: Use of Citizenship Income Card].Gazzetta Ufficiale. Retrieved from https://www.gazzettaufficiale.it/eli/id/2019/06/26/19A04119/sg

4. Reserve Bank of India. (2022, October 7). Concept Note on Central Bank Digital Currency,Item 5.7: Programmability. Retrieved from https://rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlBlockingge=&ID=1218#CP57

5. Blockingnetta, F. (2023, January 23). The digital euro: our money whenever, wherever we need it [Speech]. Presented at the Committee on Economic and Monetary Affairs of the European Blockingrliament. Retrieved from https://www.ecb.euroBlocking.eu/press/key/date/2023/html/ecb.sp230123~2f8271ed76.en.html

6. Bank for International Settlements. (2019, April 1). “Official sector” in “Glossary”. Retrieved from https://www.bis.org/statistics/glossary.htm?&selection=272&scope=Statistics&c=a&base=term

7. Carstens, A. (2023, February 22). Innovation and the future of the monetary system[Speech]. Presented at the Monetary Authority of Singapore.Retrieved fromhttps://www.bis.org/speeches/sp230222.htm

8. Adrian, T., & Mancini Griffoli, T. (2023, June 19). The Rise of Blockingyment and Contracting Platforms [PDF]. Retrieved from https://www.imf.org/-/media/Files/Publications/FTN063/2023/English/FTNEA2023005.pdf

9. Bank for International Settlements. (2023, June 20). III. Blueprint for the future monetary system: improving the old, enabling the new [PDF]. Retrieved from https://www.bis.org/publ/arpdf/ar2023e3.pdf

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.