Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How would a US CBDC likely be implemented on a technical level?
5 points by boppo1 12 months ago | hide | past | favorite | 2 comments
Regardless of whether or not you think a US CBDC is a good idea or not, if one is implemented, what will the technical[0] details look like?

[0] I mean from a computer science standpoint more than a financial one, since the latter lends itself to endless macroeconomic debate.




TBH, I think centralization makes a lot of sense here.

When you get into a CBDC, you're probably looking at a lot more real-world infrastructure needs than even the most ambitious crypto. In particular, the on/off ramp capacity has to be huge, especially in early phases of the evolution when you're going to run into random commerce opportunities that aren't ready. (Vending machine that only takes 25c coins? Kids selling Girl Scout cookies?) People are going to need to get notes and coins in and out of the system.

I could see having it farmed out to a cooperative of the major private banks, like the Federal Reserve is nominally. This fits the grand American vision of privatizing things that make more sense as a public good. But also because they already have infrastructure and footprint. If every branch/ATM of the 10 largest banks in the country is a CBDC access point, you can make it viable for normal people quickly.

If we treat it as a platform where the banks talk to it, rather than mere mortals (again, appealing to regulatory capture visions), it means that the ledger is basically "authorized parties only", so you largely don't need a blockchain model. You probably just have mirrored infrastructures at each major bank, streaming updates between each other with a tight SLA.


The technological implementation aspect is not generally what stops new ideas. And, I think the technical aspect comes after deciding how a CBDC will look like, since it depends on what you want to achieve with a CBDC.

Looking at the different aspects of topics like Privacy, Auditability and how the CBDC relations to the government will give you vastly different implementations of CBDC.

For example:

1) Privacy: is every transaction in the blockchain completely public? Is it only accessible to certain authorized parties? Is it private by default and only accessible with a "view" key like with Litecoin or Monero? All of these questions depend on what the goal of the goal of the currency is. Having a more private currency will make it harder to audit, but you probably do not want to make it completely public in the same way that you'd probably not want to make all your bank transactions public.

2) Considering auditability: How can you make sure then money in a transactions didn't come from illegal gains? If all transactions are completely private (even to the central bank), how do you do KYC and comply with AML regulation? Currently, banks do KYCs on every customer, but if the blockchain for the CBDC doesn't have access restrictions, who will do the auditing? Additionally, how would a tax collection agency like the IRS confirm that you're actually telling the truth about your transactions? They'll need to be able to access those transactions at some point too for audit purposes.

3) Considering the relationship with governmental power: does the government have the power to view every transaction at any time? What powers do they have in the blockchain? Are they the ones that develop the code?

Considering all these questions, you can start to get a relatively good idea for what a CBDC would look like: 1. There are probably some access restrictions since someone needs to do KYC. 2. The blockchain needs to be private by default, but accessible by anyone auditing.

Considering privacy, you could set up a system where authorized transaction processors (such as regional or national banks) are permitted to create wallets for their clients after doing KYC. The transactions could be private by default but have a key to allow the KYC provider to audit transactions an comply with audit requests.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: