 How's it going? I'm James. I'm here representing Abridged. This talk is sort of, it's called Beyond Burner, intuitive design and incremental decentralization. So really focused on UX issues. Abridged is a development toolkit. We're focused on intuitive design for blockchain applications to onboard new users. My background, if you've seen me before, I was with the grants team. You may know me from there at the EF, but this is sort of the new project that I've been working on since April. So a little overview, we'll go over what Beyond Burner really means. The significance of the application layer, the current state of where we are within adoption, and then what fixing this issue actually looks like. So why Beyond Burner? So Beyond Burner is the Beyond Burger narrative plus the burner wallet. Both of these sort of industries, which is the cryptocurrency space as well as the alternative meats industry are sort of holistic solutions that are trying to disrupt incumbent systems. And they sort of face similar adoption hurdles, which is mainly like unfamiliar experiences and an unfamiliar product, which is also somewhat inconvenient for people who want to get, like use it. And they don't know how. So it creates the unfamiliarity and inconvenience, creates discomfort and friction for their end users. At a high level, it's kind of like I like meat. I don't know what this vegan stuff is, and I don't really like the taste of it or something. For Ethereum, it's like I don't know what a private key is, what is gas, and why does it take so long to use these applications. On top of that, we're also building somewhat in a desert. We don't really have a lot of user data to pull from to make many design decisions. So the, and then another thing is this is just another sort of example where we are. Ethereum has about 0.01% of the user base of Facebook. That's the daily active users or monthly active users on MetaMask divided by the monthly active of Facebook. And then need alternatives are sort of significantly ahead of that. With the Beyond Burger narrative, they've gained half of a percentage of the market of the meat industry, which is pretty great. So we need to give DXR user base in order to match what they've done there. So again, the Beyond Burger narrative, they kind of broke through that stigma of meat, of imitating that meat flavor. So you can be a meat eater, go to Burger King and buy a Beyond Burger and be as satisfied. And it sort of points to the fact that users will choose holistic solutions if it's convenient and comfortable for them. And that's sort of what we need to get to for Ethereum applications to actually be adopted by end users. We can't sort of shove this sort of decentralization down people's throats, right? It's not as useful. And so the first, I think the first real iteration of this was the burner wallet with Austin Griffith. He kind of made onboarding a thing at East Denver in 2019 that was the largest point of sale system that has been spun up in the Ethereum ecosystem since inception. It created instant value for people that were on the ground that are wanting to use that network. And so how do you onboard? Well, you have to inspire trust within your user base and it also has to be efficient and convenient, right? The old paradigm of key management is challenging. I see the future as key management, private key management is being sort of subset to a new contract based management system. My mom won't likely ever download a private key, most likely, right? A new paradigm that we're suggesting in Beyond Burner is to use these burner wallet keys or ephemeral keys with a contract account. So it's essentially a multi-sig that you can control funds with a number of different keys and all of those are potentially temporary, right? So it's essentially there's sort of burner keys that are tied to a contract. This is a design that's really been pioneered somewhat by James Young and this is sort of a quote from him, programmable money deserves programmable access which I fully agree in and I think it's a pretty sort of exciting new frontier to be developed. And so why Beyond Burner? The burner wallet is an instance of the Beyond Burger narrative and the success of Beyond Burger within the Ethereum ecosystem. So why do we care about mass adoption? I think we need to talk a little bit about the significance of the application layer. The application layer is where value is delivered to end users and so that's really fundamentally important. If we don't have that value delivered, all of the work that we're doing in the back end with scaling, it's charting, etc., we'll go to waste or it's just kind of we're developing an asylum. So what does it look like today? Well, it's mainly DeFi, right? The killer app of Ethereum is like Maker and ICOs. It's, you know, it's maybe prediction markets but that hasn't really even really caught on yet. So mainly it's like you're trying to make and save money. The future of Ethereum is a different, like we have a lot of idealistic philosophies around the future and your Dean had a nice little Twitter rampage about this obviously, so what, trolling the idea of this but a lot of ICOs did come out in 2017 very serious about inventing new business models around blockchain around a mutable ledger system to actually like solve real world problems. We also have the bank, the unbanked. Essentially, we have the potential to create better systems if we gain this adoption, right? And so what does user adoption look like? Mainly makes money creates better systems and that could also mean like providing knowledge or comfort or like social belonging dopamine to the end user like all of that stuff is essentially value for them. Fun is also sort of included in that value proposition potentially. And for developers, if you get users, that means you can actually make money, which is a huge thing because today the money is really reserved for exchanges, right? No one is making real revenue aside from exchanges and consultants more or less, right? And so that's sort of the exciting proposition is that you could make a sustainable ecosystem if you actually develop systems or developers are able to build applications to attract real end users. And so to the current state of development, where are we? So like I sort of mentioned earlier, we're really focused on scalability. This has been the Holy Grail and this is probably 90% of the talks that you've heard at DevCon thus far. But again, we're sort of building in a desert where we're sort of siloed, we don't have a lot of interaction within these systems that we're coming up with. And even the core of our ecosystem, we still haven't adopted Ethereum to like pay for things within our existing infrastructures, right? And within the companies who are really pioneering this, it would be great to sort of have a bit more dogfooding, right? For these things to happen. And so it also proposes that we're sort of focused on, at least from a narrative perspective, potentially, the back end more than we need to be, because the front end should be driving the back end solutions. This is another quote from James, working with him. It's really great. He just has like a lot of wisdom to share. But don't like the perfectly named enemy of good. Probably not original, but give attributing it to him. So the current state, $25 billion was raised in 2017, or since 2017, there's about 10 dApps with 20,000 users each on the daily. Again, 0.01% of the Facebook user base. Very few have product market fit, if any. So we're well within the chasm, right? And the reason for this too is the developer challenges. This is a survey built by Fluence in 2019. If you haven't seen it, I think it's probably the best UX survey out there today. And they kind of just go over all of the issues with developing blockchain apps. It's really difficult. We're both developing this new interface, and then you have the tools that you're also developing at the same time. And there's just a lot of issues. So again, you're coming back to, we're sort of forcing private keys down in users' throats more or less. This is also a stat that I saw on another presentation that I thought was really interesting. I believe it comes from the cryptocryptus study. So how do you fix end-user issues? And I'm going to go back to onboarding and scaling. And focus on that onboarding side, because this is beyond burner again. So it's getting focused on that account contract with ephemeral keys to create a programmable access of funds. And if you don't have effective onboarding, there's no reason to have a state channel or a secondary solution. There's no real need for eth2.0 if we don't have enough end users to drive traffic. The approach to really understand this is you have to know your user base, create intuitive interfaces, and then iterate with the feedback that you're given. And a lot of that means to ship quickly and gather information as quickly as possible. And so again, sort of iterate why onboarding sucks. It's uncomfortable and inconvenient for me. And I think everyone can kind of appreciate that. I'm sure everyone has tried to talk to someone like, hey, yeah, that's great. Come on to MetaMask or something, and whoever you're talking to is like, no, I'm not really sure. Compound is kind of weird. I don't really want to download this thing. So a hypothesis that we developed at Bridge was, okay, if we just use Web2 flows like AWS authentication, for instance, we could maybe onboard more users. And that could happen. And so we sort of went on a rampage. We came with an SDK in June. And integrated it with as many applications as we could. We hit like eight or nine, essentially. And so all of these applications sort of have a bridge tooling integrated into it. And the most popular have been Yolo Rect and Dow House. They actually have real end users. If you want to actually experience what this account contract design feels like, definitely check these both out. Yolo Rect is just a binary options trading, you know, betting platform. And then Dow House is going to be a Dow, you spin up mall like Dow's, right? So they have like 10 different Dow's moving along there, which is pretty exciting. And what we found from that sort of all of this feedback was that there's two types of users that you're looking at when you're developing blockchain applications. One is for Web3. And the other is for Web2. So like Web3 users are really interested in, you know, privacy. Web3 provider, they prefer MetaMask and self sovereignty, of course. I spoke with Nate Greninger, who is building in Web3 as well, and he kind of describes it as coddling an ember in a damp forest, where you're just trying to get it to kind of like keep heating up, right? And of course these are like MetaMask users. For Web2 users, though, they kind of, they likely don't care as much. They're looking for just like intuitive, fun things to use, which burner and like the average like smart contracts or account contracts is potentially a more viable solution. And so the common denominator, everyone wants a seamless experience. They don't want to think they want to trust what you're doing. And they don't want to waste time in the onboarding process. Otherwise, you won't get there. You won't be able to show the value of what the application is. So to us, that looks like, at least at first, when someone is getting used to understanding what decentralization and what Web3 provides or Ethereum offers, no seed phrase download, native mobile apps are really nice. All the onboarding occurs within the application, so no needing to switch screens, and then account recovery options are also included within your management system. So again, we want to create instant value for the end user, and the account contracts are really the way potentially to do that. It's a more flexible way in the ephemeral keys, essentially the account contracts is in particular, useful. You can recover your funds, and you can also uniquely permission each key for different use cases. So each key could have different access. And this is sort of what Beyond Burner really aims at. You have an account contract that has multiple keys, all for different reasons. You have your phone, your computer, your guardian, your mom, or girlfriend, or whoever. Maybe you have a portis or torus integration as well, as a sort of master reset. You'll erect, maybe you're interested in playing, you also play God's Unchained, and you're part of the Medicare data. All of those could have different levels of fund access, and that's all programmable. So if you end up losing your phone, thankfully you have all these other keys that you can build your next phone with, and you can recover your funds through a social recovery process. And again, this system has a lot of possibilities that have yet to be developed in terms of app linking and recovery flows. So if you're interested in sort of building that kind of stuff, please come talk to me after this. And so this kind of comes down to incremental decentralization. Again, you want a soft landing pad for users to come into the ecosystem and sort of understand what's going on before you just put them in the deep end. And that comes down to sort of providing that layer of trust and sort of onboarding them into something that looks familiar, while also giving them full access to their funds, but not showing them a completely new system at the beginning. And this also, to some extent, I think that DAPS, full decentralized, full stack decentralized DAPS, have a very small chance of actually succeeding in the near term. It's more about like Ethereum applications, where you have hybrid solutions that are using like AWS and Firebase or, you know, other sort of like centralized solutions to get things that people want to use. The second piece of the onboarding puzzle is Fiat Ramps, of course, and you have like Wire, MoonPay, Ramp Network, Carbon, all these different solutions that I think they're all sort of competing in the same space. It's really great that that's a competitive area right now. And then lastly, if you have apps, you need off-chain transactions. If you have users on your app, you likely need off-chain transactions in order to make a seamless experience. And all these teams are doing a lot of really great work to provide like fully decentralized solutions for these off-chain transactions at a bridge, where we actually have a off-chain system as well, but it does have a degree of trust. It's using a central hub that you could potentially collude with. I'm not going to get too deep into that, but that's kind of like essentially the idea. And so to fix the UX issues again, you just need onboarding and off-chain transactions. That's kind of the combination that you need in order to make a seamless application flow. And if you want to see another example, you can like scan this app. This is actually a native mobile app. I don't know. How many people have actually used like a native mobile Ethereum app? That's not a wallet. Anyone? Okay. Sweet. A couple. All right. So this is a native mobile app that has a account contract as well as the average sort of off-chain solution interpreted into it, that you can sort of play around with like social tipping for content. So the takeaways here, Ethereum is really difficult to use for a lot of reasons. While decentralization is really, really important, it also inhibits to some extent user adoption if it's going to be taken to the nth degree from the beginning. There's also really difficult tools, underdeveloped tools to use within the ecosystem to develop these applications. And we have no user data to actually say what tools are really useful. The need to create trust, we need to create trust for the end users through more intuitive design to make it convenient and comfortable and programmable access is potentially a way in which to do this through account contracts. And so I sort of am proposing that the ecosystem should spend about as much time on this issue, maybe not as much, obviously. I think the nuances of connecting ETH 2.0 is going to be quite a task, but getting nailing down this flow also requires a significant amount of effort and iteration, and it won't happen overnight. We need sort of encouraging pragmatic development and hybrid architectures and sort of continuing to ship solutions to gather that user feedback and sort of focus on end users rather than maybe the most idealistic situation possible. So this is me on the Twitter and it's abridged if you want to check out what we're doing. Yeah, that'll be all.