Improve withdraw flow for users; Add option to require a memo in stellar.toml about stellar-protocol

[nullstyle]

Better is if these exchanges just start supporting federation

I think it would be best to have all of the above. This feature would be very useful for anchors and at present anchors expose their extended info through the Stellar.toml file.

IMO, we should explore this to see how we can facilitate simpler deposits from the network into an anchor.

[nullstyle]

Yeah that would be a nice UI, but technically how would kraken know it was your XLM? in your kraken account your lumen balance has to go up after this "withdrawal" from stellar.

One possible formulation:

1. Kraken would add a Stellar.toml file that includes an entry for their "Withdraw" server
2. The client would initiate a withdrawal from the stellar network into kraken by identifying the current user (authentication TBD) and receiving an account id and memo to send lumens to.
3. The client would populate the payment form with the necessary info and the user would manually enter how much XLM they are withdrawing into kraken
4. Send transaction.
5. ???????
6. Profit

(sorry, I couldn't resist the underpants gnome joke)

---

Speaking to your comment @irisli, I suppose what I'm arguing is that the two issues you describe don't need to be handled differently at the protocol level, and ideally they would not be handled differently at the user experience level.

Conceptually, I see transiting the stellar/non-stellar divide as a single protocol problem: It shouldn't matter whether I'm "withdrawing" fiat or stellars, and it shouldn't matter if I'm "withdrawing" into an exchange's system or an anchor's system. I'm even willing to say that we should unify this protocol with the bitcoin bridging protocol... it's all just moving things out of the stellar network and into somewhere else. Yes, each situation has different wrinkles, but I think we can handle those wrinkles within the context of one protocol rather than several.

[jedmccaleb]

How do you know to look at a particular stellar.toml file though?
Better is if these exchanges just start supporting federation

[irisli]

Good point. Home domain? Yeah you're right, seems cumbersome.

I do agree that using federation is the better solution.

[jedmccaleb]

I suppose there is no harm in adding it but how do you know you are sending to an anchor? Is the client going to check the home domain of every account it sends to?

[nullstyle]

I imagine, for example, anchors will eventually advertise their deposit address in the toml file, alongside this setting. But you bring up a good point which is perhaps we should think about the end-user experience we're trying to facilitate.

I think back to our old official client where adding an anchor happened by entering a domain name. IMO it would be great if there was a way to remove the need for copy and pasting memos to withdraw funds from the stellar network. To do that the client would need some way to resolve the deposit address and the memo to use for the payment. I see this proposal as only a partial solution for the former piece of data, and I'm not sure how best to handle the latter. Perhaps a new federation request type?

[jedmccaleb]

I think the exchange just needs to give their customer's a payment address: so "To deposit lumens
send them to 872863*kraken.com" then the user doesn't have to enter in the memo or the deposit account ID.

[nullstyle]

IMO, that's a pretty poor user experience, and while we can support your proposal using federation alone, my hunch is that we will have to build a more palatable experience to accelerate adoption.

IMO, I want us to be able to enable a client that looks like the below:

[jedmccaleb]

I think anchors are different. Have you seen how stellar desktop does it? How would it work for depositing lumens on kraken?

[irisli]

My motivation for opening this issue was for sending lumens to an exchange.

I do think that a feature with a withdraw link built in to the client would be pretty useful though.

[nullstyle]

I think anchors are different.

How do you view anchors and exchanges differently, from a user experience standpoint?

Have you seen how stellar desktop does it?

Yep, and I think that's the direction to work towards but it still isn't great; There's tons of room IMO for a better user experience. Also right now, and correct me if I'm wrong, their solution all manual integration and an ad-hoc apis.

How would it work for depositing lumens on kraken?

1. Click the "Withdraw" link on the XLM (I should have included a withdraw link on the XLM portion of the table)
2. Choose "kraken" from the following page as the withdraw destination
3. Enter how many XLM you want to move into kraken, then click submit.

[jedmccaleb]

Yeah that would be a nice UI, but technically how would kraken know it was your XLM? in your kraken account your lumen balance has to go up after this "withdrawal" from stellar.

[irisli]

I think when jed says "I think anchors are different.", he means there are two separate issues here we are talking about:

1. Withdrawing XLM
2. Withdrawing an asset

With issue number 2, it can be solved with a nice withdraw UI. But for issue 1, it's still a unresolved issue.

[nullstyle]

An idea about UI:

edit: To be clear, I'm not advocating for this specific vision, but rather using an image to roughly communicate an idea that would require a lot of work to put into text.

[irisli]

Ah, thanks for the mockup ideas scott. It just clicked in my mind that my client can have a withdraw button in the balances and then list a few well known sources. This would make it easier and less intimidating for the user!

[nullstyle]

@irisli Yeah that's exactly my intention with the mockup. You're on track with the notion of "well known sources", but maybe we need a more generic term than "sources" (since we're talking two way connections). Perhaps we use Stellar Router as the term? or maybe External Account?

Perhaps we just add a sub-protocol to federation (using a new a query type) to expose what routers a given domain supports?

[bartekn]

I was thinking about this some time ago and I realized that having something like this as a flag in a ledger account that (when set) rejects transactions without memo (or accept only specific memo type) would be really helpful:

• Exchanges - they wouldn't have to deal users that sent txs without memo.
• Anchors using Compliance protocol - transactions without memo_hash are not valid in Compliance protocol so they would be rejected by a core node.

[vogel]

That is great idea Bartek. Do we want also to support restriction on memos? Like range in case of MEMO_ID or regex in MEMO_TEXT? Or is that too much?

[bartekn]

I don't think it's necessary (and also I wouldn't allow users to set regexp then executed by every node in a network 😉 ).
I think there could be 4 new account flags (or something called "memo" flag?):

• REQUIRE_MEMO_ID
• REQUIRE_MEMO_TEXT
• REQUIRE_MEMO_HASH

Then:

• If none is set, then tx with no memo, or any memo type will work. (existing behaviour)
• If only one is set, then only this type is allowed.
• If two are set, then only these two memo types are allowed.

I think we should allow MEMO_RETURN all the time in case there is a return transaction.

[MonsieurNicolas]

I don't think MEMO flags make sense at the protocol level as from a user experience the next question is "how do you know it's the right syntax for that MEMO field?".

From what I see it only reduces the chance of people not specifying the right data in the tx (and leave the destination with dealing with bad data).

I think that this is calling for ways for a client to:

1. detect that something special needs to be done and have a few "well known requirements" for certain transactions
2. potentially have a way to validate a tx before submitting it the network

it seems that both of these would be built on top of federation, first one seems to be what @nullstyle is advocating for, second one is not easily done today - we'd need to have smart contracts of sorts.

[antb123]

Two ideas

1. Why can't exchanges simply detect if there is a memo field on incoming transactions. If no memo field return the XLM?

2. Could we leverage the new deposit SEP to support this?

[vogel]

I like the idea of exchanges returning transactions, but there is no way of forcing that.

[oelmekki]

Hi guys,

Hope I'm not hijacking your discussion, but I have a feedback on the topic, as an user, regarding UX.

Last year, I tried to use the exchange features of Stellar Desktop Client. I added vcbear.net as a trustline, bought an xrp, then tried to use the "send" tab to send it to my ripple wallet. It was rejected, so I thought it was just not ready yet.

I tried again today, and realized the problem was that I was not supposed to send to non stellar address to begin with: I can only send ripple credits to an other stellar address. Good thing first transaction was rejected, it made me smile thinking I basically did the same thing than those people who input their litecoin address when sending bitcoin.

So after that, I think I got it : I have to go on the website of the anchor to use my credits. I went to vcbear.net ... only to realize it was all in japanese, and it was an exchange. From there, I have no idea how I could actually use my credits.

What a good user experience would be:

1. if I could send to my counterparty asset address in the "send" tab (I suppose other wallets / account viewer have something similar).
2. if anchor could provide some logic in wallet to withdraw asset directly from my stellar wallet

I get how challenging it can be, that would mean knowing everything about other assets (what their address looks like, do they use a memo field, etc). But maybe stellar could provide some ways for anchor to implement their own logic and provide those features, that wallets could then use in their interface?

[jedmccaleb]

Addressed with SEP6: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md