I went down the rabbit hole of Purpose Bound Money so you don’t have to
This is a story of my journey exploring and building the Purpose Bound Money (PBM) protocol for Project Orchid.
Check out our project’s website at www.pbm.money and GitHub repository at https://github.com/GovTechSG/cbdc-purpose-bound-money.
The Project Orchid is a multi-phase project initiated by the Monetary Authority of Singapore (MAS) to explore the design and technical aspects of a retail Central Bank Digital Currency (CBDC) system for Singapore.
Understanding Purpose-Bound Money
The Project Orchid whitepaper provides a pretty interesting introduction to the concept of PBM, though it may also be a bit challenging to grasp on the first read. I find that the key to appreciating PBM lies in understanding the concepts of Programmable Payment and Programmable Money. With Programmable Payment, the rules and logic of a payment reside outside of the medium of exchange, and transfers are often facilitated by a third-party backend implementing the rules. Since the rules are decoupled from the value, they can be applied to different forms of money. Conversely, with Programmable Money, the rules are embedded within the money itself. When programmable money is transferred, its rules and value are transferred together, all without intermediaries. Stablecoins and CBDCs are implementations of programmable money. PBM is a protocol that aims to combine both the concepts of programmable payment and programmable money. PBMs have their logic embedded within themselves moving together as they get transferred without intermediaries, while also allowing the rules to be applied to different underlying digital currencies. I’d recommend anyone interested to take a look at the whitepaper and form their own interpretations.
Our Purpose Bound Money
A Brief Background
Our project is a collaboration between SkillsFuture Singapore (SSG), United Overseas Bank (UOB) and GovTech (where I’m with) to develop a PBM protocol that wraps Digital Singapore Dollars (DSGD) using ERC-20 standards. In terms of roles, UOB acts as the DSGD issuer, SSG as the spender, an overseas training provider as the recipient, and GovTech as the implementer. The PBM wraps the DSGD issued by UOB and is pegged 1:1 with the DSGD, which can be off-ramped into fiat when redeemed from UOB. When participating citizens use their SSG credits to apply for courses, SSG pays the training providers with the payment conditions embedded in the PBM.
The PBM’s conditions allow the spender, SSG in this case, to specify a holding period for each payment, during which it’s escrowed before the payee can redeem the money. If the spender believes the service hasn’t been fulfilled, i.e. the participant did not attend the course, they can recall the payment within this period. Likewise, the payee has the option to refund during this time. Once an escrow matures, the PBM is automatically released to the recipient’s wallet. Check out section 7.4 of the Project Orchid whitepaper for more details on our case in the project.
The Approach
I’m sure there are different approaches to developing the PBM. Considering the requirements, timeline and nature of the pilot, what I’m about to discuss was my approach at the time of implementation. There are 3 main components to the project, namely, smart contracts, PBM portal and wallet.
1. Smart Contracts
The smart contracts are where we implement the conditions for the payments. Essentially, each PBM (based on the rules in our case) undergoes a lifecycle: from initiation to being escrowed, to ready for withdrawal, and finally to withdrawn, with the possibility of status changes due to recalls or refunds during the escrow period. All the contracts were deployed on Polygon PoS. There are a few parts to the smart contracts:
- PBM Token
The PBM is implemented as an ERC-20 token. It wraps another ERC-20 token as its underlying asset. Access controls are implemented to the token to facilitate the participating users’ roles in the pilot. For instance, the PBM token allows a Payer role to recall a payment and a Payee role to refund a payment. - PBM Vault
When the spender specifies a holding period, the PBM will be escrowed into a vault. This vault stores and holds the PBM for a specified period and issues a “receipt“ vPBM to the recipients for withdrawing their PBM later. As an aside, I’ve released the vault contract as a standalone library that can be used in other cases too. You can check it out at https://github.com/GovTechSG/time-lock-vault. - Task Manager
This manages the contract automation which integrates with the Gelato network to automatically release the exact amount of PBM in a payment to the recipient’s wallet when an escrow matures. For example, if a payment of 280.95 DSGD is supposed to be escrowed for 14 days, it will stand by to withdraw 280.95 PBM from the vault on day 14 upon maturity and automatically release them to the recipient’s wallet. - Deployment scripts
These are not smart contracts per se, but I wrote a bunch of contract deployment scripts, which later saved me a ton of time and hassle.
2. PBM Portal
The PBM portal is a Web3 frontend to facilitate payment issuance, recall, and history review for spenders while allowing recipients to check payment statuses and unwrap their PBM into DSGD for off-ramping. The frontend was mainly implemented using React and ethers.js.
A few aspects of the UX in the design may appear familiar as I incorporated some of the common Web3 design patterns while designing the frontend. For instance, the interface for unwrapping PBM may resemble those seen in DEX swap interfaces. A key challenge I faced was helping both spenders and recipients visualise the statuses of their payments and balances. Recognising that the PBM lifecycle may not be inherently apparent, I had to design a dashboard with a pie chart that shows users’ balance amounts at each stage of the lifecycle for easier tracking and understanding.
It was also important to empathise with the users in the pilot as many are not web3 natives and were interacting with the blockchain for the first time. So, it’s understandable that some may feel anxious about making mistakes. Thus, the confirmation prompts are specially designed to clarify the exact actions they’re about to take. I’ve learnt that making the user’s actions explicitly clear to them is quite effective in reducing their anxiety, which often arises from the self-doubt and uncertainty they feel about their intended actions.
To see more UX screens for the frontend, check out this link for the deck of UI mockups I’ve designed for the project.
The PBM portal is simply an interface for the users to interact with more intuitively. All the payments and their rules were transacted and settled entirely on the blockchain without intermediaries.
3. Wallet
Although our project ultimately settled on using the Metamask wallet, I think we could certainly implement a more friendly solution for the wallet should the project move into a commercial phase. In fact, I had initially built a few prototypes around account abstraction and also wallet connect for the PBM portal. These prototypes were intended to have a friendlier UX that didn’t require users to have a wallet extension (such as Metamask), deal with their private keys or hold crypto for gas fees. They also used the system’s passkey, which reads the user’s fingerprint or face ID, to retrieve the user’s account to send the PBMs. Unfortunately, due to time constraints and added complexity, these prototypes did not make it into the final build of the project. Nevertheless, here’s a glimpse of how connecting an account to the PBM portal without Metamask in one of my early-stage prototypes looked like:
Just my imagination…
This section mostly reflects my learnings and imagination drawn from the whole process in the project.
As I was developing the PBM protocol for the project, I began thinking to myself that PBM could potentially be used a little more than it seemed, be it originally intended or not. I’ll elaborate on what I mean. PBM is essentially a wrap token with some rules. For the crypto natives, except for the rules, it’s like your WETH and WBTC. In other words, it is a token that wraps another token for its value. An issuer can issue a digital currency token such as the DSGD backed by fiat reserves. Let’s call this currency token the base token for now. Instead of applying the rules only through the PBM, this base token can afford to have some fundamental logic and rules pertinent to the issuer. The PBM then wraps the base token’s existing rules and adds its own. After this, the PBM can be utilised under the set of combined rules programmed. Now comes the interesting part: what if we could loop this wrapping process? Imagine a PBM token called $XYZ that wraps another PBM which then wraps another PBM which finally wraps a base token. I think you start to see where I’m going. Suddenly, the $XYZ token is now a composite PBM that has a few layers of rules and logic to it. Could this be useful, with $XYZ carrying the composite rules, used across organisations or partnerships between businesses or even integration with existing DeFi protocols?🤔
I’ve drawn a diagram to illustrate the idea. Note the different shapes used in the diagram to represent the layers of PBM wrapping.
Here, the issuer could be a bank, a private issuer or even a DAO. Each issuer is likely to issue its digital tokens (depicted as DSGDA and DSGDB) with some basic rules. They are going to be the base tokens. Regulators might mandate certain rules and logic for these tokens to qualify as “regulated” for use. For instance, perhaps, every token might need to facilitate user blacklisting for AML compliance. Regulators could incorporate these rules in a PBM (depicted as R-PBM token in the diagram) which issuers can then use to wrap their tokens before distributing them. Once in circulation, users of these PBM tokens could either use them as-is or wrap them with additional layers of PBMs with bespoke conditions. For example, a business with specific payment conditions with other businesses could wrap the R-PBM with another PBM embedded with their conditions (depicted as BizX-R-PBM-DSGDA token). Likewise, a business or public agency with specific standard rules for handling money within their organisations could encode these rules in another PBM (depicted as AgencyZ-R-PBM-DSGDB) and wrap with it. When there is a use case to spend AgencyZ-R-PBM-DSGDB under some conditions, those conditions could be embedded into yet another PBM and further wrapped again. In the diagram, I used an example of learning credits where the conditions of the credits are embedded in LearningCredits-AgencyZ-R-PBM-DSGDB. This could also apply to use cases such as paying for services (depicted as CompK-AgencyZ-R-PBM-DSGDB), welfare payouts, and others. You get the idea. It’s a little bit like Lego for money.
Of course, this potential use remains in the realm of my imagination since I haven’t had the chance to experiment with it in the project yet. I believe it won’t be without its challenges. The technical design would require careful planning. The first thing that comes to mind is preventing conflicting rules. Still, it will certainly be interesting to see how it might develop.
It’s a wrap!
I’m thrilled that our recent PBM pilot in Project Orchid concluded successfully on the Polygon PoS mainnet. All monies were SAFU. *phew*😅
I’m also deeply grateful to all our partners in the project for being such awesome collaborators!
I see Project Orchid as sort of like design fiction for digital currency in our society. The whitepaper provides several seemingly abstract concepts of PBM and might leave some seeking explicit answers to immediate uses slightly baulked. However, I find the real (and fun) value of this project lies not so much in having an immediate answer but in provoking us to speculate about the use and design of an emerging technology within our society in the possible futures — that might not be too far off considering the developments in this field.🚀
Share your thoughts in the comments!
Visit our project’s website at www.pbm.money and GitHub repository at https://github.com/GovTechSG/cbdc-purpose-bound-money.
Now, clap below for this article to find your purpose.🤪
