David Schwartz, the CTO of Ripple, chimes in about the confusion over Ripples blog post, related to smart contracts and programability on the XRPL. He writes:

Seems like there’s confusion over the programmability blog post we put out yesterday, so let me clear a few points up:

Ripple simply cannot (and absolutely doesn’t want to) unilaterally change the XRP Ledger. The blog post is Ripple saying that we see the value in bringing programmability to XRPL Mainnet (in addition to what’s already happening with the EVM Sidechain) and are making this a priority now, and we’re committed to putting out a design proposal for community review. Instead of coming out with a proposal already baked, our intent was to be transparent and show where we’ll now be focusing internal resources and priorities, do the due diligence, and come back to the Community with our thoughts.

Why the sudden change? As many pointed out, I focused on the fixed functionality of the XRPL and EVM sidechain at Apex earlier this year. I genuinely didn’t see how smart contracts on Mainnet would work without turning XRPL into a different chain. I had convos in the past few weeks with Orchestra Finance, and others in the community that made me recognize that programmability on Mainnet can work if key challenges are addressed (ledger bloat, TPS loss, and bugs/exploits). I think the best way to mitigate these risks is to take small steps that lead in the right direction, and it's great to have the historical data of how hooks has worked on Xahau. I fully acknowledge that plenty of smart minds came to this conclusion that programmability makes sense for Mainnet much earlier.

Why now? Besides the above, we also felt it made sense to share our thinking ahead of the XRP community gatherings in Korea and Japan this week, because these are important in-person chances to discuss programmability! This is honestly the only reason for the timing…there is no hidden agenda.

We have, and will continue to be transparent about what we’re thinking. We’re committed to:

• Regular community calls
• Design reviews with external community members/stakeholders
• Blog posts explaining considerations, thought process and any designs we propose.

Link

David Schwartz, the CTO of Ripple, chimes in about the confusion over Ripples blog post, related to smart contracts and programability on the XRPL. He writes:

Seems like there’s confusion over the programmability blog post we put out yesterday, so let me clear a few points up:

Ripple simply cannot (and absolutely doesn’t want to) unilaterally change the XRP Ledger. The blog post is Ripple saying that we see the value in bringing programmability to XRPL Mainnet (in addition to what’s already happening with the EVM Sidechain) and are making this a priority now, and we’re committed to putting out a design proposal for community review. Instead of coming out with a proposal already baked, our intent was to be transparent and show where we’ll now be focusing internal resources and priorities, do the due diligence, and come back to the Community with our thoughts.

Why the sudden change? As many pointed out, I focused on the fixed functionality of the XRPL and EVM sidechain at Apex earlier this year. I genuinely didn’t see how smart contracts on Mainnet would work without turning XRPL into a different chain. I had convos in the past few weeks with Orchestra Finance, and others in the community that made me recognize that programmability on Mainnet can work if key challenges are addressed (ledger bloat, TPS loss, and bugs/exploits). I think the best way to mitigate these risks is to take small steps that lead in the right direction, and it's great to have the historical data of how hooks has worked on Xahau. I fully acknowledge that plenty of smart minds came to this conclusion that programmability makes sense for Mainnet much earlier.

Why now? Besides the above, we also felt it made sense to share our thinking ahead of the XRP community gatherings in Korea and Japan this week, because these are important in-person chances to discuss programmability! This is honestly the only reason for the timing…there is no hidden agenda.

We have, and will continue to be transparent about what we’re thinking. We’re committed to:

• Regular community calls
• Design reviews with external community members/stakeholders
• Blog posts explaining considerations, thought process and any designs we propose.

Link

Arguably, the two biggest challenges for retail central bank digital currencies (CBDCs) are whether the public sees them as useful and concerns about privacy. Despite coverage to the contrary, central banks design most current CBDCs with good intentions. However, with many countries shifting towards more divisive politics, some worry that CBDCs designs could be tweaked. These concerns relate to a central bank or regulator dictating who can use the CBDC or restricting how the money can be spent. Alternatively, there are big brother snooping concerns. A recent paper by staff at the International Monetary Fund offers a thoughtful approach to the topic.

At a high level the report shows a deep appreciation of the issues. But it also delivers a practical how-to framework.

More than once they cite a 20-year-old paper that argues privacy is inherent to the nature of money. That ‘Money is Privacy’ report was in response to the growth of ecommerce, including the use of personal data to charge higher prices to some people. The ‘Money is Privacy’ paper even suggested some might want to use an intermediary in order to anonymize payments in the absence of anonymous money. This was before the invention of Bitcoin.

The IMF authors cite an Edelman Trust Institute study that found respondents trust businesses (63%) more than government institutions (51%). However, the research spanned 28 countries, with people putting greater trust in the government in four jurisdictions.

Apart from the collection of data, privacy risks come from external events, such as data leakages, data abuses, cynt privacy by design and PETs (privacy enhancing technologies).

Data use cases

Personal data isn’t particularly useful for central banks. However, aggregated transaction data can be used for monetary statistics and to optimize monetary policies.

The report notes that the European Central Bank and the Bank of England have vowed not to access or use personal data for CBDC. Although it said that “other central banks (for example, the Reserve Bank of India) have emphasized the economic value of CBDC data.”

On that point, one of the purposes for collecting private information may be to provide credit scores for those that lack traditional credit histories.

The paper explores how each participant – central banks, payment service providers, merchants and consumers – might desire to access either aggregated data or private information. For consumers, the desire is to control that access.

One question is whether central banks can learn from the BigTech experience, particularly from China’s Alibaba and the associated payments app Alipay. It notes that data collection can help to expand access to credit. At the same time, it says BigTech profit incentives result in the erosion of consumer privacy.

The question is whether there is a similar risk for CBDCs with payment service providers (PSPs). “A nonbank that manages payment data is a central node in the ecos paper is well worth a read.

Meanwhile, in June the ECB published a blog post about making the digital euro private and we analyzed the digital euro progress on that front.

Link