On the slatepack transaction ux

Hey everyone, i’ve read a bit about the UX issues the slatepack transactions have, and I also think they are not very userfriendly. I don’t know about how to technologically improve this stuff, but maybe i can help to make the user feel more secure and comfortable when doing this kind of tx.

From my perspective the main problems are as follows:

  1. The slatepack transactions are explained in technological terms. It’s very abstract.
    Calling this process exchange of addresses might help here. So that the user understands that slatepacks are one-time wallet addresses which need to be exchanged to confim a transaction. That would be easier to understand imo.

  2. The slatepack addresses look scary and take up lots of space.
    I guess you don’t really need to see them in the tx process. Or at least only show them to ppl who really want to know. You’ll see the address when copy/pasting anyways.

  3. I don’t get any feedback.
    This is really important. The user want’s to know that everything has worked.

Here is a simple visualization of what the process might look and feel like. The structure and the ui design is not perfect, but i hope you get the basic idea.

It’s still 4 clicks, but i think that by making the user understand the workings of it in a simple fashion, and by giving feedback during this whole process, the user will be more comfortable doing slatepack transactions.


@whyisnoquestion I agree with you. To be honest, slatepacks work fine and the process is rather simple, just some copy pasting. Especially after doing it once or twice it feels completely comfortable.
But showing the user where you are in the process with check-marks indeed makes for good User Experience. In addition, by showing the user the steps, it teaches the user the protocol (SRS and RSR) which is a nice added benefit.
@davidtavarez what do you think, would this fit with Grin++?


I agree.


Are you using Grin++???

I appreciate that you took the time to bring this topic. I invite you to explore Grin++ (https://grinplusplus.github.io/) and propose the improvements that from a UX perspective, you think it will help. I’m always open to make things simpler for the regular users.

I think I would need something more specific, but of course, I would love to make any change, specially for mobile.


Thanks for taking the time to try and improve ux, it’s really beneficial to see what bothers the users :slight_smile:

The problem with calling that process exchange of addresses is that it’s misleading to how things work (signatures). The reason why i think the user needs to know about when he signs the transaction is so that he can prevent play attacks. Slatepack addresses are not one-time addresses but tavarez is working (or has plans to) on giving an option to use them, but they won’t be required afaik

Besides that nitpick i agree with your points. I think it would be good to see tx details when you paste the slatepack (before you confirm), otherwise confirm should imo be automatic. One possible reason for showing tx details is that you might paste your slatepack after a week, not sure if that’s a good enough reason to not automate finalize step though

I have created some examples in the past of how tx details could be shown (in different steps), one such example is the testnet exchange, the other one are the videos I’ve created in the past:
Exchange deposit flow video
Create tx contract flow video

1 Like

Yea, I agree. It’s not that complicated once you get the hang of it. Problem is: Most users are lazy and don’t like to learn new shit.:stuck_out_tongue:

Yea, i’m using Grin++. Besides the crashes on macOS/Linux, and the violations of color-conventions, it’s a pretty cool wallet. (I’d not mix brand-colors with button-colors. And using a different logo is also not recommended. hurts brand recognition.)

That’s not so easy to do. :sweat_smile: But I hope I can try something once I get some time on my hands.

Yea, I was not sure about how to explain slatepacks in a more simple fashion. It should be comprehensible, without having to learn new concepts imo. Maybe use some real-world examples or sth. Don’t know… But it’s not that important, you’re right.

Automatic is faster, I agree. But it takes away control from the users. Would be careful with that.


In an unpublished Grin++ UI interaction I tried that but I thought it was unnecessary so I did never commit those changes to the repo… maybe I could try again and see, it would be nice, specially for regular users.

Please, whenever you’re facing an issue, let us know in Telegram: Contact @GrinPP I’m also curious about the violations of color-conventions, it sounds like something bad. Again, please, feel free of suggesting things that improves the user experience.

PS: the logo is perfect :grimacing:

1 Like

Haha, you are using the yellow brand-color as a button color. But the states of buttons are already defined, and ppl are used to them. Breaking such conventions is not recommonded.

And regarding the slatepack-thing. I think it makes sense to have a dedicated area for slatepack transactions. Something like a To-do list.

Here is a quick draft. And please ignore the design. :sweat_smile:
I wasn’t able to figure out the design-guidelines for grin. There are none, right?


Plenty of huge brands are using their brand color as primary action color.

I know. Doesn’t mean they’re doing it right, bc they are big brands. I think companies which heavily rely on marketing tend to overuse their brand. They make it more important than the conventions which were established over the years. It’s confusing imo.

Try to get that beyond a product manager… :smiley:

It’s also not wrong, just because some UX designers said so.
UX conventions are not carved in stone, but Coca Cola’s branding guidelines are carved in stone.
IMO it is much more important to do it consistently within the application than doing it consistently with Material or Bootstrap.

1 Like

Really great build up. We need wallet without any technical terms which is the only thing I am unsatisfied with Grin++ now. Look at the Beam wallet, it is really a killer!

1 Like

Correct, we have no design guidelines afaik. Perhaps getting two different guideline suggestions for light/dark would be cool.

Also Grin’s branding, we all love yellow :yellow_heart:

Well, how do we create an UI/UX that can be understood by everyone since Grin is so unique? It is a genuine question. I want to educate users trough the experience but at the same time I want them to feel familiar with a crypto UI. Really hard stuff.

1 Like

The way I would see this is with just three headers where a checkbox appears once the step is done, below them you see if you click the step the same two screen as you would see now Grin++ when sending or receiving slatepacks.
So the only addition is that you show above the “Slatepack” and “Response” screen the step.
The naming of these three steps should be technically correct and goes back to the SRS RSR discussions.
Apart from that I would not change the behavior of Grin++, it is already very intuitive.

It has been a while since I was toying around with ideas, but I saw some kind of dashboard and then specific action screens. Only showing one thing at a time.

I was also playing with screens for smartwatches, because that enforces to be really minimal.

I stopped playing when corona came, I think…
This was also before I knew about slatepacks.


Some product managers understand the value of keeping the users in a familiar environment, some don’t. :stuck_out_tongue: But you’re right. It’s not easy to get this in the heads of ppl working at coke, or any other marketing-driven brand. I just think tech-heavy products, and products which don’t have a multi-million-dollar brand, should not do such fancy stuff. Anyways, this is not really the topic, i guess. :slight_smile:

Edit: If you really want to go for such a color scheme, I’d suggest you use yellow for positive action, and work with icons+wordings for all other button states.

Yea, it’s not easy and costs lots of time if you want to do it in one big step. I think the way grin++ is developing its UX is a more resource-friendly approach. Especially for non-UX designers. Ask users, care about feedback, test things out, look how others do it etc. That’s the way to go imo.

And grin is only unique because of the slatepack transactions. all other stuff is identlical, no? Enter address, send amount. That’s basically it. right? :smiley:

Good thing is that wallet UX is nothing new. There are lots of established conventions. The fintech industry already spent millions to figure this shit out. So i guess, it’s more about how do utilize and translate what they have already done?

I think the most important thing that needs to be hammered in, is that there is a third step, so that people don’t forget to finalize. Therefore pending transactions need to be shown as in your example above and it needs to be clear that an action is required or that they are currently waiting for an action of their counterpart. What also is pretty different from other wallets is that there are multiple ways to do things. RSR (invoice) vs. SRS (payment) flow, Tor vs. slatepack messages, use an address with slatepack messages or use none. Bitcoin wallets are more linear in this regard.


If there is any suggestion for Grin++ mobile please do not hesitate. Grin++ v0.2.0 (Android) available now! - #3 by davidtavarez cc @whyisnoquestion


I have no Android, which is a bit blocking, but I can see some things from the screenshots. I will try to make some suggestions.

It’s unique because of interactive transactions, slatepack is just the standard this community came up with to encrypt the data that needs to be sent to the other party. This standard also first tries to send this data over tor. So basically the difference is multiple communication rounds (2 instead of 0, if it goes through tor it still does those 2 rounds but it’s hidden from you) which leads to more transaction states. Another new thing is also an option to cancel a signed tx (which isn’t on the chain yet, was blocked in some way…there is an open rfc for that)

1 Like