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.