[CAP-64] Memo Authorization for Soroban

[dmkozh]

This is a discussion thread for CAP-64 - Memo Authorization for Soroban.

[tomerweller]

Thanks. This seems like an important thing to fix given that developers are working on smart wallets and there's currently no way to attach a memo to their invocations.

Some prior art here: #1534

• @mollykarcher: thoughts on the effects of downstream systems and SDKs?
• @earrietadev: xbull will likely be the first wallet to encounter this issue. Thoughts?

[leighmcculloch]

During the authorization process the value of txMemo field is validated against the memo of the transaction being executed. In case of a mismatch, the authorization is considered to have failed.

The coupling of the auth memo to the tx memo is very limiting, but it's also very convenient since integrators can continue to rely on the tx memo field. It's the right tradeoff I think for a surgical change to support transfers to anchors and CEXs using auth sigs.

The worst part of the limitation is that it will be difficult to decouple them in the future because downstream systems will be dependent on the coupling itself. But I think the actual impact will be small, because future expansion will probably be focused on muxed accounts rather than making memos more flexible.

I'm a 👍🏻. Definitely keen to hear @earrietadev thoughts.

---

Minor comments:

requires unsafe workarounds (like using an intermediary classic Stellar account for performing the payment)

What makes it unsafe? I don't think this is inherently unsafe. Awkward maybe, annoying yes.

This CAP introduces a new version of

The CAP's abstract looks incomplete.

[dmkozh]

The CAP's abstract looks incomplete.

Thanks, I've created a PR that updates it.

What makes it unsafe? I don't think this is inherently unsafe. Awkward maybe, annoying yes.

I suppose this depends on whether the intermediary classic account is owned by the user (which kind of defeats the purpose of having a custom account), or the trusted third party (which is unsafe, unlike something like e.g. fee payment service).

[mollykarcher]

But I think the actual impact will be small, because future expansion will probably be focused on muxed accounts rather than making memos more flexible

I would agree with this. Personally, I think memo's should die a slow death in this context. We don't yet have an opinionated view on how exchanges should integrate in a consolidated Classic/Soroban world, but I can guarantee that won't involve memos.

[earrietadev]

To be honest after seeing so many users having issues with memos (every now and then we receive some user that forgot to add a memo when sending to an exchange and it needs support) I believe it might be better if we just avoid it and instead we try to move the exchanges in the direction of just using contracts for receiving payments.

Making it so it's compatible with smart wallets I feel what it will cause is that exchanges will never stop using memos... Now that being said, this CAP will make my life easier with the smart wallet version of xBull because I was going to go with the middle account route and with this CAP I won't need to do that

[mollykarcher]

I would actually tend to agree with this. It was likely a mistake to put memos at the transaction level, and it was likely a bigger mistake that we made centralized exchanges dependent on them, but that's where we are.

Given that exchanges are pretty unlikely to make any changes at all, my preference is to avoid asking them to make any changes until we have a strong, opinionated view on how that should look. In all likelihood this does mean a complete overhaul, maybe using muxed accounts but more likely using contracts to send/receive payments. I would say that we're not quite ready to recommend them to make that switch today, the user story around how they would transition is not yet as easy as it needs to be for them. So I look at this memo change as a (hopefully short-term) stopgap, but we still want to do the ideal solution.

[tomerweller]

I'm with @leighmcculloch. This is not the most elegant solution but it deals with the exact scenario we need to fix with a solution that appears to have minimum downstream impact (@mollykarcher please keep us honest here).

@earrietadev I'd love to see exchanges migrate away from memos but what we see repeatedly is an aversion to any type of change from these players. Yes, this might force them to move to smart contracts but it also might make them just not support smart wallets altogether.

I was going to go with the middle account route

What would that look like? Is this a 3rd party account that takes custody of a user's funds in-flight?

[earrietadev]

What would that look like? Is this a 3rd party account that takes custody of a user's funds in-flight?

Yeah, it's an account assigned to the user which takes the funds and routes it to the exchange. Similar to how Anchors work but in this case the "anchor" is just sending the funds to the exchange

[dmkozh]

Yeah, it's an account assigned to the user which takes the funds and routes it to the exchange.

But the users do not own the keys for these accounts, do they? That's the 'unsafe' pattern I've referred to in the CAP. With memo auth the users are able to sign the transfer directly to the exchange, and any 3rd party account can execute it without user funds ever going to it.

[mollykarcher]

Indeed, this will have minimal->no effect for services like Horizon & RPC. There will be some adjustments for SDK's and downstream of that that do the signing (defer to @JakeUrban on wallet impact), but that's not going to impact exchanges.

[JakeUrban]

Assuming all SDKs eventually reach feature-parity with the JS SDK and have an AssembledTransaction object or similar, SDKs should be able to be implemented to accept a memo and use it when constructing both the auth entry and transaction. Otherwise, applications will need to make sure to provide the same memo twice (once when constructing the authorization and the other when constructing the transaction).

[leighmcculloch]

I think the XDR changes can be reduced, but whether that simplifies or complicates the resulting XDR is debatable.

I think we could remove the SorobanAddressCredentialsV2, and use the existing SorobanAddressCredentials.

The proposal requires the credentials.memo and tx.memo to match, which means it is very unlikely anyone will read credentials.memo. Most entities already ingesting txs will continue to read the tx.memo.

The proposal says that the old SorobanAddressCredentials will be invalid to use with tx.memo set to anything but MEMO_NONE. Conveniently this means that it is clearly deterministic which payload needs to be signed. For example:

• If MEMO_NONE, then sign the HashIDPreimage::ENVELOPE_TYPE_SOROBAN_AUTHORIZATION.

• Else, then sign the HashIDPreimage::ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_V2 that includes the memo.

Whether that change simplifies or complicates is subtle. It results in the final XDR having less variations, but it requires signers to know which preimage to build for signing. But, signers already need to know which preimage to sign, so the complexity cost is the same. It could be argued that it's more complex because the wallet has to produce a payload that it doesn't already have in complete form in the tx, but that's no different to tx signature payloads which sdks produce, so again this doesn't seem more complex than the ecosystem already handles.

[dmkozh]

Thanks for raising this, I have considered this option as well. I don't have too strong opinion on this. In general, auth payloads could be collapsed into smaller data structures, but we went for a more explicit approach where an auth payload is easy to interpret and transmit from RPC. Thus I went with a similar approach here for consistency. That said, one might argue that memo is semantically closer to network id (which doesn't make too much sense to be included into auth payloads), so it may be omitted. But OTOH given an auth payload there are just 3 expected network ids to match it with, but the memo space is huge. So given a signed payload and a signature its pretty much impossible to tell if the signature is valid or not without the enclosing transaction. This is definitely not a requirement, but is a nice property of the current protocol.

I think that's a good question to raise during the protocol discussion to get opinions on this from the broader audience.

[leighmcculloch]

Agreed with all your points. I'm on the fence for the reasons you mention. The main benefit to including the memo is for any system that wishes to pass around the auth entry on its own, it self contains all the inputs to the payload that gets signed. That's convenient. I expect SEP-10 for contracts could benefit from that (cc @philipliu @marcelosalloum). But that's an offchain system, and a tradeoff of making the XDR everyone sees more complex, so it's not obvious to me.

Look forward to discussion more in the meetings 👍🏻.