Smart Contract Transfers with Memos

[leighmcculloch]

Hi all, I'm opening a discussion about the issue of sending transfers with smart contracts to custodial entities using memos and muxed identifiers.

Relying on tx memos is broken because it is limited to one destination per tx, which at best is limiting and at worst is ambiguous. Classic has the ability via muxed accounts to send to a different destination per payment, but in smart contracts we're back to the old story that payments themselves do not have a facility to support specifying a muxed id, or a memo, or a tag that associates with that specific transfer.

I'm starting the discussion with a simple idea that @tomerweller suggested, documented in these two documents:

• SEP-44 – a transfer_with_memo function that is a SEP-41 token extension that publishes a memo event
• CAP-61 – implementing support for SEP-44 in the Stellar Asset Contract and disallowing tx.memo on soroban txs

(I should have just posted the ideas here rather than already documented them in drafts, the above proposals are just drafts and nothing more, because I think there are very likely alternative ideas that we should explore too.)

[dmkozh]

An alternative to this can be achieved without introducing a CAP, specifically:

• Create a regular Wasm contract with a single function transfer_with_memo(token, from, to, amount, memo).
• Contract calls from.require_auth(), then token.transfer(), then emits event transfer(token, from, to, memo).
• memo can be just Val, or Map<Symbol, Val> (that's how UDT structs are represented in Soroban SDK)
• Off-chain processors need to know the address of this contract and ingest the transfer events from it for the purpose of getting the annotations. Basically the contract address has to be a part of the SEP, which is kind of unprecedented, but probably isn't a showstopper

[tomerweller]

I like this idea but I think that issue 1️⃣ of having to connect between events is a very hairy problem and prone to issues

[leighmcculloch]

I think issue 2️⃣ is resolvable by assuming a predictable address and having SAC cause those events to occur for classic transfers. So I don't think we need to worry about 2️⃣ now.

Issue 1️⃣ is still an open issue.

[namankumar]

Hmm... for 1️⃣, can't the ingesting system simply rely on contract ID to differentiate between valid memo-related events an no-memo events? It can ignore all memo-containing events that are not fired by the contract. And since events without memos do not contain the contract ID, exchanges can use whatever parsing pattern they use today.

[Shaptic]

You can correlate a memo event with a contract ID to a transfer event with a contract ID, but what if there's more than one transfer event in the invocation? Which one does the memo apply to? Even if the other parameters are identical, there's no way to disambiguate.

[sreuland]

there will be two events for each sac transfer, one for the sac contract invocation and one for the memo wrapper contract, both of these events will have a payload of the transfer amount and a topic that contains the token expressed as canonical asset, and the contract id can be derived from that token such as this example of how horizon ingestion parses sac events.

the complexity comes at the point for ingesters which want a de-duped union of sac transfer events and wrapper events based on same token contract, this implies 'outer join' functionality, where the union only has one logical event per unique sac transfer invocation, and it contains an optional memo value(populated if the wrapped memo contract was also emitted). but there is no unique identity related to sac transfer() invocation provided on the ensuing event emitted from sac contract or the wrapper contract, if two sac transfers for the same amount were done during same tx, the ingester needs to identify which wrapped memo event should be joined to its associated sac transfer event.

[namankumar]

Why not just add a memo field to the existing transfer function?

[JakeUrban]

I think it would break existing contracts since rust doesn't have optional arguments. Doing this would require replacing the wasm for your contract.

[leighmcculloch]

WASM functions do not support optional arguments either.

[JakeUrban]

I'm against this proposal because it would require applications that monitor balances to add yet another way in which balances are transferred to their indexing logic. There are already 6 different ways to transfer balances on Stellar today:

• payments
• strict receive path payments
• strict send path payments
• DEX trades
• AMM deposit & withdrawals
• SAC transfer() calls

We have an opportunity to limit this fragmentation by keeping token.transfer() the only way to move value with contracts.

[leighmcculloch]

I think it is okay if there are many ways to cause transfers to take place, and the challenge for downstream systems is that there are 1️⃣ too many places to look to understand that a payment has occurred, and 2️⃣ too many ways to interpret whether a memo is associated, or a muxed ID, or both, etc.

For 1️⃣:

• transfers in classic operations can be ingested via:
  • Horizon /transactions endpoint,
  • Horizon /payments endpoint
  • RPC via transactions
• transfers in smart contract operations can be ingested via:
  • the transfer event
  • (with this proposal) the transfer memo event

For 2️⃣:

• memos/muxedIDs in classic operations can be found:
  • on tx
  • on source accounts
  • on destination payment accounts
• memos/muxedIDs in smart contract operations can be found:
  • no where today
  • (with this proposal) the transfer memo event

We have an opportunity in rpc and its event stream, that are currently only smart contract events, to bring all these data sources together.

So as we think about a solution about where to put memos in smart contract transfers, we should consider is that place somewhere that could be reconciled and published for classic operations too if in a future version of the protocol events start getting emitted for classic operations too.

SEP-44/CAP-61 would be able support this in the future because it's the one event that's published by the SAC. However the solution documented at #1534 (comment) may be more tricky.

[sreuland]

wanted to mention in relation to 1️⃣ for sources of payment info, horizon ingests soroban token contract events for transfer,mint,burn,clawback into historical operation model, marking them as payments. It is published on API as asset_balance_changes in the 'operation' resource model which is returned from most /payments and /operations endpoints.

[Shaptic]

@leighmcculloch to echo what @sreuland said, the problem isn't nearly as bad as you're describing:

For 1️⃣, all payments appear in the /payments endpoint and everything can be parsed from raw transactions. So the information is... too available? I don't see why that's a bad thing. And if someone wants to build a payment indexer on RPC it wouldn't be hard at all (to your "bring all these data sources together" point), but I want to emphasize that is not what RPC is for. It provides raw data and is a building block, period.

For 2️⃣, they can still be found in the muxed source account for a Soroban transaction. And otherwise they don't exist, like you said. But to @JakeUrban's point, this proposal begs the question: why would we let smart contract transfers have memos? Exchanges can define the way they approach bulk deposits and withdrawals themselves rather than relying on an esoteric differentiation method (memos). We don't need to shoe-horn our new platform into the "legacy" method of doing custodial accounts and should rather come up with a new set of recommendations on how to do custodial + bulk transfers in the smart world.

---

Separately, I want to address a couple of subtle things in your comment:

its event stream, that are currently only smart contract events

You say this like there are other events but there are not. The various schemas that Horizon defines for payments are completely made up and non-standardized. In fact, I'd even argue that people shouldn't rely on them at all and should have their own definitions for what a payment means to them.

if in a future version of the protocol events start getting emitted for classic operations too.

Designing something in preparation for a future that seems borderline technically infeasible (the structure is called a ContractEvent, after all) seems unnecessary.

[brianebert]

From sep-0044: “would make it extremely easy for existing contracts to store balances against the muxed account instead of the underlying account” is useful.

I too like the approach of dmkozh

I hope you leave classic memos alone. They are a useful message queue without single point of failure.

BE

[overcat]

I also agree not to disable the classic memo. Can memo: u64 in CAP-61 fully meet the existing users' needs for classic memo? For classic memo, users can input not only a number.

[slycompiler]

I agree with #1534 (comment)
we can implement without CAP.

[leighmcculloch]

@tomerweller pointed out offline that it would be less awkward with the CAP-61 event topics and stacking the 'memo' ontop of a maybe asset name (what the Stellar Asset Contract does), if we added the token name to the topics of all events, so the token events match the Stellar Asset Contract events.

We can do this by:

1️⃣ Proposing a change to SEP-41, like: #1540.

2️⃣ Or we could open a new SEP-?? that adds the name: String field to all token events. The Stellar Asset Contract already implements SEP-??. SEP-44 is then updated accordingly to depend on SEP-??, and adds the memo topic after the name topic. CAP-61 is then updated accordingly to depend on SEP-??.

I'm partial to 2️⃣, but interested to hear what others think. SEP-41 is technically still in draft.

[leighmcculloch]

Countering this idea, the name would be unvalidated and essentially useless for any token other than Stellar Asset Contracts. The only reason the SACs name is useful is it can be validated by converting it to the Contract ID to determine if it is valid. There is no way to validate the name with only the data in the event for any other contract.

[leighmcculloch]

We could also change SEP-41 to add topics void, memo where void is replaced by the sep11asset name for the SAC.

[leighmcculloch]

I've opened this change, call it 3️⃣, which is functionally as compatible as 1️⃣ and 2️⃣, without actually needing to address the issue of the sep11 asset name inconsistency between SEP-41 and CAP-46-6:

• SEP-44, CAP-61: Move memo into fifth event topic #1541