Shaping Indonesia’s CBDC Infrastructure
Unpacking Indonesia’s chain infrastructure model, CBDC standard spec and the government & public participation.
Observing the development and adaptation of blockchain for the past years back, has made me believe more in how blockchain & Distributed Ledger Tech can really be the base foundation and IS the best candidate of the payment infrastructure in Indonesia.
Understanding current common system of how core banking and other digital-money fund movement work, using the 13th century well proven concept of double-entry accounting, may be the best idea of creating a robust payment infrastructure, but only the weakness is the silos and how every company implement their technology differently.
Looking at Indonesia’s payment landscape, BI (Bank of Indonesia / Central Bank of Indonesia) has shown several standardization and infrastructure initiative, say for example SNAP (for it’s Payment API standard), BI-Fast (for it’s real-time online transfer), BI-RTGS (for it’s real time transfer for big amount of money), QRIS (for QR payment), and GPN (for it’s card payment). Those that I mention is basically having the same purpose:
Moving the fiat-money, Indonesia Rupiah
And to issue CBDC, is not only to handle the payment scope. Money, is the core of the payment itself. So that’s why, when thinking about CBDC, we should not think the solution provided only in API level, just like the previous way of BI issued another API standard whether for inquiring or transferring. But we must think until beyond.
Sharing the Infrastructure instead of sharing the Interface
The creation of Central Bank issued digital money will surely make impact into the current digital money held by existing payment service provider. The digitalization of Rupiah already take place just before the CBDC it self was created, so the question is, how can CBDC fit in? Or… how can the existing digital money fit in? There may be a lot of assumption of the way both will fit into, but in this writing, I just want to share my idea of utilizing blockchain as the shared common infrastructure for the government who issued the digital money and the digital payment service provider, who later will conduct the rest of it (payments, lending, etc). Where eventually, the process of money debit and credit happened in the same agreed infrastructure inside the blockchain.
E-Rupiah Issuance: Reflection of Stablecoin
When the government issue the digital money, the concept should be similar like how the stable-coin is minted. There should be a 1:1 fiat backup for every e-Rupiah issued into the chain. Because this way, the value of rupiah it self will be kept regardless of it’s form. There should be a guarantee that the possession of E-Rupiah will have the same buying power the physical money have. Government can also establish the facility to exchange between digital and physical money.
Spec of E-Rupiah: Copying the ERC-20 function standard
In order to create a specification standard, Indonesia’s CBDC can take a look at the widely adopted standard of Ethereum Request for Comment of Fungible Token, ERC-20. This is the spec that followed by big crypto token derived from Ethereum, say for example MATIC (Polygon), USDT (Tether), IDRT (Rupiah Token) and other. Of course with more specific addition, such as to support the multi-signature verification, will create a possibility of upgraded ERC standard that will fulfill the needs of CBDC.
Though it is not limited for E-Rupiah to create its own blockchain platform and ecosystem, by copying the established standard can boost many efficiency during the development and also to keep up with the advance of blockchain technology from open-source community.
Now, Imagine if E-Rupiah is deployed on the blockchain with the CBDC ERC-like standard, what are the following impact?
- There will be no API spec needed, the parameter standard is defined by the ERC itself, the existing web3 client (web3js or Ethereum JSON-RPC) can be used to interact with the chain.
- Unification of CBDC infrastructure unleashing the possibility of not only nation-wide but a world-wide participation. Using the same standard on the level of infrastructure may lower the tech barrier of other country who want to create their own CBDC. The cross-border digital payment can be look similar to how cross-token exchange happen under the same ERC / standard. Exchanging eRupiah with eRinggit would not be different like exchanging Matic Polygon with Arbitrum
Challenges:
- How can the blockchain keep up with the existing transaction speed? Visa claimed that it can processed up to 24.000trx/s on it’s peak, while the speed of Ethereum only do up to 40trx/s.
This problem may be figured out using Layer 2 chain solution like Polygon PoS or using a roll up approach like Arbitrum. Other solution may employ using a permissioned blockchain to minimize the value of validator just like how Ripple works.
Bridging the on-chain into off-chain (Web2): Where Existing Fintech Players Take Part
BI built blockchain as the infrastructure . Which has the scope only to provide the ledger of money (digital rupiah / eRupiah), so the movement of fund can be tracked in the distributed ledger of blockchain in end-to-end. But who move the money itself? Those responsible for executing the movement of funds are assigned to each payment service provider (registered Banks / Fintech / Wholesale / Retail / etc).
Maybe what we see on the chain is only a random public address sending some amount of eRupiah into a fintech wallet address, but the actual process between those A -> B money movement can be deeper than that.
A scenario example could be a user, is paying an electricity bill by using the eWallet XYZ, where he is, under his validation allowing the eWallet XYZ to deduct some portion of his eRupiah to be credited into the XYZ eRupiah address. When eWallet XYZ received the event of money successfully transfered to it’s account, then it trigger an electronic bill payment using the conventional Web2 API protocol, into the bill aggregator. Sometime, eWallet XYZ also has multiple account to be separated between different account use (Tax, P/L, Deposits, other) where the process of internal eRupiah movement can take place between XYZ’s internal account.
To employ a more privacy, eWallet XYZ can also use a sharing account provided by either BI or other clearing house. So let say when user want to send money to eWallet XYZ, instead of moving user’s money from his account into XYZ’s account, the money will be moved into BI sharing account. There will be a Clearing and Reconciliation afterward to extract the portion of XYZ money from the sharing account. With that process, the total money of XYZ’s won’t be exposed and will secure the company competitive data.
Government & Public Participation : Leveraging the Power of Staking
Now the question may arise, Who has the control over the blockchain?
To ensure that government doesn’t lose the control over the chain entirely, the blockchain can be made permissioned. Solution like JP-Morgan/Consensys Quorum, IBM Hyperledger or self-hosted ethereum-like or other Proof of Stake blockchain client connecting to custom network outside the mainnet. During the first initiation, government can issue 2 separate token, one is eRupiah itself as the CBDC, and other one is token that can be used for staking, so the fluctuation of blockchain token won’t affect the price of Rupiah directly, let’s called it Bhinneka Coin (just an example).
To allow people participation and keeping the chain less centralized, government can sell some portion of Bhinneka Coin to the public and point some trusted non-private / non-government agency to be the validator of the chain. In this scenario, the retail participant can delegate the Bhinneka coin they own to the public pointed agency. With this approach, blockchain can be ensured to have neutrality and prevented from the centralized entity controlling over the chain, preventing the censorship and reversion of transaction or manipulation over the chain.
Other thing with this approach is to keep the advantage of blockchain redundancy to ensure minimum data loss and increase data finality. With multiple node hosting the blockchain and running the validation, will increase the network security, yet limiting the number of nodes, by permissioning who can be the validator, can keep the decent transaction speed.
Audit and Transaction Security: Establishing a National Equivalent of CERTIK
As the nature of blockchain is transparent, government and public should have, not only independent, but also expert auditor to ensure the correctness of the chain, protocol and smart contract running. The privacy of Indonesia’s citizen data including the transaction, must be protected at all cost. Utilizing zero-knowledge proof will surely help keeping those privacy, but we need to ensure that is the implementation is well-designed and there are no flaws or vulnerability that can harm every component of the chain.
The fallback scenario must be prepared in case there are major disaster happened. Private Key revocation and recovery action must be available in case the majority of the chain is hijacked. Both full-chain and partial chain snapshot must be exist so every time the unrecoverable happened, there is always a near-time roll back solution.
Periodical audit for every pointed delegation of chain validator also important so the Bhinneka coin that people staked into those validator node is not misused. There must be platform and access for every people who stake their coin to self-validate the amount they staked too, so the public trust is kept.
Useful Reference
