Singapore’s Monetary Authority of Singapore (MAS): Comprehensive explanation of the Purpose Binding Monetary (PBM) technology white paper.

Translation: Spinach spinach!

Source: https://www.mas.gov.sg/publications/monographs-or-information-Blockingper/2023/purpose-bound-money-whiteBlockingper

Introduction

Digital assets refer to the digital representation of value, such as ownership of financial or real economic assets. The digital asset ecosystem has the potential to facilitate more efficient transactions, improve financial inclusion and unlock economic value. Central Bank Digital Currencies (CBDCs), tokenized bank liabilities, and potentially well-regulated stablecoins, combined with a well-designed set of smart contracts, can serve as the exchange medium for this new digital asset ecosystem. While initial experiments have shown promise, these new forms of digital currencies, which are popular in blockchain and peer-to-peer currency flows, still need to demonstrate that they offer greater practicality than existing domestic real-time payment systems and other electronic payment systems. One major benefit of digital currencies is their support for programmable features. 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 currencies to serve as exchange media. Currency singularity should be maintained, programmability should not restrict the distribution of currency, and should not lead to fragmentation of liquidity within the system. This paper provides a technical overview of the concept of Purpose-Bound Money (PBM), which enables currency to be directed towards a specific purpose without the need to program the currency itself. PBM adopts a generic protocol designed to work with different ledger technologies and forms of currency. Through a standardized format, users will be able to access digital currencies using their chosen wallet provider. This paper builds on the PBM concept introduced for the first time in MAS’s Orchid project and describes how it can be extended to a wider range of use cases.

• Monetary Authority of Singapore (MAS): Introducing Purpose-Built-Blockchain (PBB) Technology Whitepaper
• 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

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 for users in 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 very resource-intensive. At the same time, integrating with other platforms increases merchant operational efforts, and merchants will have to train their retail staff to handle and accept different payment schemes.

私人、独立的努力已经试图将这些计划整合到一个单一平台上，以简化用户体验，实现数字化的潜力。然而，这些努力需要进一步确保它们在所有计划中都是开放和互操作的。这些平台不应仅限于订阅其生态系统的消费者和商家才能使用。互操作支付系统将提供更大的灵活性，并为企业和消费者提供无缝支付体验。

货币的编程性和可替代性

与传统的基于账户的账本系统不同，数字货币提供了将独特特性编程到个体承载资产中，并决定如何使用数字货币的可能性。然而，直接在数字货币上实施编程逻辑会修改其作为交换媒介的属性和接受度。虽然这种方法扩展了数字货币的功能，但如果其使用条件多样且动态，就会限制数字货币作为一种可行的交换媒介的使用。它还需要在每次需要新的条件或使用案例时，对所有流通中的数字货币进行重新编程。

另一种方法是数字货币发行者提供多个版本的数字货币，每个货币都有不同的逻辑编程在内。然而，这种方法可能不实用，因为这些数字货币不能互相替换，会使市场的流动性碎片化。为了理解如何保持数字货币的可替代性，使其可以自由交换，本文研究了不同的编程模型。

编程模型

可编程支付指的是一旦满足一组预定义的条件，就会自动执行支付。例如，可以定义每日消费限额或定期支付，类似于直接扣款和常规订单。可编程支付通常通过设置数据库触发器或以应用程序编程接口（API）网关的形式实现，该网关位于会计账本和客户端应用程序之间。这些编程接口与传统账本互动，并根据编程逻辑调整银行账户余额。

可编程货币指的是在价值存储本身内部嵌入规则，定义或限制其使用的可能性。例如，可以定义规则，使得价值存储只能发送到白名单钱包，或在完成交易级别筛选后转账。可编程货币的实施包括代币化的银行负债和中央银行数字货币。不像可编程支付，其中编程逻辑和价值本身是解耦的，可编程货币是自包含的，包含编程逻辑并作为价值存储。当可编程货币被转移到另一方时，逻辑和规则也被移动。

Programmable payments provide an advantage in that they allow for a set of programming logic or conditions that can be applied to various forms of currency. Additionally, programmable currencies are self-contained and have the benefit of point-to-point conditional logic transfer between parties. As central banks, commercial banks, and payment service providers around the globe are exploring 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 an increasing need to ensure that there is a universal framework for interacting with different forms of digital currency and to ensure interoperability with existing financial infrastructure.

The third model – Purpose Binding Money (PBM) – was explored in the initial stages of MAS’s Orchid project, which was based on the concept and capabilities of programmable payments and programmable currencies. PBM is a protocol that specifies the conditions under which the underlying digital currency can be used. PBM is an anonymous tool that can be transferred peer-to-peer without intermediaries. PBM includes 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 and becomes unconstrained again.

This can be illustrated with the example of using PBM as a digital coupon. A coupon comes with a predefined set of conditions for use. The holder of the coupon can present it to a participating merchant in exchange for goods or services (programmable payment feature). In some cases, the terms of the coupon scheme allow for transfers between individuals (programmable currency feature). Therefore, a consumer can purchase a gift card based on PBM and transfer it 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 and the usage terms are met, the digital currency is released from the PBM and transferred to the merchant. The merchant can then use the digital currency unconstrained for other purposes (such as paying suppliers).

Purpose Binding Money

This section examines 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 a digital asset-based network. The components of the network can be classified into four different layers: the access layer, the service layer, the asset layer, and the platform layer, as shown in Figure 2. The programming logic of PBM can be viewed as a service, while the digital currency is located in the asset layer. When the digital currency is bound to PBM, it spans the service layer and the asset layer.

The design of PBM is technology-agnostic and aims to work across different types of ledgers and assets. PBM is expected to be implementable on both distributed and non-distributed ledgers.

Access Layer

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

Service Layer

The service layer provides various services related to digital assets. It typically runs on top of the asset layer, enabling users to manage and utilize 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: the wrapper that defines the intended use; and the underlying value store that serves as collateral. This design allows existing digital currencies to be deployed for different purposes without changing their native properties. 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 is available. The PBM wrapper can be programmed to enable PBM to be used only for its intended purpose, such as being valid within a specific time period, with specific retailers, or at designated 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 for a PBM design.

Cryptocurrency

Underlying cryptocurrencies that are tied to the PBM as collateral. When the conditions of the PBM are met, the underlying cryptocurrency is released and ownership is transferred to the intended recipient. Cryptocurrencies must fulfill the functions of money, namely good stores of value, units of account, and mediums of exchange. Cryptocurrencies can exist in the form of CBDCs, tokenized bank liabilities, 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 can be implemented in various ways as a flexible abstraction. An entity can hold multiple roles, or a role can be executed by different entities.

PBM Creator

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

PBM Holder

This entity holds one or several PBM tokens. This entity can redeem non-expired PBM tokens.

PBM Redeemer

This entity receives the underlying cryptocurrency when the PBM token is transferred.

Lifecycle

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

Issuance

The PBM lifecycle begins 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 achieved using ERC-1155 or equivalent. The use of the cryptocurrency is constrained by the conditions specified in the PBM smart contract and will only be released if 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 the tokens according to the original conditions set by the PBM creator.

Transfer

During this stage, PBM tokens can be transferred from one entity to another in their packaged form, according to their programming rules. The transfer stage is optional and depends on the use case. In government disbursements (e.g. study aid), PBM tokens may not be transferable to other citizens. In commercial vouchers (e.g. retail mall vouchers), PBM tokens can be transferred to other consumers.

Redemption

The redemption stage occurs when all of the specified conditions in the PBM are met. At this point, the PBM tokens are unpacked and ownership of the underlying digital currency tokens is transferred to the receiving entity. The entity can freely use the digital currency tokens, which are subject only to the conditions specified by the digital currency issuer.

Expiration

The expiration stage refers to a situation where a specified condition in the PBM is explicitly violated or expires (e.g. expiration date), rendering the PBM tokens permanently unusable for the PBM holder. Expired PBM tokens can be aggregated and destroyed or “burned” to return the underlying digital currency to the PBM creator. Alternatively, the PBM can be suspended indefinitely to prevent further interaction with the expired PBM.

Sequence Flow

The implementation of PBM can differ in design, method, and technology. In this section, we explore one design where the PBM is divided into three parts, as shown in Figure 5. The following conditions have already been defined for the release of digital currency in this implementation: (1) access control via whitelist and blacklist; (2) expiration date of PBM wrapper; and (3) expiration date of PBM token type.

PBM Token Manager

For example, if the ERC-1155 multi-token standard is adopted, PBM creators can create different PBM token types representing different values (e.g. $1, $2, $5) in the same PBM wrapper. The PBM token manager provides an interface to easily manage different token types and maintain the balance of each token type. Here are some of the main functions of this component:

1. Create PBM token types.
2. Get detailed information about each PBM token type.
3. Increase/decrease the supply balance of each PBM token type.
4. Validate the validity period of PBM tokens.

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 whether PBM tokens can be transferred.
4. Check whether PBM tokens can be unwrapped.

PBM Wrapper

This component contains conditions that constrain the underlying digital currency use. Digital currency can be ERC-20 compatible and may take the form of a central bank digital currency, 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 will present detailed sequence flows for each stage of the PBM lifecycle.

PBM Lifecycle: Issuance Phase > Initialize PBM

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

PBM Lifecycle: Issuance Phase > Create PBM Token Types

Figure 8 illustrates the steps to create new PBM token types. In this phase, the PBM creator can create different token types representing different values.

PBM Lifecycle: Issuance Phase > Minting PBM Tokens

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

Prior to the 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 minting process.

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

• Step 2: Since minting and distribution may be done in a single transaction, the PBM wrapper must call PBM logic to check if the recipient is on the blacklist.

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

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

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

• Step 15: Mint PBM tokens.

Whitelist/Blacklist Addresses

The 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 functions throughout the entire lifecycle of the PBM. It is important to note that technically, the distribution and transfer phases are the same process, only involving different roles. If the PBM is distributed to a whitelist address, the PBM will be unwrapped and release digital currency.

PBM Lifecycle: Distribution/Transfer

In the distribution or transfer phase, PBM tokens are transferred in an encapsulated form. The only difference between these two stages 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, such as checking if the recipient is blacklisted in our example.- Steps 6 to 8: Check if PBM can be unwrapped to release digital token. Additional conditions can be added, such as requiring the recipient to be on a whitelist in our example.- Step 9: Transfer PBM tokens in wrapped form.PBM Lifecycle: Distribution/Transfer – Transfer FailureFigure 12 shows the steps for PBM token transfer failure. PBM tokens are not transferred and remain in wrapped form.PBM Lifecycle: Redemption PhaseWhen transferring PBM tokens, if all conditions are met, PBM tokens are unwrapped to release the underlying digital currency token to the recipient.The following outlines some key steps and considerations.- Steps 6 to 8: Check if PBM tokens can be unwrapped to release the underlying digital token. If all conditions are met, PBM tokens 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 token to be transferred to the recipient.- Step 12: Burn PBM tokens. This step is optional and depends on the requirements of the PBM creator. In some cases, PBM tokens may be kept as souvenirs.- Steps 13 to 16: Reduce the number of PBM tokens. In our design, validation of the expiration date of the token is performed 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: PBM wrapper transfers ownership of its digital currency tokens to the recipient.- Step 21: Issue PBMUnwrap eventPBM Lifecycle: Expiration Phase > Redeem Expired PBM TokensIn this phase, the PBM holder attempts to redeem a PBM token where at least one condition has been indisputably violated or expired, resulting in transfer failure. In our example, the token has expired. The following outlines some key steps and considerations.

Steps 6-8: Because token expiration validation was implemented in step 14 of the redemption phase, the PBM token is considered unpackable.

Step 14: Validation fails due to token expiration.

PBM Lifecycle: Expiration Phase > Revoke PBM

If at least one condition is indisputably violated or expired, PBM holders cannot use PBM tokens, and the digital currency 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 revocation process.

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

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

• Steps 9-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 critical to ensuring that PBM implementation by different service providers does not lead to fragmentation of the payment ecosystem. PBM providers running their own proprietary networks may create “walled gardens” within their own closed partner ecosystems. This could lead to monopolistic behavior and rent-seeking among PBM providers. If left unchecked, this could have adverse effects on consumers who either need to access multiple 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 universal standards ensures PBM tokens are compatible with different wallet service providers. This will enable digital assets to be transferred across different platforms and stakeholders. Additionally, implementation efforts and costs can be reduced as the same infrastructure can be reused across multiple use cases. The PBM design presented in this article is intended to be applicable to various ledger types, including both blockchain-based and non-blockchain-based ledger systems. To illustrate the concepts presented in this article, we provide a specific technical implementation as an example. We envision that future PBM implementations may be based on ledger systems different from the ones referenced in this article. Service providers will need to choose the support ledger type that best fits their business model and expected use cases. Digital currency PBM provides a universal framework conceptually, regardless of the type of underlying digital currency.

As PBM derives its value from underlying digital currencies, its acceptance, perceived value, and usability are strongly tied to the relevant digital currencies. Therefore, it is crucial to consider the supportive reserve assets of digital currencies and their related regulatory impacts and compliance requirements. CBDCs, tokenized bank debt, and stablecoins offer 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 by tokens that represent payment obligations rather than value storage. While this may serve a similar role in representing claims on debt, settlement occurs on a deferred rather than atomic and real-time basis, introducing the risk of settlement failure.

As the global regulatory environment for digital currencies is still evolving, regulatory treatment of PBM may vary across jurisdictions. Privacy The composability of PBM design means that PBM wrappers smart contracts could be developed by private sector entities, using CBDCs issued by central banks as the underlying digital currency. Alternatively, government agencies might develop PBM wrapper smart contracts and use tokenized bank debt in the form of private currencies as collateral to support government payments for PBM. By separating the roles of PBM creators and digital currency issuers, an arrangement can be established where no entity can oversee both the issuance of currency and the way in which it is used and where it is used.

Therefore, the amount of data held by individual entities is limited to the information necessary to perform their authorized functions. As an additional safeguard, arrangements could be put in place so that fund transfers can be made anonymously by authorized entities. For example, PBM conditions could be set up to check individual registries separately before a transfer is made to ensure that the individual initiating the transfer is authorized to do so. However, in this example, the registry system does not supervise the nature of the transfer or specify who the recipient is. The registry only notifies whether a party is authorized or not.

Policy Considerations

PBM can be used by both official and private sectors. While 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 sectors.

There are different views globally on what constraints should be placed on individual spending habits. For example, during the process of distributing relief funds during the pandemic, some jurisdictions allowed relief funds to be used to purchase financial products and services, while others restricted their use. Meanwhile, some central banks have already 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 and specify the conditions under which they are used.

Online Business

When shopping online, consumers typically need to pay for the products they wish to purchase in advance. Once 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 payment such as credit cards and prepayments can protect the merchant, but not the consumer. Meanwhile, arrangements such as cash on delivery may benefit the consumer, but offer no guarantee to the merchant, especially for perishable goods such as food that cannot be reused. PBM provides an alternative solution, offering guarantees to both merchants and consumers, with funds being transferred when the service obligation is 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 sales terms of the property. The terms can be defined to release funds when a milestone is met at different stages of the property development or sales process. In practice, PBMs can be based on standard templates that are universal to home buyers.

Commercial Leasing

When leasing a property, landlords may require the tenant to provide a security deposit as a form of protection against any damages or unpaid rent. This deposit is held by the landlord during the lease term and is returned to the tenant at the end of the lease term, provided the tenant has fulfilled all obligations under the lease agreement. If the tenant has caused damage to the property beyond normal wear and tear, or they have failed 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 assume the role of the security deposit when there is a possibility of full refund of the security deposit by all parties to the lease agreement. In case of disputes, 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. In order to facilitate trade involving multiple parties, across different borders and currencies, trade finance providers offer a range of services such as letters of credit, bank guarantees, and collection of bills. These services help ensure secure and efficient payment, while also providing protection against non-payment or fraud. Trade finance instruments can be modeled as PBMs, with payment occurring automatically when the service obligation is fulfilled. They can become negotiable instruments that can be transferred between parties.

Donations

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 can often involve multiple intermediaries since economically feasible options for remittance are limited. As a result, the beneficiaries may end up receiving only a small fraction of the original donation value. PBM can be used to increase transparency and accountability. For instance, PBM can be used to ensure that only the intended beneficiaries are able to use the money and only when certain conditions are met.

Cross-Border Payments

Cross-border payments are subject to policy and regulatory requirements such as capital flow management and macroprudential policy measures as well as anti-money laundering (AML) and countering the financing of terrorism (CFT) standards. Complying with these measures and standards can result in high costs and processing delays. By embedding existing policy requirements as conditions into PBM, compliance checks can be automated, significantly reducing costs and improving the efficiency of cross-border payments. This design compliance approach may help achieve regulatory and policy interoperability in the context of the G20 roadmap to enhance cross-border payments.

Future Work

The development in the digital currency space is rapidly evolving. In this section, we will discuss potential future research areas.

Account Abstraction

Currently, most retail users are not familiar with the use of digital asset wallets, which can 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 allows for functionalities such as account recovery, transaction restrictions, and freezing 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 form factors (e.g., cards) and offline payments to reduce dependence on network connectivity. This aims to improve financial inclusion by allowing people to participate without the need for smartphones or digital payment services.

Name Addressing

Currently, a mobile phone number can serve as a proxy for a bank account number for fund transfers. In the absence of a bank account number, name addressing services provide a proxy 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 paper proposes the concept of Programmable Bank Money (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 initially introduced through Singapore’s Monetary Authority’s Orchid project, we envision that the technical design concepts may be applicable to a wider international audience.

To achieve broader adoption, the PBM technology framework is designed and developed in an open-source manner, with contributors from different organizations. This paper builds on the groundwork initiated by the Orchid project and is the collective contribution of central banks, financial institutions, and financial technology companies from around the world.

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

It is foreseeable that additional opportunities may be introduced in the development of the digital currency and digital asset ecosystem in the future, bringing risks that need to be addressed in future work. Members of the global financial technology community are encouraged to build on the concepts presented in this paper and provide feedback to the global financial technology community.

References

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

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

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

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

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

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

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

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

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.