Smart Contract Transfers with Memos #1534
Replies: 6 comments 15 replies
-
|
An alternative to this can be achieved without introducing a CAP, specifically:
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Why not just add a memo field to the existing |
Beta Was this translation helpful? Give feedback.
-
|
I think it would break existing contracts since rust doesn't have optional arguments. Doing this would require replacing the wasm for your contract. |
Beta Was this translation helpful? Give feedback.
-
|
WASM functions do not support optional arguments either. |
Beta Was this translation helpful? Give feedback.
-
|
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:
We have an opportunity to limit this fragmentation by keeping |
Beta Was this translation helpful? Give feedback.
-
|
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️⃣:
For 2️⃣:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@leighmcculloch to echo what @sreuland said, the problem isn't nearly as bad as you're describing: For 1️⃣, all payments appear in the 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:
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.
Designing something in preparation for a future that seems borderline technically infeasible (the structure is called a |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
I also agree not to disable the classic memo. Can |
Beta Was this translation helpful? Give feedback.
-
|
I agree with #1534 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
We could also change SEP-41 to add topics |
Beta Was this translation helpful? Give feedback.
-
|
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: |
Beta Was this translation helpful? Give feedback.
-
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:
transfer_with_memofunction that is a SEP-41 token extension that publishes a memo event(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.)
Beta Was this translation helpful? Give feedback.
All reactions