Reimagining government payouts with programmable money (p2.)

By Paul Hong Tay and Sheikh Salim

In our previous article, we discussed the background behind our Project Orchid trial on the use of Purpose-bound Money (PBM), a tokenised digital currency for government voucher payouts.

In this article, we will share in detail about the trial, including the core decisions, parties and accounts, smart contracts, processes, our user journey design, and trial results.

Overview of Trial

In this trial, we worked with DBS as a bank partner to realize Singapore’s first tokenised digital currency, Digital Singapore Dollar (DSGD), and make the SGD cash payments back to the merchants. The following diagram illustrates the broad overview:

Goals

As part of the CBDC retail trial, the OGP trial aims to achieve the following goals:

1. Demonstrating faster payouts to merchants — This is achieved as merchants directly receive DSGD for any vouchers redeemed. While we are aware of the caveat that the DSGD ecosystem has to be fully developed first to achieve this overall ambition, it will still be helpful in informing how this ecosystem should be designed and developed in future trials and developments.
2. Demonstrating the feasibility of adopting smart contracts for Government campaigns — Government campaign organisers should be able to easily define and enforce their voucher logic (e.g. targeted merchants, specific timeframe) and issue vouchers to their targeted users. If vouchers are used outside of the terms of the smart contract (e.g. at merchants not participating in the scheme), the transaction should fail.
3. Demonstrating interoperability for voucher schemes — In the long term, recipients should have the freedom to choose their own wallet applications to access Government issued PBM tokens. Campaign organisers should also be able to easily specify their own required voucher logic without the need to re-invent existing voucher systems.
4. Ease of conversion between DSGD and SGD — This is needed to promote the use of DSGD. As DSGD is not a legal tender yet, we would need an efficient way to convert DSGD back to SGD to pay the merchants.

Parties and Accounts

The following are the various parties and stakeholders involved in this trial.

*Fiat money is a government-issued currency that is not backed by a physical commodity, such as gold or silver, but rather by the government that issued it.

Core Decisions

User initiated flow

Since inclusivity is not a key goal of this trial, we have scoped the trial strictly toward digital vouchers. Under this new scope, we have modified the user flow from that of the original RedeemSG solution, where transactions are designed to be merchant-initiated and where vouchers do not have recipients.

In this new approach, we decided against the traditional RedeemSG flow in place of a user-initiated one — akin to existing payment solutions such as PayNow. We made this change with the assumption, at this juncture, that there would be no paper fallback for vouchers. This also opens up the possibility of future integrations with SGQR — a well-adopted, unified payment QR code scheme.

Wallet-Based Approach (Fungibility)

Since the focus area has been scoped towards digital vouchers, we found that offering a fungible wallet concept made more sense since it allows for a greater degree of freedom for users to utilise their vouchers. Ideally, we would want to approach the mission of achieving purpose by being binded to money rather than set denominations of vouchers. We will discuss in greater detail future improvements in our second article.

System complexity hidden from the Merchants

Another core design decision made was to keep the concept of PBMs completely opaque to merchants. In this approach, merchants need not have any knowledge of PBM tokens, instead receiving only DSGDs. This approach is similar to RedeemSG, where merchants are only concerned with payouts to their bank accounts rather than the underlying mechanics of the voucher scheme they are part of.

Processes

1. Crypto on-ramp

A crypto on-ramp is a system that allows for economic value to flow from fiat money into crypto assets. It’s a series of steps users can take to exchange fiat for crypto. The digital fiat issuer, in this trial DBS, will operate this service by allowing a PBM Issuer to swap out their fiat currency (SGD) for DSGD. To operationalise this activity, the Digital Fiat Issuer would initialise the DSGD smart contract and mint DSGD. The Digital Fiat Issuer is responsible to ensure that DSGD is backed by SGD with a 1:1 pegging ratio, and that any SGD used by the PBM Issuer will be earmarked to ensure the peg.

For our trial, OGP would fund its DBS Bank Account. Upon receipt of the fiat funds, DBS will earmark the fiat SGD in OGP’s bank account and transfer the respective amount in DSGD to OGP’s crypto wallet.

2. PBM Wrapping and Minting

PBM Minting involves the wrapping of DSGD tokens with an embedded custom logic which forms the purpose aspect of the PBM. Here, PBM issuers will first have to generate a smart contract (PBM Contract) and set up the desired redemption logic and pegging ratio, as well as provide the required DSGD tokens to be escrowed by the contract. In the context of this trial, the logic is scoped to merchant list, expiry date, and campaign metadata — which form the main requirements in 8.2.2.

For each PBM mint, an equivalent amount of DSGD is held in the PBM contract, functioning as a decentralised escrow. These funds are held and remain unclaimed until:

1. A redemption within the logic specified (i.e. approved merchant list) is being made.
2. Timelock for campaign expiry is reached, thereafter allowing the issuer to revoke the DSGD held by the contract.

The processes mentioned above will be streamlined, simplified, and made more accessible through RedeemX, a separate version of RedeemSG’s, campaign organiser portal. The outcome of this is similar to what we are currently doing for the CDC campaign, where we have vouchers offered to residents. These vouchers have an expiry date and can only be used on an approved merchant list. The main difference now is that the enforcing logic is hosted on a trustless contract in the blockchain, as compared to a trusted central server such as that of RedeemSG’s.

3. PBM Unwrapping & DSGD Fulfilment

As discussed in the previous steps, the PBM contract functions as a trustless and transparent escrow in the fulfilment of PBM to DSGD tokens. PBM tokens are only unwrapped into DSGD once the correct redemption requirements, specified by the issuer, take place.

The following explains the steps for unwrapping during a successful PBM token redemption.

1. DSGD tokens that the issuer escrowed in the PBM contract are released to the PBM recipient (i.e. merchant).
2. PBM tokens used for redemption (from receiver/caller) are burned from the caller’s wallet (in the same atomic transaction) to reduce the overall PBM token supply and maintain PBM to DSGD pegging.

For our trial, participants would visit a merchant, purchase an item and use the RedeemX web application to make payment to the merchant. Upon pressing Pay, PBM tokens will be deducted from their crypto wallet, and DSGD will be added to the merchant’s crypto wallet following the aforementioned 3-step process orchestrated by the PBM contract.

4. Crypto off-ramp

A crypto off-ramp is the exact reverse of an on-ramp. It’s a mechanism that allows for economic value to flow from crypto assets back into fiat money. It’s the side of the bridge that allows users to cash out of crypto, and into the fiat space. The Digital Fiat Issuer will operate this service by allowing a PBM Issuer/DSGD Recipient to swap out their DSGD for fiat currency (SGD). The Digital Fiat Issuer is responsible for ensuring they can fulfil all off-ramp requests. This is done by burning DSGD and transferring the SGD equivalent from the previously earmarked account, ensuring the 1:1 pegging ratio at all times.

For our trial, DBS will run a daily job to burn all DSGD from the merchant’s crypto wallet and transfer the SGD equivalent back to the merchant’s bank account. The outcome of this is similar to what is being done by RedeemSG, where at the end of each day vouchers redeemed from each merchant are fulfilled with the respective equivalent SGDs to the merchant’s bank account via Fast and Secure Transfers (FAST).

User Journey

The following details the user experience for the different parties involved in the Project Orchid Trial. Note that these are designs catered to the context of the trial.

PBM Issuer Experience (Campaign Organiser)

As described in previous sections, token minting requires the issuer, in this case the campaign organiser, to shore up for an equivalent amount of DSGD. Essentially, issuers will need to already have the required DSGD tokens that they wish to wrap a purpose to. The following illustrates the token flow.

PBM Holder Experience (Members of the Public)

1. Onboarding

The PBM holder (akin to a traditional voucher holder) will sign up for a campaign with the PBM Issuer. The RedeemX platform will then create a crypto wallet for this holder and map this wallet to an agreed-upon identifier (e.g. mobile phone number, NRIC, etc.). The holder will then be sent a unique link via SMS. This link will contain all the necessary information to access this created wallet.

While this flow is convenient, it will not be a permanent fixture. The grand goal would be to have the concept of a relatively universal wallet (along with relevant identification-related infrastructures) for holders, such that a single wallet could be used to make claims for different PBM campaigns across different schemes.

2. Payment

The transaction experience will be similar to that of a typical online payment flow, as follows:

Payment Flow

Merchant View

The interaction between the PBM holder, the merchant contract, and the token contract can be summed up as follows:

PBM Redeemer Experience (Merchants)

1. Onboarding

Merchants will sign up with the RedeemX platform, where their bank account numbers will later be sent to the partnering bank (in this case DBS) for the creation of a crypto wallet. Upon creation, the wallet address will be returned to RedeemX, and these addresses will be added to the “approved” merchant list within the PBM contract of a particular campaign. Merchants will then be provided a link for them to access their wallets via the same RedeemSG Merchant interface.

Note: For the context of this trial, merchants would have to have an existing bank account with that of the partnering bank, DBS. This again will be expanded further to be more interoperable with other banking arrangements in the future.

2. Payouts

In the previous article, we briefly discussed the concept of off-ramping. At the end of the day, DBS will run a job and transfer all the DSGD from the merchant’s crypto wallet back to DBS’s crypto wallet, hence conducting an off-ramp. After-which, these DSGD tokens will be burned from circulation, and the equivalent earmarked SGD will be released back into the respective merchant bank accounts.

Sample Screens

The following outline the 4 main steps when generating a payment to a merchant:

Results

In the final section, we will outline the results of our trial in relation to our trial goals.

1. Demonstrating faster payouts to merchants

How the goal is achieved: Merchants receive DSGD directly once a voucher transaction takes place, as the PBM converts directly into DSGD as per the logic of the PBM smart contract.

Areas to be worked through: While merchants receive DSGD immediately, for DSGD to be useful on its own, it would need to be accepted more widely.

This requires it to either be more widely in circulation — via a larger and more widely accepted ecosystem around it — or for legislation to formally designate it as legal tender.

2. Demonstrating feasibility of adopting smart contracts for government campaigns

How the goal is achieved: We have demonstrated that it is relatively feasible to use the mechanism of a PBM smart contract to achieve the requirements of government campaign organisers — such as ensuring PBM token/voucher expiry and targeting specific merchants.

Areas to be worked through: While it is technically possible to provide PBM issuers, in this case, government campaign organisers, with the ability to write and deploy their own smart contracts via a contract factory, it is unclear what the wider adoption would look like.

For instance, not all PBM issuers would have the technical capability to do so. To promote wider adoption, we may have to provide a portal through which PBM issuers specify their contract requirements and provide PBM “templates” that make it easier for the PBM issuer.

3. Demonstrating interoperability for voucher schemes

How the goal is achieved: As mentioned above, while building the DSGD smart contract, we ensured it was easily interoperable between government and commercial use cases and that recipients could still access the same tokens via crypto wallet apps.

Areas to be worked through: For a wider rollout and a more production-ready system, there should ideally be the same token standard across commercial and private use cases — e.g. whether it be ERC 20 or ERC 1155. The choice of what token standard would work best for Retail CBDC is something that would need to be worked through in tandem with other decisions mentioned throughout this article.

4. Ease of conversion between DSGD and SGD

How the goal is achieved: As mentioned previously, this is achieved as the DSGD Issuer (in this case DBS) handles the conversion on the merchant’s behalf of DSGD back to SGD at the end of the day via a batch job.

Areas to be worked through: Ideally, the DSGD Issuer could explore ways in which the conversion could be done on a more real-time basis.

5. Feasible migration to Web3 Infrastructures

How the goal is achieved: Generally, the migration has been demonstrated to be relatively feasible, with added caveats. Operating costs as a voucher management platform provider (i.e. RedeemSG) went down as a result of this migration.

Areas to be worked through: However, we also note that the same guarantees for transaction reliability went down when adopting a public/permissionless networking approach. A great deal of monitoring is done to :
1. Ensure transactions reach a consistent state
2. Ensure users have sufficient gas in place of network congestion

There are also additional UX challenges that surfaced with the permissionless approach, with some harbouring on the topics of user privacy and convenience.

Moving forward in future stages of our trial, we hope to make improvements in areas such as network architectures, user experience, and support for offline vouchers. In the long run, we hope to be able to integrate with government and commercial wallet providers and existing merchant identifiers (such as SGQR/PayNow) to allow for a more seamless user experience.

To read further into the technical design and next steps following our trial, you can check out our github repository. If you have further questions regarding the trial or wish to work with us on your use case, you may contact paul@open.gov.sg.

If what we are doing excites you, join our team on our mission to transform the payments ecosystem in Singapore! We are hiring 🙌

Acknowledgements

Special thanks to the CBDC team for the hard work in making the trial a huge success!

Paul Hong Tay, Senior Product Manager at Open Government Products

Sheikh Salim, Software Engineer at Open Government Products

Talitha Chin, Senior Product Manager at Open Government Products

Pallani Kumaran, Lead Cloud Infrastructure Engineer at Open Government Products