Implementing muxed accounts

[ire-and-curses]

Recently, SEP 23 was updated to include some notes proposing steps to support CAP 27 (muxxed accounts) for general use.

This issue is to brainstorm the steps needed to make muxxed accounts a reality, to motivate the need, and to evaluate the priority of the work.

Here's my first pass (without detailed thought) at steps: please add comments and challenge anything or point out omissions. There are surely more details, and maybe some parts are simpler. I'm not an expert but I'm pretty sure it's a lot of moving parts.

Horizon

• discuss and agree on user-facing terminology for M addresses
• internal Horizon model/db schema changes
• lookups everywhere by M address
• adding M addresses to all relevant responses
• ingesting all Horizon data where M addresses might have been used now that they are valid
• changing all the places where we hide M addresses in Horizon right now
• identifying DB migrations or breaking changes, measuring their impact and communicating them to the ecosystem

SDKs

• support for M address types as first class entities
• verifying M address behaviour against all other SEPs (I think we've done this but need to double check)
• API helpers for comparing M addresses and extracting underlying G addresses
• unit tests for M addresses as G address drop-ins

Docs

• explainers for M addresses and virtual accounts and what they're for (this is complex)
• API docs all updated to show M address examples
• M address examples in all SDKs

Ecosystem

• Evaluate likely compatibility issues
• Raise issues with all other SDKs to implement full M address support
• Create explainers (blog posts, etc) to sketch path forward for M address support - different cases for exchanges, wallets, sdks, normal users
• Consider new SEP to describe how exchanges should use M addresses, how other behaviours should change, how systems can indicate M address support etc
• Create FAQ to explain edge cases / consequences (e.g. what if I send to the G address instead of the M, what if it includes a memo, what if you hard-coded parsing for a "G" etc etc)
• Create timeline for migration to full M support
• Understand all the implications of ecosystem interactions during the phase change from G to M (i.e. demonstrate that non-M support consequences are benign)

If accurate, it seems the above is large, end-to-end, and disruptive. I think the complexity is similar to the work involved in a protocol update. As gating factors to making this a priority, I think

1. The work needs a clear need described (beyond the theoretical "building block that the network can use").
2. We should be able to point to at least one organisation in the community who wants this over and above SEP-29, and ideally many, and have general consensus that any disruption is worth it.
3. We should have a reasonable belief that exchanges etc would actually implement this if it was fully supported by us.
4. It needs an internal champion at SDF to oversee these many parts.

It's hard to know what exactly to say about the timeline. Certainly we can help estimate the pure implementation work on the platform side but the rest is complex.

[tomquisel]

@MonsieurNicolas heads up on this. I think the broad point here is that bringing this to completion is a major investment, and as of now there's unclear product value and demand from the community. As to that last point, we'd love to hear from anyone who needs muxed accounts!

[leighmcculloch]

I think we also need to evaluate the vocabulary we want to use. We use the terms G address and M address above, but we don't use terms like that in the SDKs and M address won't really cut it. We refer to G addresses simply as addresses in the code. We need to make some decisions like:

• Do we use the term address to mean G or M address and find a new term for each of those?
• Do we use the term address to mean G address as it does now and find a new unique term for M addresses?

I think we need a strong narrative, probably as a SEP, for how this works in the vocab of the SDKs and the developers who use them.

[ire-and-curses]

We can discuss. We already use terms like MuxedAccount, MuxedAddress, unmuxedAddresses in the code base.

[MonsieurNicolas]

Great points @ire-and-curses and I think it makes sense.

I wish we would have gotten this type of feedback before making the xdr changes as we're stuck with them now that they're included in protocol 13 (along with risks that come with features that are never used). In particular, it seems like the changes left would take longer to implement than waiting for "the next core protocol release".

Next step: I think the best would be to surface this to the ecosystem and ask people to vote/comment on this issue if they'd like the foundation to spend more time on it.

[rice2000]

@marcomontesneri from Saldo mentioned this week that he has a vision for using muxed accounts. Hoping to get some follow up details here from him.

[saldomx]

The business opportunity we see: Stellar becoming an alternative to Real Time Gross Settlement (RTGS) networks. Muxed accounts would be more widely adopted by Fintech companies (wallet providers) compared to G accounts + Memos. As an anchor our solution would consist in creating M accounts in bulk for all the existing users that wallet providers have in their databases and a web service to create new ones programatically. Wallet providers would only hold tokenized fiat in the hosted wallet as needed to serve outgoing stellar transactions to other stellar wallets in the same way that today wallet providers use deposits in a central bank to serve interbank transfers via RTGS. In general it would lower the barrier for traditional players to adopt stellar in order to solve the interoperability problem.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. It will be closed in 5 days unless the stale label is removed, or a comment is posted.

[ire-and-curses]

Go SDK support is being tracked here: stellar/go#3490

[github-actions]

This issue is stale because it has been open for 30 days with no activity. It will be closed in 30 days unless the stale label is removed.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. It will be closed in 30 days unless the stale label is removed.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. It will be closed in 30 days unless the stale label is removed.

[Blake-Emigro]

We went all-in on muxed accounts with EmigroPay.com , and now it's biting us in the butt because we can't find anchors or exchanges that support them yet, any suggestions? We're currently participating in SCF#11, and would have launched by now if it weren't for this issue.

[tomerweller]

@Blake-Emigro sorry you ran into this issue. Unfortunately exchanges move slow. We need to add a clarification to the docs about the current state of adoption.

Are there specific anchors that you want to work with? Anchors usually move faster than exchanges so we can try and poke them.

[Blake-Emigro]

Yeah, it seemed like more were ready, but we just weren't finding it to be true. We have a commitment from our BR anchor, and are pushing our US anchor. I don't want to out them here. In the interim we're going to have to do onboarding from CEX's in the US with memos. Thanks!