Singapore MAS: Detailed Explanation of Purpose-Bound Money (PBM) Technology White Paper

Introduction

A digital asset is a digital representation of value, such as ownership of a financial asset or a real economic asset. The digital asset ecosystem is expected to facilitate more efficient transactions, improve financial inclusion, and unlock economic value. Central bank digital currency (CBDCs), tokenized bank liabilities, and well-regulated stablecoins, combined with well-designed smart contracts, can serve as a medium of exchange for this new digital asset ecosystem. Although initial trials show potential, the utility of these new forms of digital currencies still needs to be proven to be superior to existing electronic payment systems. One of the great benefits of digital currencies is that they support programmatic functionality, but this is still a controversial topic. Operators need to ensure that programmatability does not compromise the ability of digital currencies to be used as a medium of exchange. The singularity of the currency should be maintained, and the programmatic nature should not limit the distribution of the currency, leading to the fragmentation of liquidity within the system.

This article provides a technical overview of the concept of purpose-bound currency (PBM), which allows currency to be directed towards specific purposes without the need to program the currency itself. PBM uses a universal protocol designed to work with different ledger technologies and forms of currency. Through standardized formats, users can access digital currency using their choice of wallet providers. This article will describe how to extend the PBM concept, first introduced in the Orchid project by the Monetary Authority of Singapore, to broader application scenarios.

! MAS: PBM Technical White Paper

Background and motivation

In recent years, digital initiatives aimed at improving operational efficiency and user experience have made significant progress. However, the digitalization efforts in the financial sector also face challenges.

Market Diffusion and Fragmentation

The increase in payment solutions and platforms has added complexity that users may face when adopting digital financial services. For example, payment operators often run distribution channels with different characteristics for different solutions. Integrating merchants into proprietary platforms consumes significant resources. At the same time, integrating with other platforms increases the operational workload for merchants, who need to train retail staff to handle different payment solutions.

Private, independent efforts are attempting to integrate these plans into a single platform to simplify user experience and realize digital potential. However, these efforts need to further ensure openness and interoperability across all plans. These platforms should not be limited to consumers and merchants subscribing to their ecosystem. Interoperable payment systems will provide greater flexibility, offering seamless payment experiences for businesses and consumers.

The programmability and fungibility of currency

Unlike traditional account-based ledger systems, digital currencies can program unique characteristics into the individual assets they carry and determine how to use the digital currency. However, implementing programming logic directly onto digital currencies alters their properties and acceptability as a medium of exchange. While this approach expands the functionality of digital currencies, it limits their use as a viable medium of exchange if the conditions for use are diverse and dynamic. It also requires reprogramming all circulating digital currencies each time new conditions or use cases are needed.

Another approach is for digital currency issuers to provide multiple versions of the digital currency, each with different programming logic. However, this method may not be practical, as these digital currencies cannot be exchanged for one another, leading to fragmented market liquidity. To understand how to maintain the substitutability of digital currencies, allowing them to be freely exchanged, this article examines different programming models.

programming model

Programmable payments refer to payments that are executed automatically once predefined conditions are met. For example, a daily spending limit or regular payments can be defined, similar to direct debits and recurring orders. Programmable payments are typically implemented by setting up database triggers or API gateways, positioned between the accounting ledger and client applications. These programming interfaces interact with traditional ledgers to adjust bank account balances according to programming logic.

Programmable money refers to the embedding of rules within the store of value itself, defining or limiting the possibilities for its use. For example, you can define rules so that stores of value can only be sent to whitelisted wallets, or transferred after transaction-level filtering is complete. The implementation of programmable money includes tokenized bank liabilities and central bank digital currencies. Unlike programmable payments, programmable money is self-contained, contains programming logic and serves as a store of value. When programmable money is transferred to the other party, the logic and rules move with it.

The advantage of programmable payments lies in the ability to define a set of programming logic or conditions applicable to various forms of currency. Programmable currency is self-contained, allowing for peer-to-peer transfers of conditional logic among parties. As global central banks, commercial banks, and payment service providers explore different designs of central bank digital currencies, tokenized bank liabilities, and stablecoins, the future financial landscape will become more diverse. Therefore, it is necessary to ensure a universal framework for interaction with different forms of digital currency and to ensure interoperability with existing financial infrastructure.

The third model --- Purpose-bound currency ( PBM ), explored during the initial phase of the Orchid project by the Monetary Authority of Singapore, is based on the concepts and capabilities of programmable payments and programmable currency. PBM refers to a protocol that specifies conditions under which the underlying digital currency can be used. PBM is an anonymous instrument that can be transferred peer-to-peer without intermediaries. PBM includes digital currency as a store of value, along with programming logic that identifies its use based on programmed conditions. Once the conditions are met, the digital currency is released and becomes unconstrained again.

This can be illustrated using PBM as an example of digital coupons. The coupons come with a predefined set of usage conditions. Holders can present them to participating merchants in exchange for goods or services ( programmable payment functionalities ). In some cases, the terms of the coupon scheme allow for transfer between people ( programmable currency functionalities ). Therefore, consumers can purchase PBM-based gift vouchers and transfer them to another person who might use it at a participating merchant.

However, unlike ordinary coupons, PBM restricts how the payer can use PBM, but there are no restrictions on the payee. When consumers use PBM to pay for purchases, if the terms of use are met, the digital currency will be released from PBM and transferred to the merchant. Thereafter, the merchant can use the digital currency for other purposes (, for example, to pay suppliers ).

Purpose Binding Currency

This section examines the life cycle of a PBM and the different components that make up a PBM. This section provides an overview of key entities and their interactions, highlighting their roles in the PBM lifecycle.

Overview of the system architecture

The PBM protocol refers to a four-layer model to describe the technology stack used in digital asset networks. Network components can be divided into four distinct layers: access layer, service layer, asset layer, and platform layer. The programming logic of PBM can be viewed as a service, while digital currency resides in the asset layer. When digital currency is bound as PBM, it spans the service layer and the asset layer.

PBM is designed to be technology-neutral and designed to work across different types of ledgers and assets. It is expected that PBM can 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 typically operates above the asset layer, allowing 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 execution, storage, and achieving transaction consensus.

! MAS MAS: PBM Technical White Paper

component

PBM consists of two main components: a wrapper that defines the intended use; and the underlying value storage that serves as collateral. This design allows existing digital currencies to be deployed for different purposes without altering their native properties. Once PBM is used for its intended purpose, the digital currency can be utilized 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

A PBM wrapper implemented in the form of smart contract code that specifies the conditions under which the underlying digital currency is available. PBM wrappers can be programmed so that PBMs can only be used for their intended purpose, such as being valid for a specific period of time, at a specific retailer, in a predetermined denomination. Once the conditions specified in the PBM wrapper are met, the underlying digital currency will be released and transferred to the recipient. For example, a PBM wrapper can be implemented as an ERC-1155 multi-token smart contract.

digital currency

The underlying digital currency bound by PBM is used as collateral for PBM. When the conditions of the PBM are met, the underlying digital currency is released and ownership is transferred to the intended recipient. Digital currencies must fulfill the function of money, i.e., as a good store of value, a unit of account, and a medium of exchange. Digital currencies can exist in the form of CBDCs, tokenized bank liabilities, or well-regulated stablecoins. For example, digital currencies can be implemented in the form of ERC-20 compatible fungible token smart contracts.

! MAS: PBM Technical White Paper

Roles and Interactions

Characters, as a flexible abstraction, can be implemented in a variety of 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 the PBM, minting and distributing PBM coins.

PBM Holders

This entity holds one or more PBM coins. The entity can exchange unexpired PBM coins.

PBM Exchange User

When the PBM token is transferred, this entity will receive the underlying digital currency.

Life Cycle

Regardless of the programming language or network protocol used, the design of PBM has a consistent lifecycle phase that ensures compatibility across different technical implementations. This section provides an overview of the expected functionality of PBM and the relevant lifecycle phases.

Issuance

The PBM lifecycle begins with the issuance phase. Here, the PBM smart contract is created, and PBM tokens are minted. The ownership of the digital currency is transferred to the PBM smart contract. The digital currency is now bound by the PBM smart contract, which can be implemented using ERC-1155 or its equivalents. The use of the digital currency is subject to the conditions specified in the PBM smart contract, and it will only be released when all conditions are met.

Distribution

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

Transfer

At this stage, the PBM token can be transferred from one entity to another in its packaged form according to its programming rules. The transfer phase is optional and depends on the use case. In the case of government-issued (, for example, in learning grants ), the PBM token may not be transferable to other citizens. However, in commercial vouchers (, such as retail mall vouchers ), the PBM token can be transferred to other consumers.

Exchange

All conditions specified in the PBM must be met.