▲▲▲

Paralelní Polis is a one-­of-­a-­kind nonprofit organization that brings together art, social sciences, and modern technologies. The ideas of liberty, independence, and innovative thinking and development of society are the main underlying foundations the whole project is built upon.

The project intends to remain state-free as it operates entirely without support from the government, and most of the funds come from voluntary contributions of our donors and partly from commercial activities such as running a unique co­working space and the world’s first bitcoin-­only cafe.

It was founded by members of a contemporary-­art group Ztohoven, and Slovak and Czech hacker­spaces. Its main goal is to promote economic, social, and digital freedom. We try to be a vocal voice of freedom in order to shape the public discourse, and ultimately work towards a freer future.

Welcome to my presentation without a deck.

I founded Portis back in 2018, which was acquired by Shapeshift in 2020.

in the beginning of this year to work around account abstraction to act as a product manager.

So when we're talking about account abstraction, we generally want to get around the problem of EOAs and as we all know, EOAs, externally owned accounts, are challenging, to say the least.

So some of the challenges, and I'll go over them briefly because this isn't a talk about account abstraction.

In general, I'm going to go briefly over that for people who are not that familiar with it.

But there is something more interesting which I want to get into.

And we're also a little bit short for time.

So EOAs are mostly a problem because of the fact the big problem Is that it's 1 key, you know, you have this 1 key to rule them all you lose your 1 key You lose your funds you make too many copies.

You lose your funds and So there's it's really problematic in terms of UX, but a bigger challenge I think in the world of Ethereum is the fact that there's no key rotation.

For instance with Bitcoin if you fail your keys compromise you can just easily say okay I'm just moving all my assets to a different wallet that's it.

With Ethereum it's not just your key that you own, it's also your address, your public key, which is known in different contracts.

So if you want to rotate your key, there's no easy way of doing that, and sometimes it's not even possible.

Some contracts may say, oh look, there's a time delay for a year if you want to change your wallet or whatever.

We noticed that a lot in Portis because we were a self-custody wallet.

If someone lost their password, they didn't write down their C phrase, we would be in a situation where we would be like, well, we're sorry, there's not much we can do about that.

In addition, there's no granular control, right?

If we're talking about just 1 single key, it means it's 1 single key that does everything.

And you know, in the world of Web 2, when you're using like bank accounts, stuff like that, you have a lot of safeguards in place which we don't have with just 1 single key.

So no multi-sig, no spending policies, no nothing.

Also, in terms of gas payment, well, you know, when you want to use, when you want to sign a transaction, then you got to have some ETH in your wallet.

That's a huge challenge, both from an onboarding perspective, but also from a privacy perspective.

If I want to just claim an NFT with a wallet with a brand new wallet I need to have some ETH in that wallet which means that ETH had to originate from somewhere which might be KYC'd so I'm losing that privacy.

With Paymasters we can have the gas be paid by a third party.

That wallet remains pristine in the sense that nobody knows where it came from.

And also for dApps, EOAs are a challenge because there's no flexibility.

Like there's no batching, there's no, you know, stuff like automation.

If you want to have a recurring payment, so I want my wallet to listen to an event, a trade that happens and automatically do something, there are ways to accomplish that, but they require usually some sort of centralization or trust, which we don't like that much.

So with account abstraction, we're basically abstracting 3 things.

The validation of your transactions, which I would break down into 2, which is the authentication and authorization.

And what we're changing here, it doesn't have to be just an ACSDA key.

It can be any key we want and we're seeing wallets doing using either their secure enclave which is a great option or Which basically turns every smartphone into a hardware wallet or signing with Google if you want that's fine for Whatever that key can do which is the second part which is the authorization?

Yes, the authorization which says what is this key allowed to do?

So, thanks to account abstraction, we can have this much better control over permissions.

Something we're used to from web 2, right, ACLs, stuff like that.

We're getting the same concepts which we need to have.

Execution which I mentioned, the automation, the batching of transactions, that is also something that we are allowing to abstract, even nonsense is something that we are semi-abstracting which allows you greater flexibility when you're talking about you know signing transactions at the same time for multiple entities etc oh wait we got slides okay great so and Okay, great.

And finally I think I mentioned gas payment.

So allowing third parties to pay for gas fees, either fully subsidize it or they accept USDC and they pay the ETH.

This has been a very big challenge for dApps and wallets in general.

And having something which is part of the protocol, something that is standardized, really, really helps user adoption.

So I mentioned what we get out of the full account abstraction.

The censorship resistance is very important.

So a lot of account abstraction proposals, or not proposals, but solutions that are out there right now they have some sort of centralization element to them mostly around reeling the transaction because Ethereum is still a theorem you still need an eo a wallet to sign a transaction because that's how the protocol works So there is some sort of a centralization because you don't have the equivalence of bundlers and everything that ERC-4337 has.

Speaking of bundlers, we're also very admonitant about this being a robust infrastructure.

Just like how you have a lot of Ethereum clients, we also want to have a lot of bundler clients, which keep in mind, they're very similar, okay.

Bundlers are block builders in a sense or are working with block builders.

They are not submitting the big transaction that is full of user ops to the mempool.

They are submitting it as the next block.

Otherwise, there's all kind of front-running and problems like that.

So we want to make sure this is very robust, and there's a lot of implementations.

And currently, we have TypeScript, Go, Rust.

And this is part of the great thing about ERC 4337, there is no protocol change.

And I see we have not a lot of time left, so I'm not going to dwell on this too much, but you can check out the new website we have, and you can have a lot of resources there and a lot of information.

Okay, so we're getting to the interesting part of the talk, which is beyond account abstraction.

Let's say that everybody uses ERC 4337, and killer dApps are here, and we're going for 1000000000 users, we've done it.

We have some killer dApps out there, and they want to get to mainstream adoption.

This information will not really matter once we move beyond ERC

into an EAP, meaning this is actually enshrined in a protocol.

But we don't expect this to happen for at least a couple of years.

And we can't just wait for that to happen.

If we want to get to mainstream adoption soon, we have to account for things which I'm going to talk about in this conversation.

So a part of creating an account with account abstraction with ERC4337 is deploying a smart contract.

And deploying smart contracts is quite expensive.

And when we calculate how much that can end up costing on each network.

And also, the price has changed in the last 2 days.

But these are roughly the prices per network.

Some of them, the calculation is a bit different.

If we're talking about networks like Optimism and Arbitrum, It's not exactly the calculation I showed beforehand, but these are roughly the costs.

Now, this raises a question, like, who pays for that, right?

First of all, there's a problem with the fact that it costs as much as it does in the sense that just imagine on web 2 just creating a user account costs you like 50 cent per user.

Just creating the user, just like putting that DB entry in your centralized server would be that expensive.

Because you're not just paying a lot, relatively a lot, right?

You're also sponsoring the next DAP that comes along, assuming that the DAP pays that through a paymaster, which is a very reasonable thing to assume.

Because right now, wallets, like let's say, for example, Argent, are paying for deploying the contract.

But that's because they're aiming at traders, people who are not exactly the average person.

If we're talking about someone just onboarding to your application and fulfilling that hopeful dream that they don't even know it's blockchain, It has to be transparent to them.

But then the user goes to the next application, and, well, that's great.

And from a product perspective, from a business perspective, that is something we have to resolve for the applications, because they will have an issue with that, like saying, why do I pay for the next guy, right?

First of all, you don't have to create the wallet right away.

Using Create-To, you can have the address of the contract in advance.

So if you want to just receive funds or whatever before that and have just an address without paying the deployment cost, we can have that.

But until EAP6492 or any other solution is implemented that allows signatures for, you know, pre-deployed contracts to be created and adopted by the networks, There are some solutions there, and you all from our team came up with a lot of great ideas around that.

Signing messages is something that is essential in the onboarding process.

And until we have that, we still have to think about, OK, how do we solve the cost of deploying a contract?

Because until you deploy the contract, there's not much you can do.

So we're like, OK, we'll deploy the contract.

And once you start actually spending your hard-earned cash on buying stuff, then you owe us a little bit.

The problem there, the challenge, is that there's risk, because who's to say that user will end up buying anything?

So you put up the money first, but then it doesn't end up paying you.

And if we're talking mainstream adoption, millions of users, percentage-wise, that becomes a game of numbers which can be very difficult.

We all don't like ads that much, but it works.

Then we can have this kind of like triangular approach where the user sees ads and the paymaster gets compensated from the ad agency, and they pay for the cost.

So the dApp isn't even a part of that, right?

It's like all between the wallet and the paymaster, and it's like super simple for the dApp.

But there is a cost here as well when you think about it, which is the brand, right?

I'm seeing a lot of ads to create my account.

Then when I'm going on application 2, I see nothing.

So the first application also paid something for the next application, in a sense, which is diluting its brand.

The second application has a great experience.

So that's also not so great in just ignoring that fact that the first application pays for everything.

There's a word in Hebrew, okay, which is flyer.

Flyer means to be a sucker, but it's a big part of our culture that nobody wants to be the sucker.

In this case, the first application is the sucker.

It's paying somehow, either directly, with its brand, or by assuming risk.

So 1 approach, which I think is a nice way to think about it, is amortization, which is something from finance.

It's not exactly like amortization, but it kind of gets the idea across, which is where everybody pitches in as more dApps join in.

Okay, so the rules, the basic rules, and this is just, this is not something, you know, this is just like a beginning of a conversation here.

Okay, so Accounts when you create a new account as a user through a DAP first, you're limited to only using that DAP Okay, you can only interact with its contract could it paid for it?

You can still do basic stuff like send money to your friends or receive funds, whatever, but you can't interact with other contracts You can always buy your freedom pay back the depth what it what it paid and you get back full control of your account And as more daps join they get they also are able to enter allow the user to interact with their contract.

At some point, you open up the contract completely, because from a gas payment, doing all that calculation just doesn't make sense anymore.

So this is a pretty straightforward approach.

Assuming G is the gas cost of the initial deployment, this is how much DAP number I will pay.

The next 1 will pay half the gas cost of the first app.

And moving forward, you can also see how much it will pay for each individual app.

Now, this is a little hard to understand like this.

So I created a nice little animation, which I hope will work after all the shenanigans.

So it will look like this, but let's see.

So the first DAP pays, for the ease of understanding, let's assume the gas cost is 1, 1 of whatever, doesn't really matter.

So the first 1 pays 1, then the second 1 pays half to DAP 1.

So now DAP 1 in essence paid half, the second 1 paid half, they're like equal partners in how much they paid.

The third DAP will pay a third divided between each 1, so it's one-sixth and one-sixth.

You do the math, you see everybody paid a third, and we're all equal partners in how much we paid.

It's one-fourth, one-twelfth to each 1, and slowly over time, everybody is pitching in in the same way.

And, yes, once 10 dApps have paid, have pitched in, like the user already logged into 10 different dApps and they all pitched in, you'll see that the original deployer only paid

of the original cost, making this a lot easier for them to swallow.

Also from a business perspective, they know all the other dApps pay 10% so they can feel a lot better about it.

From a game theory perspective, they don't feel like they came out as a friar.

Then it takes another 10 dApps to only get 5 more percent.

So it doesn't really make sense also from the calculation.

And how exactly is this implemented in terms of the contract itself?

It wouldn't make sense to calculate and pay every time, obviously.

You can just keep track of how many dApps have participated, and whenever a dApp wants to cash out, it can, but most of the time, things can even out, because it pays to onboard a new user but it also got paid from a previous DAP, so probably doesn't make sense to constantly pay each other, obviously, from a gas perspective.

Well, obviously, but just some food for thought when you walk out of here.

So maybe we want to ask new dApps to also account for the interest of how much, like, they paid 1 month ago, if they put that money into some sort of staking mechanism, they would have earned interest on it.

So maybe the next app also has to pay for that interest to make it completely fair.

And maybe we can have a more sophisticated, we definitely can have a more sophisticated amortization mechanism, something less linear, maybe a bit more accounting for all kinds of edge cases, et cetera.

And what we're starting to see in the ecosystem is wallets that are very modeler.

And the model, like you have this basic smart account, and you have models that can model, so you can plug into.

So maybe this is a way to also compensate those models.

And another way of managing the balance that I talked about is maybe through paymasters, which can reduce a lot of the gas costs because it happens off-chain, but can be done in a way which still maintains security and not a problem of trust.

I have 10 seconds, so I'll just wrap up with this.

Web 3 makes us rethink how we approach things that in Web 2 seems like completely basic problems.

Check out our website or follow us on Twitter, And let's go for those 1 billion users.

I'm afraid we don't have time for questions, unfortunately.


Speaker 0: Yeah, okay. So hi, everyone. Welcome to my presentation without a deck. So my name is Tom Thieman. So a little bit about myself.

I founded Portis back in 2018, which was acquired by Shapeshift in 2020. And I joined the foundation

Speaker 1: in the beginning of this year to work around account abstraction to act as a product manager. So when we're talking about account abstraction, we generally want to get around the problem of EOAs and as we all know, EOAs, externally owned accounts, are challenging, to say the least. So some of the challenges, and I'll go over them briefly because this isn't a talk about account abstraction. In general, I'm going to go briefly over that for people who are not that familiar with it. But there is something more interesting which I want to get into.

And we're also a little bit short for time. So hopefully, we'll get there quickly. So EOAs are mostly a problem because of the fact the big problem Is that it's 1 key, you know, you have this 1 key to rule them all you lose your 1 key You lose your funds you make too many copies. Someone can get a hold of them. You lose your funds and So there's it's really problematic in terms of UX, but a bigger challenge I think in the world of Ethereum is the fact that there's no key rotation.

For instance with Bitcoin if you fail your keys compromise you can just easily say okay I'm just moving all my assets to a different wallet that's it. With Ethereum it's not just your key that you own, it's also your address, your public key, which is known in different contracts. So if you want to rotate your key, there's no easy way of doing that, and sometimes it's not even possible. Some contracts may say, oh look, there's a time delay for a year if you want to change your wallet or whatever. So it's a big problem.

And recovery is also a big issue. We noticed that a lot in Portis because we were a self-custody wallet. If someone lost their password, they didn't write down their C phrase, we would be in a situation where we would be like, well, we're sorry, there's not much we can do about that. In addition, there's no granular control, right? If we're talking about just 1 single key, it means it's 1 single key that does everything.

And you know, in the world of Web 2, when you're using like bank accounts, stuff like that, you have a lot of safeguards in place which we don't have with just 1 single key. So no multi-sig, no spending policies, no nothing. This 1 key does everything. No granular control. Also, in terms of gas payment, well, you know, when you want to use, when you want to sign a transaction, then you got to have some ETH in your wallet.

That's a huge challenge, both from an onboarding perspective, but also from a privacy perspective. If I want to just claim an NFT with a wallet with a brand new wallet I need to have some ETH in that wallet which means that ETH had to originate from somewhere which might be KYC'd so I'm losing that privacy. With Paymasters we can have the gas be paid by a third party. So I can just create a new wallet. Someone else pays for gas.

That wallet remains pristine in the sense that nobody knows where it came from. We can have the privacy that we want. And also for dApps, EOAs are a challenge because there's no flexibility. Like there's no batching, there's no, you know, stuff like automation. If you want to have a recurring payment, so I want my wallet to listen to an event, a trade that happens and automatically do something, there are ways to accomplish that, but they require usually some sort of centralization or trust, which we don't like that much.

We were trying to avoid stuff like that. So with account abstraction, we're basically abstracting 3 things. The validation of your transactions, which I would break down into 2, which is the authentication and authorization. Authentication is, is this key valid? And what we're changing here, it doesn't have to be just an ACSDA key.

It can be any key we want and we're seeing wallets doing using either their secure enclave which is a great option or Which basically turns every smartphone into a hardware wallet or signing with Google if you want that's fine for Whatever that key can do which is the second part which is the authorization? What can it? Yes, the authorization which says what is this key allowed to do? So, thanks to account abstraction, we can have this much better control over permissions. Something we're used to from web 2, right, ACLs, stuff like that.

We're getting the same concepts which we need to have. There's good reason why they came about. Execution which I mentioned, the automation, the batching of transactions, that is also something that we are allowing to abstract, even nonsense is something that we are semi-abstracting which allows you greater flexibility when you're talking about you know signing transactions at the same time for multiple entities etc oh wait we got slides okay great so and Okay, great. So this is where I am right now. And finally I think I mentioned gas payment.

So allowing third parties to pay for gas fees, either fully subsidize it or they accept USDC and they pay the ETH. This has been a very big challenge for dApps and wallets in general. And having something which is part of the protocol, something that is standardized, really, really helps user adoption. Which brings us to ERC-4337. So I mentioned what we get out of the full account abstraction.

I won't go over that again. The censorship resistance is very important. So a lot of account abstraction proposals, or not proposals, but solutions that are out there right now they have some sort of centralization element to them mostly around reeling the transaction because Ethereum is still a theorem you still need an eo a wallet to sign a transaction because that's how the protocol works So there is some sort of a centralization because you don't have the equivalence of bundlers and everything that ERC-4337 has. Speaking of bundlers, we're also very admonitant about this being a robust infrastructure. Just like how you have a lot of Ethereum clients, we also want to have a lot of bundler clients, which keep in mind, they're very similar, okay.

Bundlers are block builders in a sense or are working with block builders. They are not submitting the big transaction that is full of user ops to the mempool. They are submitting it as the next block. Otherwise, there's all kind of front-running and problems like that. So we want to make sure this is very robust, and there's a lot of implementations.

And currently, we have TypeScript, Go, Rust. I'm missing a few, but a lot. And this is part of the great thing about ERC 4337, there is no protocol change. Okay? And I see we have not a lot of time left, so I'm not going to dwell on this too much, but you can check out the new website we have, and you can have a lot of resources there and a lot of information.

Okay, so we're getting to the interesting part of the talk, which is beyond account abstraction. Let's say we've made it. Let's say that everybody uses ERC 4337, and killer dApps are here, and we're going for 1000000000 users, we've done it. We have some killer dApps out there, and they want to get to mainstream adoption. Image is upside down.

That's kind of funny. So a spoiler. This information will not really matter once we move beyond ERC

Speaker 0: 4337

Speaker 1: into an EAP, meaning this is actually enshrined in a protocol. But we don't expect this to happen for at least a couple of years. And we can't just wait for that to happen. If we want to get to mainstream adoption soon, we have to account for things which I'm going to talk about in this conversation. So a part of creating an account with account abstraction with ERC4337 is deploying a smart contract.

And deploying smart contracts is quite expensive. And when we calculate how much that can end up costing on each network. And these are rough estimates. And also, the price has changed in the last 2 days. So things are different.

But these are roughly the prices per network. Some of them, the calculation is a bit different. If we're talking about networks like Optimism and Arbitrum, It's not exactly the calculation I showed beforehand, but these are roughly the costs. Now, this raises a question, like, who pays for that, right? First of all, there's a problem with the fact that it costs as much as it does in the sense that just imagine on web 2 just creating a user account costs you like 50 cent per user.

Just creating the user, just like putting that DB entry in your centralized server would be that expensive. But there's a bigger problem here, okay? Because you're not just paying a lot, relatively a lot, right? You're also sponsoring the next DAP that comes along, assuming that the DAP pays that through a paymaster, which is a very reasonable thing to assume. Because right now, wallets, like let's say, for example, Argent, are paying for deploying the contract.

But that's because they're aiming at traders, people who are not exactly the average person. If we're talking about someone just onboarding to your application and fulfilling that hopeful dream that they don't even know it's blockchain, It has to be transparent to them. It's not like a trade or wallet. So the application will pick up the tab. But then the user goes to the next application, and, well, that's great.

They get that bonus for free, right? And from a product perspective, from a business perspective, that is something we have to resolve for the applications, because they will have an issue with that, like saying, why do I pay for the next guy, right? There are some caveats here. First of all, you don't have to create the wallet right away. Using Create-To, you can have the address of the contract in advance.

So if you want to just receive funds or whatever before that and have just an address without paying the deployment cost, we can have that. But until EAP6492 or any other solution is implemented that allows signatures for, you know, pre-deployed contracts to be created and adopted by the networks, There are some solutions there, and you all from our team came up with a lot of great ideas around that. Signing messages is something that is essential in the onboarding process. And until we have that, we still have to think about, OK, how do we solve the cost of deploying a contract? Because until you deploy the contract, there's not much you can do.

So 1 approach is IOUs. I mentioned Arjun. So we're like, OK, we'll deploy the contract. And once you start actually spending your hard-earned cash on buying stuff, then you owe us a little bit. Pay us back.

The problem there, the challenge, is that there's risk, because who's to say that user will end up buying anything? So you put up the money first, but then it doesn't end up paying you. And if we're talking mainstream adoption, millions of users, percentage-wise, that becomes a game of numbers which can be very difficult. Another approach is ads. We can have the user see ads.

We all don't like ads that much, but it works. Then we can have this kind of like triangular approach where the user sees ads and the paymaster gets compensated from the ad agency, and they pay for the cost. So the dApp isn't even a part of that, right? It's like all between the wallet and the paymaster, and it's like super simple for the dApp. But there is a cost here as well when you think about it, which is the brand, right?

Because seeing ads isn't fun. So I'm going on application 1. I'm seeing a lot of ads to create my account. Then when I'm going on application 2, I see nothing. So the first application also paid something for the next application, in a sense, which is diluting its brand.

The second application has a great experience. So that's also not so great in just ignoring that fact that the first application pays for everything. Again, the images flip outside. It's even better this way, I think. The issue remains, okay?

There's a word in Hebrew, okay, which is flyer. Flyer means to be a sucker, but it's a big part of our culture that nobody wants to be the sucker. In this case, the first application is the sucker. It's paying somehow, either directly, with its brand, or by assuming risk. So what can we do about it?

So 1 approach, which I think is a nice way to think about it, is amortization, which is something from finance. It's not exactly like amortization, but it kind of gets the idea across, which is where everybody pitches in as more dApps join in. Okay, so the rules, the basic rules, and this is just, this is not something, you know, this is just like a beginning of a conversation here. Okay, so Accounts when you create a new account as a user through a DAP first, you're limited to only using that DAP Okay, you can only interact with its contract could it paid for it? You can still do basic stuff like send money to your friends or receive funds, whatever, but you can't interact with other contracts You can always buy your freedom pay back the depth what it what it paid and you get back full control of your account And as more daps join they get they also are able to enter allow the user to interact with their contract.

At some point, you open up the contract completely, because from a gas payment, doing all that calculation just doesn't make sense anymore. So this is a pretty straightforward approach. Assuming G is the gas cost of the initial deployment, this is how much DAP number I will pay. The first DAP pays G. The next 1 will pay half the gas cost of the first app.

And moving forward, you can also see how much it will pay for each individual app. Now, this is a little hard to understand like this. So I created a nice little animation, which I hope will work after all the shenanigans. So it will look like this, but let's see. Great, okay, it seems like it's working.

So the first DAP pays, for the ease of understanding, let's assume the gas cost is 1, 1 of whatever, doesn't really matter. So the first 1 pays 1, then the second 1 pays half to DAP 1. So now DAP 1 in essence paid half, the second 1 paid half, they're like equal partners in how much they paid. The third DAP will pay a third divided between each 1, so it's one-sixth and one-sixth. You do the math, you see everybody paid a third, and we're all equal partners in how much we paid.

Moving forward, you get the point. It's one-fourth, one-twelfth to each 1, and slowly over time, everybody is pitching in in the same way. And, yes, once 10 dApps have paid, have pitched in, like the user already logged into 10 different dApps and they all pitched in, you'll see that the original deployer only paid

Speaker 0: 10%

Speaker 1: of the original cost, making this a lot easier for them to swallow. Also from a business perspective, they know all the other dApps pay 10% so they can feel a lot better about it. From a game theory perspective, they don't feel like they came out as a friar. It then starts to taper off, right? Then it takes another 10 dApps to only get 5 more percent.

So it doesn't really make sense also from the calculation. And how exactly is this implemented in terms of the contract itself? There's a lot of cool ways to do it. It wouldn't make sense to calculate and pay every time, obviously. Each dApp can put up a lot of money.

You can just keep track of how many dApps have participated, and whenever a dApp wants to cash out, it can, but most of the time, things can even out, because it pays to onboard a new user but it also got paid from a previous DAP, so probably doesn't make sense to constantly pay each other, obviously, from a gas perspective. Can we do more? Well, obviously, but just some food for thought when you walk out of here. So maybe we want to ask new dApps to also account for the interest of how much, like, they paid 1 month ago, if they put that money into some sort of staking mechanism, they would have earned interest on it. So maybe the next app also has to pay for that interest to make it completely fair.

And maybe we can have a more sophisticated, we definitely can have a more sophisticated amortization mechanism, something less linear, maybe a bit more accounting for all kinds of edge cases, et cetera. And what we're starting to see in the ecosystem is wallets that are very modeler. And the model, like you have this basic smart account, and you have models that can model, so you can plug into. So maybe this is a way to also compensate those models. And another way of managing the balance that I talked about is maybe through paymasters, which can reduce a lot of the gas costs because it happens off-chain, but can be done in a way which still maintains security and not a problem of trust.

I have 10 seconds, so I'll just wrap up with this. Web 3 makes us rethink how we approach things that in Web 2 seems like completely basic problems. Check out our website or follow us on Twitter, And let's go for those 1 billion users. Thank you very much.

Speaker 2: Wonderful. Thank you, Tom. Give me a round of applause. What a fantastic talk, mate. I'm afraid we don't have time for questions, unfortunately.

But you can put them online, if

Speaker 1: you

See all Parallel Polis transcripts on Youtube

ERC-4337 Create Account - who pays for gas? / Tom Teman