Empty Wallets, Full Potential: Coinless Users & the Path to Mass Adoption

Transcript

Hello everybody. Um, my name is Harry Evans. Uh, I'm going to be talking a little bit about Coinless Users. Here's a little bit about myself. I'm the CTO at, uh, Project Liberty, which is the, uh, Devco for uh, the frequency blockchain. Couple of, uh, pointers to other stuff there. So, just to get started, what do we mean when we talk about coinless users? First, a definition. um a user who can take action on a blockchain without paying the transaction fees. This is important because um the uh ways in which we go about acquiring crypto and the ways in which users onboard to apps have high friction in the case of acquiring coins. So some of the key

concepts involved the wallet types and the wallet data involved um coinless users are compatible with most wallet types out there today. uh custodial wallets, non-custodial wallets, um whether they're uh account abstractions or externally owned accounts, uh wallet as a service or uh other related types. Um these general techniques work with all those cases. The second is the wallet data. When we talk about wallets, they do a lot of things now, but at the core, we're really talking about the ability of the user to authorize a particular transaction and to affect the signing of it in a way that can be submitted to the chain for authorization.

Um, and when we get to the actual data being submitted to the chain, that's where cost actually comes in and that's where the focus on techniques around uh affecting coinless users uh comes from. Um, and this workflow is inherent in any of the wallets used. You have the intent, the user's formulation of the transaction, for example. The permission, this is the user authorizing it, asking the wallet to actually sign it. In some cases, this might be a pass key that they use a biometric. It might be entering a password to unlock a wallet. Uh, it can be any number of different types of authentication. And then you have the actual action them taking action on this which is submitting it into the consensus system and attempting to modify chain state and

or achieve finality. So how to coin this users work? Um there's a few uh kind of key techniques and requirements involved. The first is cost shifting. This is where the user signs the transaction but someone else pays the transaction fees. So you see this in for example uh ERC 4337 with pay masters. That's a good example of it. There's other techniques involved for other chains but similar in all these cases is the user actually involved in signing each of the transactions as they occur um without paying the transaction fees obviously. Uh the second is delegation.

This is where the user delegates to another address. You see this with uh well our previous speaker uh talking about uh 7702 and also 7710 where you see externally owned accounts or uh account abstractions for example being able to delegate specific operations to other addresses and those addresses can not only take the actions that are specified but they can also fund the transactions. So these are two of the key ways that we see uh coinless user transactions being effectuated. And then the third one is more of a practical concern. When you look at transaction pricing, um you not only have the aggregation of the costs from the individual users uh uh that the for example developer or other sponsor of

the transaction has to pay. So they're uh uh dealing with not the the decentralized individual payments that an individual user would have. They have the aggregation of those. But in addition to that as you look at least the techniques today the expenses involved for the same transactions when the costs are shifted are actually higher. So it actually increases the overall burden that's involved there. So that's another practical aspect. You see these a lot on L2s less on L1's and that has to do with cost. Two to 5x the cost of cheap is often still cheap but two to 5x the cost of expensive is often impractical or impossible.

Some of the drawbacks uh from coinless users um their censorship risks uh Ethereum for example has been through several iterations of things like pay masters to be able to do cost shifting. One of the big concerns was around things like uh bundlers or uh uh open relays being able to uh choose not to participate when certain transactions came through and effectively be able to censorship for any number censor for any number of reasons. The second one is is that paymancers are an inherent source of censorship. Ultimately, they're the ones that are paying the bill when the transaction is being sponsored onto the chain. They have a approval process as part of the verification of the transaction. And theoretically, they could choose at any particular step to

not pay for particular transactions flowing through the chain. So, it's an inherent censorship risk. Now theoretically users can shop around for other pay masters but the way that the uh uh uh structure of these things are today is many cases the pay master is the D app that the user is formulating the transactions on so it becomes impractical for them to go elsewhere. Um the second is delegate trust. What do you do when you've delegated the rights to take certain types of actions under your account and that delegate goes rogue? So it can't operate outside the bounds of the types of transactions it's um authorized to take. But there are semantic ways that it can violate that.

For example, uh frequency uh is specifically designed around social networking. And you can imagine a case where you delegate a particular application to be able to do likes on your behalf. You click on the screen, it submits the likes to the chain, but you're not required to sign for every heart you give a post as you're scrolling a social media feed. If it goes through and likes hundreds of posts that you didn't click on, what do you do? Well, the first piece is uh uh revocation, right? Like you want to stop the delegate from doing additional damage.

Um and that ties in now with a second concept, which is oftentimes uh delegates and pay masters are used in coordination. So not only do you have uh folks making delegations, the actual delegation cost itself was paid for via sponsored transaction. So what do you do in the case of revocation? There's not the same. You have an incentive misalignment in many cases around the revocation there. There are options you can do around uh prepayment into smart contracts. And uh on the frequency blockchain, we actually have optimized revocations around delegates specifically uh as part of the delegation process. It's automatically prepaid. So either party, the delegator or the delegate can actually break the

delegation mechanism at any point in time with a transaction that effectively costs nothing because its cost was already paid previously. Then the final piece is uh repudiation. If you have a delegate that goes rogue and likes a bunch of posts in the example I was giving, um not only do you want to revoke their access, but you want to see if you can actually fix the damage. Now there's a number of types of transactions. for example, token transfers that are almost certainly nonreputable on the chain once it's reached finality. So unless you catch it at the time at a mempool level, which is unlikely in many cases, um those types of transactions wouldn't be reversible. But uh when you look at uh other use cases, whether it's in gaming or social media, In many

cases, you can you can unlike a post that you've liked, you can uh take down a uh a post that you've made that was made by a delegate that you no longer uh no longer trust and that acted uh uh without your ex sort of implicit permission. Um but for this reason, we recommend to be very careful on the types of transactions that you actually delegate for. There's a lot of use cases out there that talk about things like spending limits like, oh, this can spend up to a certain amount of uh coins in your account or it can take certain other types of actions, but you need to be very careful and look at the use cases in detail when you're working with coinless users, especially around delegates to ensure that the potential damage for a delegate that becomes

untrusted or gets compromised, for example, where it's not even the delegate themselves acting rogue, but their keys were compromised somewhere else in the chain. um to to be very careful about the types of things there in uh uh our social use cases on the frequency side. We actually don't allow for example token transactions to be delegated right now because of those sorts of risks. We do allow a a number of social interactions to be though. So like taking those sorts of considerations as part of the um overall um uh uh uh sort of like operations that you do or don't allow delegates is a uh to to use as a is an important aspect here. Um why do coinless users matter?

Um the first area is user acquisition friction. The scale of web two versus web 3 um it's at least an order of magnitude difference. And when we look at the cryptocurrency owners, there's at least 150 million out of that 425 that's shown there that are actually folks that only hold tokens on exchanges and never transfer them off or at least haven't so far. So the actual number of users that have uh tokens in a wallet that they directly control, for example, uh is even less. Um and any extra steps in the process when a user is uh uh uh onboarding to an application can have significant impacts on the overall uh uh results as far as the number of people

actually sign up. The conversion rate from the top of the funnel to the bottom of the funnel. Um oftentimes the sort of rule of thumb for many apps is somewhere between 15 and 20% for every additional screen that you introduce during the onboarding process. For example, um on uh apps that Frequency has worked with, we've gotten this down to three screens for identity creation, wallet provisioning, handle uh creation, and delegation. But this is a this is an area that can always use more improvement. is by giving people control over their data and their identity, giving them the ability to do things that you can do with blockchain that you can't do in normal platforms, you're introducing some level of essential complexity and you're always starting from a deficit from a user experience.

So these are uh uh things to really focus on. Um the next piece is uh coinless users avoid some of the complexity of acquiring crypto and the very big complexity of KYC that at least in many jurisdictions you have to go through. Uh I'm sure many of you are familiar with the sort of move your head around, validate uh uh uh yourself, prove you're a human and not a deep fake. And um all of those steps just add on to the the the lower conversion rates that we see across many different applications uh when you introduce uh these capabilities that you can get with blockchain. um the overall uh

user acquisition friction is not as good as it can be in web two right now but that's because users actually control their data set directly. Um the next piece here, why coin this users matter is more of a a sort of a value proposition aspect which is uh investment before discovery. Having to acquire crypto as the first step in moving into a uh new application puts the investment before the discovery. You haven't experienced the app yet. The app hasn't convinced you that it's worth the investment, but you are still acquiring crypto in advance. Now, there's some uh uh use cases that this works for, and I'll cover this a little bit more in the business model flexibility, but things

like e-commerce, um things like financial transactions uh work surprisingly well in this regard where you acquire uh uh and you do investment before discovery, but they're relatively limited in the use cases when you look at the overall scope of applications that potentially benefit from blockchain and users being directly in control of their data sets. The next aspect of investment before discovery is volatility risk. Uh putting 10 USD or 10 euro of uh um value into an app that's onboarding you into a particular cryptocurrency being told that gives you a 100 actions in the game you're interested in and when you come back next week it's only 85. Those sorts of

things are things that users are exposed to on a daily basis. It's not the developers fault. They don't control the gas fee marketplace, but it's an impact that it has on users and it hurts the user experience, especially in the very early days, users deciding to use an app and then deciding to come back to an app for that second usage. The next is the microp payments issue. Um, the best case of this is illustrated via uh uh news. But would you choose to pay 13 cents for another news article? Would you would you choose 15 cents or less for financial news? At least 13 cents for sports news, but under 5 cents for general news. These sorts of decisions

are extremely difficult to make when they're this small. Generally speaking, uh microp payments have been the sort of uh payment method of the future for the last 25 or 30 years. And each time they bring this decision tax and ultimately a decision fatigue. Users don't want to make a bunch of micro decisions. They want to be able to make one macro decision around placing trust or uh uh uh buying a bundle or buying a subscription. Uh this is why we uh uh stream so many things now as well because the buying decision is different. Paying one rate getting access to a bunch of stuff is a much lower decision uh uh uh complexity for the user. They have to make much fewer choices overall. And while that's good generally uh you have to counterbalance

this with the uh issue of making sure that users still actually are in control. In many cases um there can be some dark patterns that arise by trying to avoid too many of the decision taxes as well. So there's a there's a bit of a balance here on this side. The final one is business model business model flexibility. So from a um starting point, the uh uh uh the baseline business model of a blockchain is transactional, right? You do a transaction, you pay the fee. It's great. When you open up the ability for other people to pay those transaction fees, whether via delegation, via cost shifting, or other mechanisms, you open up all of the other business models of

the web. You open up things like subscription where I'm paying you potentially in fiat and maybe you're directly sponsoring the gas. Uh you open up uh sponsorship things that look like uh uh Patreon, etc. You also open up uh the three big ones for the web, the three business models that you see over and over and over again. Free trial, premium, and advertising. Free trial is the case where you pay all of my transactions for a certain period of time and then I take over paying them once I found value with the application I'm using. Premium is you pay for the base experience and then there's premium features that I can buy into that potentially I pay for myself. And then you open up of course the advertising model where uh uh your

selling ad exposures to me. And each of these once again can have dark patterns that apply to them as well. But opening up these different business models actually opens the flexibility in a number of different domains. For example, in uh uh uh gaming, in social, in some of these other aspects, these models are basically essential for widpread mainstream adoption. And lastly, how does frequency support coinless users? Our focus has been very much on this user experience I've been talking about over and over again. How can you minimize the onboarding cost? How can you minimize the decision fatigue for users as they interact with the system? Um we have chain level delegation and a prepaid revocation model. Um we do uh cost management uh uh by closely analyzing which sets of

things actually need to be bundled up, which things need to be onchain, which things can be on a layer 2 or be pointed to externally. And then uh we also uh use a shared consensus finality. We're actually a polka dot parachchain, but it's very similar from uh how the cost structures break down as what you look at for an L2 versus an L1. And uh with that uh I'll ask if there's uh any questions. Thank you.

[Applause]