Henri Pihkala ~ Monoplasma Streamr

[Music] let's have Henry from streamer introducing mono plasma hey hey I'm Henry I head up the streamer project but today I'm here to introduce you to something called mono plasma so mono plasma is a new special purpose of change scaling solution for one-to-many payments now we built mono plasma because we needed it but it's reusable so we wanted to spin it off as a separate little contribution to the etherium scaling space I hope all the bidders gathered here today will find it useful now these are some of the things you might want to use mono plasma for revenue-sharing like imagine a decentralized air B&B with tokenized apartment ownership where an apartment might have thousands of owners now when a guest pays a fee for staying that revenue needs to be split among all the owners of the apartment right other similar use cases include distributing dividends for security tokens doing frequent air drops paying out staking Rewards loyalty reward schemes even pension payments and so on basically anything where you repeatedly fan out value to a dynamic set of accounts and want self-service withdrawals so this talk is only 15 minutes long so I'm gonna turbo charge through why we needed mono plasma for streamer and then talk about what it does and what it doesn't do and finally show a live demo so let's get started to understand our use case for mono plasma I'm going to quickly explain the basics of streamer so the streamer network is a pub/sub messaging network for real-time machine data such as data from IOT sensors smart CDs connected cars your crypto market data and so on so it's not a blockchain but a companion network for one such as aetherium the network delivers messages between data publishers and data subscribers in a robust decentralized scalable way and there's some nice cryptographic things going on such as messages can be signed and sequences of messages can be made tamper proof and so on so this is the base layer now on top of that we have a marketplace gap which connects to the streamer network and to etherium and allows the data producers to sell access to the data streams that they're producing so the reason why we needed mono plasma has to do with the marketplace so let's drill down into that bear with me on the marketplace we're working on a new feature called community products essentially we want to enable large groups of data producers such as end-users owning some connected gadgets like a Fitbit or a Tesla to pool data into a collective data product now pooling the data is not the problem the problem is when someone buys that product and that revenue needs to be split between all those data producers now if there's just a handful of data producers such as in this picture this can be easily done on chain I mean splitting a payment five ways on chain easy as pie but if there's say a hundred or a few hundred your transaction grows and starts to approach the block size limit making it impossible to do this that kind of thing on chain and in our use case there can be hundreds of thousands or even millions of data producers so distributing payments to this kind of huge crowds is nowhere near possible to do on chain so we built mono plasma our requirements were these so we needed to distribute this individual lump sum payment among a large group of recipients a bit like doing an airdrop every time new revenue enters the system the recipients must be able to accumulate value for as long as they want and withdraw when they want by doing a transaction on chain the recipients must be able to join the pool without doing a transaction or placing a stake now this is different from many other payment channel solutions out there and in fact it's crucial for us because the users are mainstream users and we can't have obstacles for joining such as having to buy eath on day one and finally the system should be trustless and transparent so we didn't really find an existing solution that would fulfill these requirements so we rolled our own we were inspired by the different plasma variant and payment channel stuff but basically we threw out everything that we didn't need in order to find the simplest possible mechanism that does what we want and only that while still maintaining good security properties and trustless nests we don't have time to go through all the little differences and similarities between mono plasma and other solutions in the same family so I'm gonna focus on the main difference which is this so we sacrificed generality in favor of special-purpose right this is not a generic payment solution where everyone can arbitrarily transact with each other know this system is unidirectional that means that there are no transfers between accounts on the side channel in other words tokens cannot be spent on the side Channel now why is this good if tokens can't be spent there there's no double spending problem which simplifies things immensely since there's no spending their balances on the side chain are your cumulative lifetime earnings the account balances can only increase monotonically hence the name mono plasma so what about withdrawals then withdrawals are tracked on chain instead of off chain the off change system records only your lifetime credits your positive balance and the smart contract keeps track of your lifetime debits your negative balance so your net balance at any time is obviously the difference and to withdraw all you need to do is to prove the positive component to the smart contract as it already knows the negative one you do this by providing a merkel proof similar to other plasma like solutions out there so if we prove our earnings on the side channel are a hundred tokens and the smart contract knows that we've already withdrawn 30 of them it will give us 70 and update its state so that it says withdrawn one now if we prove again 100 and it knows we're already withdrawn 100 it obviously won't give us any further tokens so I hope that part is is pretty clear let's cover some other aspects of mono plasma there's an operator validator model the operator controls the off change state and in mono plasma he's actually the only party who can cheat and the job of the validators is to make sure that he doesn't both the operator and the validators maintained the off change state in a Merkel tree and the operator periodically publishes the route hash to the Unchained smart contract to enable withdrawals from that state this is all familiar from other plasma variants one difference however is that there's no challenge period slash exit game because there's no double spending instead there's a simpler non interactive freeze period that allows time for the validators to exit people from the last honest Block in clay in case the operator is called cheating so the earned paired funds earned funds do become available with a few days of latency which is fine for many use cases including hours one of plasma lives in the streamer github at streamer - dev slash mono plasma and it ships with a revenue-sharing demo which showcases the functionalities of the framework so enough talk let's see how it all works time for a live demo let me just plug this in here awesome can you guys still hear me yep I'm gonna mirror my display alright so here in my terminal I have ganache running and I have the demo back-end running which houses the operator on another tab I have a validator running and in my browser here I have the demo UI so this is basically like a control panel you can inspect the state of an individual user account on the side channel you can see the overall statistics of the revenue pool you can see the blocks published by the operator you can add revenue with your meta mask and you can add users to the revenue sharing pool so in my meta mask I have two users user accounts configured I have Alice and Bob and we're gonna start with Bob I'm just gonna copy paste Bob's address to this box here to add Bob into the revenue sharing pool so we can see that the member count has gone up to one now that's not a very interesting revenue sharing use case yet so let's add some more addresses I happen to have here 99999 addresses which I'm also going to add to the revenue pool to show some scale here and here we go add users awesome now we can see we have 100,000 members in the revenue pool but no revenue just yet now that's where Alice comes in because Alice Alice is rich she has 1 million unicorn tokens on her account in her meta mask awesome so let's send some of them to the mono plasma smart contract so I'm gonna send this is the wrong input field over here 100,000 unicorn tokens to the meta Mona plasma smart contract like this and we should see some numbers appearing here so the operator published a block that is seen here it's still in the freeze period so those earnings are frozen they cannot be withdrawn just yet in this demo the freeze period is only 20 seconds instead of say two days just to make this demo go a little bit faster right okay and now these earnings are unlocked we can see that from here let's do that let's do that again to show how the value in the side channel accumulates over multiple revenue adding transactions that we do here let's make a few so that the total we've sent into the smart contract is a million tokens so here we can see there's now a million tokens in the revenue pool hopefully distributed to these 100,000 members equally which is the logic in this demo now if you remember Bob is one of those recipients in the revenue sharing pool so I'm gonna go back to Bob and copy his address and we can see in mathematic here that Bob has zero unicorn tokens in his wallet however he might have some in the side channel so let's inspect his address and we can see that yes he indeed has ten tokens which he's earned in the side channel so the way for him now to get those tokens out from the side channel onto his wallet is to provide the miracle proof and we can do just that by clicking this withdraw button over here which bundles that proof into a transaction sends it to the mono plasma smart contract and now watch this watch this number boom here we go so the earnings available went from ten to zero and total withdrawn went from zero to ten now that may not look like much but actually something very cool just happened here if we go to look at Bob's account we can see that ten unicorn tokens have indeed been withdrawn from the side channel on to Bob's account and bob was just one of those hundred thousand so anyone else in the pool could do the same when they want or keep accumulating more all right awesome now there's one more thing I could show you because it's fun we still have a little bit of time maybe so there's this one big red button that says steal all tokens and it looks like you shouldn't be pushing that so this is a button where we can trigger the operator to commit fraud and try to steal all the tokens for himself so let's see what happens when I push that button the operator will publish a fraudulent block which is seen over here it has only one member in it so the operator is now waiting for the freeze period to end so that they can take all those tokens for themselves but we had the validator running over here so now the validator has detected that whoa that something fishy is going on and the validator has attempted to exit the account that that he was that he was watching in this demo there's just five but that leads to a situation where the operator can no longer steal those tokens because the balances have changed the validator has kind of prevented that from happening so we can see here on the meta mask that there's a red box that will say that this transaction will not go through so the validator saved the world this time awesome so that's pretty much a quick review of that so if you think this might be useful for whatever you're building clone the repo play around with this demo reach out to us if you want to want to chat about it and so on good luck and thank you very much and we'll be here if you want to chat about mono plasma or streamer just come talk to us awesome thank you I don't know if there's time for questions or not there is two questions yeah yeah yeah yeah here's the repo any questions all clear clear as day on the on the side Channel you're you're keeping track of how much of the unicorn tokens Bob has so who is storing that awesome so that information is governed by the operator but the validators will also kind of replicate that information to see if it's correct or not so so yeah the operator is control of the state but if if there's anything we are happening there it will be caught by the validators there's no mining in this framework this is kind of unup in unary so you could add for example for the operator the possibility to place a stake or for the validators to to earn something by validating usually in our use case the operator will have an incentive to to run the system due to business reasons but in the general framework anything can be added of course this just specifies the kind of interfaces between the components and the mechanism of of withdrawal in there and you saw over there can also chat about the deeper technical stuff related to this so he'll be an awesome resource yeah yeah so yeah I mean this is kind of like the simplest like the kind of MVP demo kind of thing but obviously all these kind of management that's involved could be kind of could return into some sort hour or you know there's there's a lot of governance solutions out there and and of course this didn't include any of them so so definitely like a future development awesome thanks guys see you later [Applause] okay so up next we have Josh who's a head designer at D Dax and Hydra protocol and he will chat about debunking the myths of design gap design right that one so um Josh over to you hey what's up everybody obviously today I'm here to talk about debunking adapt design myths so there seems to be this this notion that designs or gaps can be poorly designed and have lackluster user experiences because we're early on in this technology we're still in the quote unquote interest stage and so I want to today and no uncertain terms basically debunk that and call there is no reason to have poorly designed adapts but before I can kind of move on and hopefully validate that I'll give you a little bit of a background about myself so I used to be a pro skateboarder believe it or not some of you might say cool well what does that have to do anything with anything and it just happens to be that when you fly off buildings and you essentially make a living flying down handrails and balancing on an inch of metal while trying not to over or under balanced by a pound avoiding death and dismemberment you get pretty good at either managing risk or ignoring risk and so those tend to be qualities that entrepreneurs have and so when I essentially retired at 24 I went on to then start a bunch of different companies and I built a bunch of different companies across various different spaces I tried to be able to personal operating system build a military contracting company as well as a bioinformatics company and so one of the themes that kept popping up as I seemed to keep working on these various complex technologies and had to find ways to simplify them into intuitive user interfaces which just happened to be one of the pain points for decentralized applications so what I how I got started in the space was I'll try to use different products when I ran into different friction points I basically tried to fix those products and then I'll send them to the company completely unsolicited and see what they would say and so eventually I ended up getting hired by radar relay I ended up staying there for a little bit and then I moved on to then become the head designer at d/dx and Hydra protocol where I'm at now one of the interesting things about d/dx and Hydra protocol is I get to work on products both at the protocol layer and at the application layer so if you don't know DDX is one of the top decentralized exchanges and in Hydra protocol is essentially a protocol for performance based decentralized exchanges and so by virtue of this very symbiotic relationship where we have an application and then we have a protocol and they each feed into each other I've really had the honour of being able to work across a number of different products so in the last 12 months I have designed browser-based apps native iOS and Android decentralized exchanges responsive fully featured decentralized exchanges dashboards iframe embed able instant trading wedges develop a documentation onboarding flows custom wallets and now something that I'm working on is a multi-chain mobile based decentralized exchange which is a mouthful but easier to design than it is to explain so when I was thinking about what I could do today I thought I could probably teach people how to design decentralized exchanges but I didn't feel as though everyone would find that valuable I thought about you know picking some products and trying to point to good things and bad things but I didn't feel as though that would lead or leave anyone with anything tangible so I thought the next best solution would be to basically mock up a fake product and walk you through at least the way that I approach designing these products because when you're working on so many different products you at least have to have that method to your madness or a mental model and so that's what I want to share today so the concept is going to basically be this it's going to be a very small subset or a feature set of a much larger system in this we're going to essentially talk about letting a user transfer tokens from one address to another and while admittedly it looks very simple in a very quick fashion we're going to go over error handling form validation handling local and global state different types of micro interactions different types of foreground background push notifications writing microcopy thinking in terms of third-party wallets and how to make that experience for your users simpler as well as different input accessory accessories and using smart defaults so we're going to make an assumption here that there is an underlying interface you can't see the user has basically clicked on a transfer button of some sort and then a modal has basically popped up and so when a user basically sees this or a stakeholder or someone watching this sees this they see this type of interface for myself I see this and so this is basically my mental model whenever I come into designing any type of product I know for a fact that I'm going to need some type of inline foreground notification these take the shape of toast little drop-down Benna notifications it could be push notifications they also have different states such as your pending success and warning states and but we'll talk about more of those in a little bit I also know that we have to have an action title in some kind of descriptive microcopy that helps you use it understand what they're about to do and framing their expectations I also know that we're going to need at least three different forms and all of their various states and then I also make sure that if we if this is a transaction where a user having is having to sign something we also have some type of wallet message in there then obviously we have a couple of buttons that allows a user to enter or exit in or out of a flow so moving top to bottom it's almost offensive that this is here but I see products over and over again do this wrong they don't have a title they don't have a description they don't frame the current action that the user is going to take and this is an important thing to have because as you're designing responsive systems you never know where a user is going to be using your application and where they're going to be triggering something from for example that this is on a mobile device and a user clicks a transfer button and this modal pops up there's going to be enough content in this modal where it's going to abstract the entire view behind it so if you use it doesn't know whether at you're going to need to tell them so how I tend to handle this is I just take a very basic description I just basically describe the action I just say you're going to transfer tokens and then I give it a description underneath that that then almost tries to describe the interface below it and now I'll fully admit that this isn't the tightest microcopy in the world it's not amazing you can play with all the cadence and the tone and all that kind of stuff but it's good enough and I know it's good enough because a user can read this in plain English and in absence of the rest of the interface they know what they need to do they need to transfer a token by adding an amount a token and a recipient address so once you've handled your micro copy card correctly then you can play with all the fancy stuff like your font weights Heights and colors and all your vertical rhythms and all that kind of stuff but that's not too important right now next when you're handling tokens it's a best practice to have both the ticker name and the project name there is no way just to own a ticker outright and so I know this for a fact that there will be clashing project names and tickers we have this at Hydra where Al token is caught hot and then there's also approaching code hollow token who has a token called hot and then there's also another project called Hydra protocol as well and so in the interface you just need to basically handle this and make these exceptions and some people might say well I just like to be as concise as possible I just want to have the ticker in here I don't need the project name I manually reviewing my tow but let's say that this took this token or this ticker isn't it may be in your top 20 tokens maybe has a thousand dollars worth of volume I mean let's say that I like this ticket because it has a great name I would just pay you some money to drop this ticket and drop this token and then list my token and you're going to do that because I pay you enough money to do that and then if you're not handling your project names you're gonna have to chase these exceptions around your product and basically making these manual flags trying to basically correct or help users understand that this isn't the old token this is this is a new one so just use tickers and project names when you're handling an amount there's a few things that I like to do here first I always like to put a max amount in the the max amount that a user has in the amount field as an assistive label and the reason that I like to do that is because I don't want to use it to abandon a flow I don't want to use it to have to exit out of this go to their wallet see their balance then come back and enter into this modal all over again I'm a strong believer that you just keep user in a flow and within that flow you give them everything they need to complete an action another thing that I see projects do is not use placeholders this is kind of form design 101 so always put your placeholder in there that is descriptive another thing that I like to do is give users the ability to have some kind of smart defaults and so in here for the most part what a user is going to be doing is sending a max amount of their token it's basically sending them all out at once but I also like to give users the ability to send a small percentage of their tokens and when I do this I like to have both a percentage as well as the actual token quantity itself and I find that this kind of assistive thing whether you implement it or not at least Syst and communicates to a user that you find this valuable ID that you find them valuable and that you're trying to make their lives easier regardless of whether they're going to use it or not next addresses can be a little bit funky to handle it's essentially two ways to handle an address one of them is long addresses and the other one is shorter dresses and you can do something in between so I think that this is basically optical gibberish but doesn't make any sense it's it's it's difficult to read and most users gonna look at that it's just gonna look like a blur of characters and so what a pattern that is starting to emerge is these kind of short truncated addresses where you basically have the first four and last four characters of a wallet of an address sorry and it just makes it a lot easier for a user to be able to understand and this is actually a pattern that's very similar to handling credit card forms where you have the last four digits and any user just has to kind of quickly verify just a small section of their of their addresses another thing that I think is really awesome is Wallet connect we use that indeed X and it's just a very simple way for a user to be able to automatically scan an address and then input that address into here typing these things out is a pain in the ass and most people are going to copy paste them QR codes our QR scan is on a big deal in the West right now but if you've ever been to China that basically used for absolutely everything especially if you've used or if you use something like WeChat you'd know how how valuable and how useful of a tool QR scanners next this is something that pretty much everybody does wrong which is handling errors I call these essentially local errors and the local error happens on a local component and I've seen these error messages either not be shown or be shown and kind of these little toast pop-up messages which are just terrible I've seen them put them at the bottom of the forms I think it's just the best idea to basically put it on the same line as the label if you're kind of constrained for space you can also put that underneath at the input as well a good error message also needs at least three things it needs to identify the issue needs to tell you they had to mitigate that issue and then it needs to be written in plain English so you don't want to be telling someone or giving someone some kind of like code based error message just think about how you're going to communicate to user the issues that they'll be facing on any of these inputs the next thing that I think is also very important and I don't think many many products take into consideration is thinking in terms of third-party integrations and so when you're using adapt you're usually going to be usually going to be using something like a metal mask wallet or ledger but I can't count the amount of times that I've had issues with meta masks where I've clicked on a button and then the modal hasn't popped up it's likely I keep clicking the button thinking that the interface is broken and then I see a slight incrementing on the notifications up in the browser window and this is a relatively difficult thing to deal with but what are one of the things that I personally like to do is to think about the wallet and then describe that interface and then tell user some of the issues that they might be running into so in this example this is something that I would do assuming that the user has made a mask installed so this basically this assistive message says upon clicking submit you'll also need to confirm within the meta mask if a window doesn't pop up click the meta mask icon in your browser to complete this transaction again this could be much tighter we could do a lot of different things to make this microcopy better but in this two line sentence basically what we've done is we've essentially identified any of the potential issues that a user might have and told them how to kind of mitigate that and so you're going to need to do this for your meta mask as well as your ledger wallets and anything else at you that you want to integrate next - and transaction fees there's many many different ways to handle this you could do it like this where you have some kind of drop-down that allows used to pick between different speeds for gas one thing that I'm I firmly believe is that we shouldn't be showing gas limits in an interface I think it's far too complex and we need to figure out ways to kind of abstract their complexity away and just give a user smart smart default basically and so when I look at this I say there's a few different elements first we have the speed we have a time and then we have a u.s. a u.s. value before this transaction fee I personally think that this looks a little bit too complex and I think this is one of the troubles when you're trying to simplify an interface is that you can essentially by trying to make things simpler you actually make them more complex there's definitely a point of diminishing returns when it comes to simplicity and so you want to make sure that you're kind of kind of almost refactoring the design and these components as you're walking through them to lower the cognitive load on a user so it'll just looks completable to them so I personally wouldn't go with someone something like this I'd probably go with something a little bit like this where instead of kind of letting a user pick the different speeds I just say how long it's going to take and the approximate cost in just in microcopy basically I think that one of the products that really does or handles gas and transaction fees really well is balance they have a pretty intuitive kind of feature on their wallet where you can just again pick between fast slow and average speeds and I try to steal that as often as I can in any kind of product that I'm using because I think that that's a really awesome feature another thing that I I see a lot of products not doing is handling their form validation and so what will happen is that they won't validate the form and then once they user click submit then they'll throw an error that's kind of not how you handle forms right so you should be you should be validating each input as a users moving through it and throwing an error message whenever a user puts some kind of invalid value in there one of the things that I personally like to do I think which is the quickest win is just to put an opacity on the label of 50% and interent not allowed on it as just so a user knows that they cannot click on this button there's also some other cool little micro interactions that you could do here you could do both an on click and an on hover event for the submit button so that when if there's an invalid form like an missing address when the user hovers of clicks on the submit button at then throws that error all over again and the user can then just move up quickly and enter in that address and then move forward once the form is valid I just basically turn usually the label back into a hundred percent the pass or 0 or 100 percent opacity which is a nice little subtle gesture I think the next thing that I think a lot of depths need to think about is just at different states for the application and to be mindful of how that interface needs to respond to those different states so in this example here the user has gone through putting the appropriate information of click Submit now this user is now in this example up in meta mask confirming this transaction and so the the button should go from submit and then basically communicate some type of pending state and another thing you can do here is just disable it so user doesn't try to submit that transaction all over again this is also something that I very opinionated about a lot of depths or applications aren't really handling kind of inline global errors or global notification so a pattern that I see a lot is that a user will submit an action or a transaction to the blockchain and then the app will show some kind of like little translucent toast message that pops up in either the top left at the top right of the screen I personally think that those are it's a very poor practice because if a user is at the computer and then they get a message on their phone they glance over to their phone or they go to get a drink or go to the restroom they're going to miss that transaction and so that interface isn't communicating to the user that's something something happened and so another little mental model that I like to think of when I like to use when I'm thinking about notifications is there needs to be four elements there needs to be a trigger there needs to be a notification type there needs to be a place to retrieve that notification and there needs to be a way to archive that and basically clean it from the view so in this example the trigger would be the user click clicking submit within MIT mask the notification would be some kind of foreground notification it could also be a push notification and then there would also be a secondary activity center where the user can come back in and go through their historical transactions and then we give them the ability basically to archive those or remove those from the view same thing with global arrow states in this example this is this is not actually the best example because once their transaction I would have been submitted this modal will have presumably disappeared but I'm just trying to kind of articulate how you could handle a successfully trends a successful transaction and so a couple of things that I always like to do is basically reconfirm with microcopy that their transaction was submitted also give them the ability to view that in some kind of block Explorer like ether scan and then also let them know that they can review this notification back in an activity center later on lastly clear your form state once a user has submitted a transaction make sure that you just deleting or removing all of the token the amount and the address and whatever other information is in your within your UI it will defeat the purpose if we go through all of this effort to make you know easy to use Mouse and we describe interfaces we use a really tight micro copy and then we just leave the inputs with their with the data in them because a user is just going to view that as it wasn't submitted and they're gonna click Submit and it's going to be frustrating and lackluster so I guess the main takeaways is that things are going to change within your product within your interface within your business they could be regulatory they could be competitive threats they could just be features being added or removed and so you need to architect your applications in a way that are very very flexible and which it's kind of easier said than done but at least aim for that the next thing is that context this King it is important that you understand how a user is using your application not just within the application itself but within the environment that surrounding them for example when I gave the example of you know a toast notification popping up and in them glancing at their phone and then missing that notification so just try to keep the context of the user in your mind as often as possible second to last is this is an early space I don't think anyone's necessarily winning at this stage so if you see something that you like in terms of UX or UI to see the beg borrow or steal I see little cool things all the time that I just I take because I think they're really interesting UX innovations like balances gas things I think that's go and at the end of the day you just need to keep it simple don't try to overthink it too much and just stick to traditional web 2.

0 best practices lastly these are some of the that I guess on the left some of the people who I think worthy of a follow and then on the right hand side some of the companies that I think of doing innovative designs and and thinking about UX in the space differently if you're an engineer you're probably going to want to follow Beltran who's lyrical polymath he's basically trying to write the web three design standards and it's someone who I personally look up to and basically take his word as as law and then there's obviously lots of cool companies like balance and Dharma's little widget that they just put out and all of their products look really good as well as Portus and consensus design as well as wallet connect lastly if you want to follow me that's my twitter handle it's Josh underscore rear if you ever want to send me an email it's just Josh at Dax AIA and also give DDX in hydra a follow because if it wasn't for them I wouldn't be standing here and I wouldn't have had the opportunity to work on lots of interesting products and lots of cool things and to be part of an awesome community and I am finished [Applause] we do a question sure well hey Josh what would you say is like the biggest pain point in crypto in general when it comes to design like what's like the cardinal sin and what is the hardest thing to designer hmm that's a very good question the hardest thing I actually think the design is the easiest thing because if you keep it simple it's not that difficult I think one of the hardest things is communicating to all the different stakeholders within a project what the trade-offs are and so DDX is a very interesting project where we have both a Chinese office as well as a u.s. office and so Eastern and Western design philosophies are fundamentally different and so a lot of the time I have to find ways to communicate Western design philosophies to the eastern team and then Eastern philosophies to the to the Western team outside of that I think that it takes a lot of courage to design simple things because you have to toss away a lot of a lot of different stuff it's safe to be complex it's much more riskier to build a simpler product so I'd say probably the hardest thing is taking the risk of making things simpler and yeah hopefully that answers your question Yeah right about the a theorem addresses so what do you think of these like pictorial representations have a Sabbath or or something have you used those and what do you think of those are they usable artists I haven't used them myself I do see like little avatars up in meta masks but to me as they use it they don't necessarily mean much it just it looks like a placeholder avatar and I don't like is it like less like a fuzz than the long address so I think anything is better than a long address I think eNOS will obviously probably help with that at some stage but I don't think that we're necessarily there yet and it doesn't have the adoption that it needs but I think any type of innovation whether it's an avatar gravity' whether it's a short address or whether it's something else it is yet to be invented will be beneficial