Technical Design

Contents

1. Design Choices
2. Comparisons

Design Choices

Category	Design Choice	Rationale
Permissioned vs Permissionless Networks	In the context of the trial, a permissionless network is used, which is readily available and publicly accessible	For the trial, we are relatively flexible towards the type of network used. The main rationale for utilising already available permissionless chain is to provide easier interoperability with other projects within this paper, that have also been geared towards public use Additionally, public networks are also much easier to develop for, given that no additional networking infrastructures or access control policies are required. This helps to reduce the barrier of entry for collaboration amongst other participants within this paper.
Permissionless Network Choice	We will be utilising the Polygon Network as the permissionless network of choice. UAT testing was done on the Mumbai Testnet and production deployment was on Polygon Mainnet	There are a few solutions in the public and permissionless chain space. Ideally, the network choice should be compatible with the system’s usage patterns, where transactions are ideally fast and relatively low-value. This also equates to an acceptable level of gas prices to reflect these use cases. Polygon compliments this by offering a sidechain (or commit-chain) that is sufficiently reliable, cheap and well supported by 3rd party services. The network of choice should also be ideally EVM compatible, where it is sufficiently easy to develop for. Solidity has become one of, if not, the most popular language of choice for smart contract development.
Pegging	We adopted a collateralized approach to ensure the 1:1 pegging ratio holds for the SGD-DSGD peg and the DSGD-PBM token peg, we ensured that 1) the total DSDG in circulation = the total SGD in earmarked, 2) the total PBM token in circulation = the total DSGD held in the PBM contract address	For pegging between SGD to DSGD, we are earmarking the respective fiat to back the DSGD token. For pegging between DSGD to PBM Token, we are putting the DSGD into the PBM contract address, which serves as an escrow that backs the PBM Token. We also explored some non-collateralized approaches but felt that it was not as effective.
PBM Tokens Conditions	Campaign expiry date Once the campaign expires, all the PBM token will be converted to DSGD and send back back to Campaign organizer’s wallet Merchant list Only approved merchant wallets will be allowed to receive DSGD from that PBM token (Ring Fencing redemptions)	Technically any verifiable business logic can be added to the PBM contract, we are just showcasing these 2 as these are the commonly required business logic in Government.
Interoperability (DSGD)	Smart contracts were written in Solidity and using the popular ERC standards. We settled with the ERC20 standard since it is the most popular ERC standard, and the best representation of fungible tokens.	DSGD can interoperate with both Government and Commercial Issued PBM Tokens When building the DSGD smart contract, we also ensured that it can be easily interoperable between both commercial and government use cases (eg; Xfers, Grab, OGP) Ideally, this base DSGD contract should offer familiar interfaces for other stakeholders to integrate with. The ERC20 standards and extensions offer the required functionality to enable many of the design requirements that a wrapping PBM token can utilise In the future, we hope to merge all of the various DSGD token implementations.
Crypto Custody	PBM Recipient’s crypto wallet private keys will be stored and managed by OGP, private keys accessible by user. DSGD Recipient’s crypto wallet private keys will be stored and managed by DBS, private keys not accessible by user.	Wallet and private key management still remains a UX problem in the web3 space, requiring either an additional app or an extension. For this trial, we are looking towards removing wallet management on the part of the voucher recipient We wanted to abstract away the concept of interacting with the blockchain from the user’s point of view. At the same time, we also wanted to offer more savvy users with a way to utilise their private keys using their own developed DApps. In addition to that, a sidegoal was to test out the concept of having client generated and signed transactions, as compared to having a centralised proxy that does transactions on behalf of the user or holder. Note: This is still within an experimentation stage. Design choices here do not reflect the final outcome and serves more for trying out new explorations and ideas

Comparisons

In general, we considered the 3 most popular token standards that have sufficient support with popular wallet providers.

1. ERC20 - A fungible token standard
2. ERC721 - A non-fungible token standard
3. ERC1155 - A multi-token standard

ERC721 was eliminated due to lack of support for a fungible wallet approach, as discussed previously in Core Decisions

Token Standards	Main Concept	Pros	Cons
ERC-20	1 smart contract per campaign Accounts based, with no fixed denominations	Easier to manage and make modification - more granular approach and custom functionalities can be done more easily should it be requested by an organiser Lower risk of contract bloating Easier for campaign specific mechanisms (eg; pausing per campaign) Clearer ownership model, with owner being the campaign organiser. RedeemSG only provides the factory and platform to easily create these contracts. Contracts are also modelled directly to existing campaign entity	Wasteful, most campaigns share the same interface either way, unnecessary deployments are being made per campaign if same implementations are done Contracts are distributed across multiple addresses, need to implement an additional aggregator/address discovery service
ERC-1155	1 smart contract for all campaigns, akin to a platform contract Allows support for both NFT-based ( ERC721) and fungible tokens (ERC20) approaches	Follow the paper vouchers concept with support for NFTs, with easier support for offline payments. Better for a decentralised approach. Better design for token/campaigns that share same logic requirements	More complexity, which equates to potentially more vulnerabilities and gas requirements. Contract is more lethargic to logical changes. The contract infrastructures required to enable this might lead to more gas consumption in the long run (eg; looking up state for permissions, interacting with separate storage contracts etc.) Interface is less widely supported as compared to ERC20, although it is rapidly growing in popularity

The ERC 1155 standards, while deemed unsuitable for the context of the trial now, will be considered in greater focus for future use-cases, given the benefits outlined above.