Support muxed contract addresses

[JakeUrban]

CAP-67 introduced support for multiplexing Stellar account addresses in soroban contracts, including updating the Stellar asset contract's transfer function and its corresponding event to support muxed destinations.

However, the use cases for multiplexing are not exclusive to Stellar accounts. Users of contract accounts may also benefit from multiplexing, but this is currently not supported by the protocol.

We should consider adding support for multiplexing contract addresses the same way we support multiplexing of Stellar accounts.

[leighmcculloch]

Users of contract accounts may also benefit from multiplexing

What are the use cases and test cases we know of that can validate both the need and the way that this might be implemented or the way that this might show up for contracts? Figuring this out up front, I think, will be critical to designing this in a way that makes sense for the contract use cases.

[JakeUrban]

A smart wallet provider is integrating with a SEP-24 on & off ramp, and SEP-24 uses memos to match offchain transaction intents with onchain transactions. Memos are disallowed when the transaction invokes a contract, so for off-ramping, the wallet provider generates the muxed address using the ramp's specified transaction memo and uses it as the destination of the SAC transfer. This approach currently cannot be used in the on-ramp case, where the ramp would need to make the SAC transfer to the contract including the memo.

Thats the concrete need-it-now use case. But more generally, why are contract accounts any different from stellar accounts in terms of the usefulness of multiplexing? A custodial wallet (ex. an exchange, or an institutional custodian) should be able to multiplex their account rather than deploy a contract account for each of their beneficiaries.

[dmkozh]

Thank you for starting the discussion and providing the use cases.

My initial take on this is to just extend the existing semantics of muxed G-addresses to C-addresses in exactly the same fashion. Specifically:

• In XDR, SCAddress gets a muxed contract variant consisting of the contract id (32-byte hash) and uint64 mux id.
• A new Strkey type is also introduced for muxed contracts
• In Soroban host, MuxedAddressObject starts supporting contracts, and the respective host functions that work with muxed addresses are updated to support contracts (get_id_from_muxed_address, get_id_from_muxed_address etc.)
• In SAC events we just emit the normal C-address as the to topic, and to_muxed_id in the data map, in the same fashion as we emit events for muxed G-addresses.

I believe this is pretty non-controversial, as we just replicate what we already do for G-addresses in a consistent fashion. But I'm open to any suggestions or additional requirements for the design.

[leighmcculloch]

CAP-67 and the accompanying changes to SEP-41 added muxed address support to four places:

• SEP-41 transfer event
• SEP-41 transfer fn
• SEP-41 mint event
• SAC's mint fn (not part of SEP-41)

It did not add muxed address support to other places that a destination address exists in SEP-41 or the SAC.

That decision was based on the use cases of G-muxed addresses, but the use cases of C-muxed addresses may be different.

Do we have a sense of whether the existing four places are sufficient for the C-muxed address use cases, or to be useful to the new use cases does this proposal also need to add muxed address support to other events or functions?

[JakeUrban]

other places that a destination address exists in SEP-41

I believe the only other place is the SEP-41 transfer_from function, right?

The use case we have at this moment will not use allowances. So if we want to continue to minimize the surface area of protocol changes, we could keep this out of scope. That being said, I don't see why muxed destinations (from either G or C addresses) for transfers that consume allowances wouldn't be a viable use case. We are not aware of one right now, but by not including this in-scope now, we're putting ourselves in a position to have to make the change in a subsequent protocol upgrade.

[leighmcculloch]

other places that a destination address exists in SEP-41

I believe the only other place is the SEP-41 transfer_from function, right?

SEP-41 today does not support MuxedAddress on transfer_from, are you saying that the new use cases requiring muxed contract addresses need it on transfer_from?

[JakeUrban]

No, the use case I'm referencing won't use transfer_from as far as I know. My argument was that we should consider adding MuxedAddress support to transfer_from not because we're aware of a team waiting on this capability at the moment, but because the use cases of transfer_from and the use cases of MuxedAddress are not mutually exclusive.

For example, we're working with a partner today that uses allowances to pull funds from an account once a debit card is charged. That partner uses an omnibus stellar account to receive funds, but its entirely plausible that partner wants to use a omnibus contract account to receive funds instead in order to take advantage of capabilities unique to contract accounts.

For the sake of keeping this proposal as uncontroversial as possible I can omit support for MuxedAddress in transfer_from from the CAP, but I think its worth considering independently from this proposal.

[dmkozh]

For the sake of keeping this proposal as uncontroversial as possible I can omit support for MuxedAddress in transfer_from from the CAP, but I think its worth considering independently from this proposal.

I agree, I think we could just open a separate discussion regarding this to keep things more focused. These also require a bit different scope of work (updating the token interface also involves a SEP adjustment). I do agree that it doesn't sound too controversial though.

[Shaptic]

Hot take maybe, but I'd like to offer a rebuttal to not including this feature.

First, on why muxing contract addresses doesn't make sense. Someone can check my historical work here, but my understanding is that we needed them for classic because they were easier to manage for a custodian (one secret key) and were cheaper than maintaining accounts per-customer (no reserve requirement). That makes muxxing a bug fix rather than a feature. The point of smart contracts is programmability, and you can still have one auth to rule them plus do an implementation-specific muxing adaptation in the contract itself.

Second, on why we shouldn't propagate memos further. They're bad UX for many reasons, number one being forgetting them, and while muxed strkeys were a way to improve on that, most of us remember how long it took for anyone to adopt them. The same goes for adding yet another way to represent an address. We're asking the entire stack (both internally and the entire ecosystem), to introduce protocol-level complexity (handling the new ScAddress arm, handling a new strkey, etc.), for the benefit of..... whomst? The cost-benefit math doesn't math for me.

Finally, on the SEP-24 case, specifically: the benefit of memos there is so that the anchor can differentiate between its users on the deposit and withdrawal flows. But contracts are already unique! You just transfer it directly. If they decide to lump all their users into a single contract, they can already do that... just write your own contract! We could have an example of how it's done and standardize that rather than introduce yet-another-transfer-method.

TL;DR: We introduced programmability to the network for a reason. Let's leverage it instead of forcing protocol-coupled solutions.

[dmkozh]

I agree on the adoption complexity part. I'm not sure I agree on the programmability part - contracts are not any different from G-accounts in terms of custodial account implementation - there is no standardized way to multiplex an address in a transfer. An option to extend the transfer interface itself has been discussed before, but for better or worse we didn't go with it at the time, and it would still require changes all over the stack with an added 'bonus' of making the interface of every token incompatible with the standard in addition to all the other work. It also still requires a bespoke user identification system, and without the standardized strkey representation it means that the developers would likely use C-address + int, which is even more error-prone.

Or do you have a better idea of how that could actually be implemented?

[sisuresh]

@JakeUrban we had a protocol meeting that included CAP-0084, and there were questions around what the actual use cases are. @Shaptic (thread) and some others were questioning if we should be propagating the usage of muxed accounts like this, as opposed to some other solution that just uses the programmability available in Soroban. Your input, along with input from the ecosystem partners (either directly or indirectly) would be helpful.

[Shaptic]

Just to follow along, my question kinda branches out to: what are the alternatives without this? Can we tweak SEP-24 to leverage events? Can we standardize a contract that mimics this behavior? etc. Those are just spitballing ideas off the top of my head, but it'd be good to see the tradeoffs more explicitly before introducing downstream complexity to integrate with this CAP.

[JakeUrban]

I'm open to suggestions, but adding the same support to C addresses as we offer to G addresses seems like the obvious choice to me.

Alternative approaches increase complexity for all parties involved in these use cases. In practice this would mean C accounts would be less-likely to be supported, and as @dmkozh mentioned, the implementations would be more error-prone.

To reiterate there are two use cases, which are the same use cases that exist for G addresses:

• Attaching an offchain identifier to a token transfer for transaction reconciliation (ex. matching an offchain payment to an onchain payment, i.e. SEP-24)
• Attaching an offchain identifier to a token transfer for subaccounts (ex. an omnibus contract account)

We're asking the entire stack (both internally and the entire ecosystem), to introduce protocol-level complexity (handling the new ScAddress arm, handling a new strkey, etc.)

We should have asked the ecosystem to do this at the same time we made the same request of them for G addresses. We shot ourselves in the foot by not providing feature-parity between G and C accounts back in CAP-67.

[leighmcculloch]

as opposed to some other solution that just uses the programmability available in Soroban

Ideas that would fall into this category came up during discussion for CAP-67 instead of adding any M support to Soroban, and iirc one of the big reasons for why not to build some new programmable pattern is that to preserve composability of contracts muxed info needs full support in every contract that passes the address value around, or it needs to be side-car information that somehow travels parallel with the value so that contracts do not need to handle it specifically but it still pops out in events for external systems.