Cash Code as a user-facing name for RPA

Wallets
,
#1

I want to propose a user-facing name for RPA: Cash Code.

As a wallet app developer, I’m seriously considering RPA support in Opal Wallet because the benefit to users seems clear. There is also real work happening this area already: Electron Cash RPA, CashFusion compatibility, SRPA discussion, etc. I’m still catching up on parts of the technical design space, so I’m not trying to settle protocol terminology here.

For builder discussion, I think RPA is fine. But for wallet UI and public communication, it feels a bit weak. Cash Code feels like a better user-facing name.

Cash is already one of the strongest words in Bitcoin Cash. It carries the original “peer-to-peer electronic cash” story without needing much explanation. It also fits the naming pattern the ecosystem already uses: CashAddr, CashTokens, CashFusion, CashScript.

These phrases feel natural to me:

  • “Here is my Cash Code.”
  • “Please donate any amount of BCH to this Cash Code.”
  • “Opal Wallet supports Cash Code.”
  • “Scan this Cash Code to send me BCH.”

That is the main reason I like it. It sounds like something normal wallet users could actually say.

Cash Code, a user-facing name for Bitcoin Cash Reusable Payment Addresses.

Does anyone think this is technically misleading in any important way? Does Cash Code conflict with existing BCH terminology? And has someone already proposed a similar naming direction before?

1 Like
#2

Johnathan Silverblood created CashAccounts long ago: SPECIFICATION.md · master · Cash Accounts / Cash Account Specification · GitLab

Electron Cash supports CashAccounts - you can register one of your addresses.

CashAccount supports binding to a RPA instead, but nobody has done this in practice yet.

I’m working on something similar currently, and I was planning on using CashAccount + RPA + CashID (CashID / CashID Protocol Specification · GitLab)

1 Like
#3

Thanks for sharing those projects around RPA. That helps me understand the current status more clearly.

How is your work going so far? Are you prioritizing Cash Accounts, RPA, CashID, or trying to make them work together from the start?

From my side, supporting all three at once feels a bit overwhelming. RPA seems like the most direct feature to ship and explain first. A broad message like “Hey my wallet supports Cash Accounts, so you can use a personal identity on Bitcoin Cash.” feels harder to make immediately compelling. But “my wallet supports RPA(maybe Cash Code) so you can receive BCH without publishing a reusable address that links incoming payments” feels much easier for regular users to understand the direct benefit.

1 Like
#4

I’m working with the Electron Cash team to standardize a RPA library in Typescript. They are currently deliberating final details before upgrading RPA support in Electron Cash, at which point the bch-rpa library that is currently found on JF’s github and the Selene gitlab will also be ready for production use.

CashAccount already natively supports RPA, we just need wallet-side integrations.

CashID works independently of both RPA and CashAccount and solves authorization to websites, not identity. One of my first BCH projects was an attempt at implementing CashID inside a browser extension. You can see the prototype here: Selene.cash / whoami.cash-ext · GitLab

I think it’s important that RPA comes before broad CashAccount support. I suspect one of the major reasons that CashAccount hasn’t already caught on is because of the privacy gap - current implementations are no better than a static, reused payment address.

3 Likes
#5

I think “Cash Code” is great branding. And it also fits nicely with CashTokens, which can be sent to a CashCode. It also abbreviates nicely to “CC”, which is good for people messaging each other to make payments.

The only slight oddity is that people talk about Bitcoin Cash Code meaning programming code too of course, but I think contextually it would rarely be overlapping.

We’re at the point in the dev cycle of a universal address scheme that several different solutions are bubbling up and being debated and perhaps are learning from each other a bit, but none have taken a decisive lead as “the main standard” yet.

Anyone passionate on this issue has a good opportunity to make their choice the standard if they do a good job of implementing it and encouraging or persuading a few wallets and libraries to add their choice, or finding a critical use case that drives lots of end user adoption.

#6

I agree that implementation and adoption will ultimately determine which approach becomes the standard. I think RPA could attract meaningful attention to Bitcoin Cash across the broader crypto space if we implement and present it well, so I intend to make it a serious priority in my wallet app. I’ll also coordinate openly with the devs working on Electron Cash and Selene.
Thanks for taking the time to weigh in and I’m glad Cash Code resonates with you.

2 Likes