Gabriel Stoica - Building consumer-focused web3 apps

Hi everyone. Thank you very much for uh having me here today. Um my name is Gabrielle. I'm uh leading the protocol development for a company called Emergentics. We are a web3 venture studio.

Um and in the last few years my obsession was bridging web two apps to web3 uh dabs. So that's why today where we're are talking about how to build consumer focused uh web3 apps. Let's go. So this talk is very short. It's everything about abstraction.

So I think I can drop the mic here but let's keep uh pushing. So let's go into a more serious question. So, how many of you know how HTTP2 handles multiplexing? Okay, me me neither. So, um as a user, that's the point.

You don't need to, right? Uh not even when you send a WhatsApp message, it's the app job to deliver. So, that's a good question. So, why should web three be any different? The point is that we need to shift our, you know, the user burden from our users to our depths.

Um, now let's go into a more um easy question. So raise your hand if you've ever tried explaining gas fees to your friends and watch their soul leave their body. Yeah, we need to do something together for sure. That's why today we are trying to fix that. So the problem is that we know for sure that the difference between you know the most used apps out there for example Tik Tok standing at 1.

9 billion users uh Instagram at two two billion users and web3's clanky on boarding staying at 5 um 160 million is huge and we need to do something to address that that's because you know we have a lot of buzzwords for example seed phrases is crypto wallets, multiple chains, dexes, checks, gas fees, bridges. We need to stop. So the question is how to bring users into your app and the answer is very simple by building traditional like experiences. But let's see how we can actually do that. So I identified uh the most important pillars every web uh every uh you know DAP or app building for millions of users must have.

I'm not going to go through each of of them right now because we have a dedicated chapter for for everything. So I I think there's no um there's no need for for a prior introduction. Everyone knows that account obstruction is the you know the you know the most important thing uh we have right now in the space. Uh and for everyone who doesn't know what account obstruction is and does imagine you know web three user experience today is like you know handing someone a Rubik's cube um and saying here's your wallet good luck. So let's go into details and find out how account obstruction can you know um solve um the on boarding problem first.

So account obstruction has something that's called embedded wallets and this uh feature allows our our users to login into our apps by email pass keys face ID or even social login methods which feels like very web two related. Um to build on top of that we can use like predefined and third party providers such as thirddev connect preview web3 o um and appkit then another important thing about the comestruction is that we can sponsor our users transactions um which means that we don't have to block our users on the way of getting gas token the native gas token for example it or any uh other ERC20 token token. So nowadays um I I I would say that you know gas sponsorship became like more uh more like a user acquisition cost and depending on the chain where you are uh deploying uh I think it's important to have dedicated plans for your users for example if you deploy on base where gas fee is very cheap you don't have to you know uh create paid plans but if you build on top of Ethereum for sure you want to subsidize somehow the cost of sponsoring gas uh Uh then another thing is batch having batch transactions. We all know that in order to transfer something uh on the on the blockchain nowadays we need to first approve it and then transfer it. that's inherently bad and we can fix that also with accountraction by batching everything together or even using the new um ERC7702 which is u standing for set code for EOS which allows um EOAs to to run smart contracts and the last thing here is to enhance you know developer experience by using tools built purposely for uh you know better experience like Porto itaka Okay, the next topic on the list is real-time execution, which means that we don't have to force our users to wait to wait until a transaction is confirmed.

So just to get a better sense of this this one, imagine you are going to buy your coffee in the morning. So even though the car payment is acknowledged, so the the payment was you know uh the funds were taken out of your wallet and you see transaction on your app, your coffee is yours, the coffee is yours but the settlement might take you know few days um to be there. So we have the same problem here and why can we you know strictly um solve this in the web three space right now because you know a transaction is not really final until it's settled and irreversible. a terminology which is called um reorganization. So this is um this is this is not happening usually in the blockchain space but if we want to build for you know masses we need to address this problem for sure.

So a chain reorganization happens when the block uh that was added to the canonical chain is removed and the transaction are are uh you know submitted again to the meool and the context of the transaction might change. Here you can see three screenshot screenshots taken from ether scan where we can see three different blocks going through all the three different um states. The first one is unfalized uh where you know all the transaction within that block are not finalized. So there is a small chance that the block can be reverted through a block reorganization and transaction dropped and um put again in the meool. The second one is unfinalized but safe.

At this at this point where we are safe we can you know prompt our users with the result of their operation and then we have the finalized state which cannot be anymore uh reverted. So in what does it mean in terms of um you know time. So here we have a few benchmarks uh across different chains. We can see that in order to be sure that a transaction is finalized on Ethereum mainet we need to wait around two or three minutes. That's because each block on the Ethereum mainet takes around 12 seconds to be um to be created and then we need around 12 confirmations to to be to be safe.

Then on base we have a time of 3 minutes and we have some solutions here. We we see mega eat we see monad which are subfalty blockchains that aim to get um you know a real-time execution but we still have a lot of chains in the space that do not offer subfalty uh time. So we need to address this problem. The solution is to use uh web hooks. Well this is just a workaround for sure.

Uh for example use morality streams API to listen for onchain events. Uh we can store all the transactions in our database with a with a confirmed flag set to false initially and then update to true when the transaction is final and cannot be reverted anymore. How it works pretty fast. Um Morales streams uh sends two requests one for pending one one for confirmed. So you just have to set up a web hook and update your database accordingly.

Then we can talk about indexing data with subgraphs. So, is there in the room is there someone in the room uh having prior experience working with subgraphs? Perfect. Seems like it's 50/50 almost. So, for everyone who doesn't know, subgraphs are like Google for your blockchain data except the fact that you are the one indexing and there's no ad crippy ad tracking.

So let's imagine that you are building a hybrid app and you might need to deal with a two-way storage model, the off-chain and onchain data, right? So you have onchain data coming from your smart contracts and then you have offchain data coming from your users which means dealing with um email addresses, location addresses, um ids and so on. That's why you need subgraphs and you'll see how. So let's take another example. What if you need to track every USDC transfer made by um your user?

So, and if we want to complex to to make this problem more complex, let's think about the user being a smart account deployed to uh through a custom account abstraction factory. So the nonoptimized approach obviously is to listen for all USDC transfers on all chains your app is deployed to and filter by user addresses, decode the logs, extract the amounts and finally store them in your database. Now the optimized way is to use an indexer which is purposely optimized to deal with u things like that. Um for hybrid apps you can aggregate your offchain uh or your offchain database with the onchain one because most of the indexer right now support you know external API calls during the the schema processing processing. Here you can see some of the most used indexers right now.

Uh on the second on the first place MVO the graph and ponder. Then we we didn't still answer that question with the uh USDC transfers. I reach out on on X about that. I reach out on uh to to MVO team about that because I was using MVO to index all our users USDC transfers and even though I was using an indexer there were like 900k events processed and this was pre-launch and seems like they created a way that only gives you the events related to your smart accounts. So now rather than having 900k events, you see only uh the ones related to your uh smart accounts.

And here you have a link if you want to to see more. Uh in terms of performance benchmarks, we can see different cases, use cases and time needed for each um indexer to do its job. We see that MVO is on the second place on the first place then ponder and finally the graph. Okay, moving to the next step is having inapp on and offramp integration which means that of course our users hate leaving our apps to buy crypto or or sell or sell crypto. So um for that we can have you know different uh options out there.

We have transact, we have moon, we have convey, coinbase or archip pay where um we can have fast fiat to crypto. And a real use case for this approach would be to you know allow our users to stake USDC and then you know cash out their profits directly from from our app without leaving uh the flow. Uh as a tip, you can pair these RAMs with gasless transactions from account abstraction u from the account abraction slide and users don't even need it to start. Then a big one is multi-chain having a multi-chain experience. So in my opinion chain should feel like cities.

Uh as you can see each one with its own vibe and strengths. We have you know Italy for good food, Spain for sun and Romania for well um everything above. So what multi-chain experience does and means? So we don't have to lock our users on a single chain. Then we have to build with modularity and crosschain interaction in mind from from day zero.

And as developers we can abstract the complexity with SDKs. We can use dedicated protocols to enable uh crosschain interactions for example layer zero acceler across or circle CCTP v2. Uh another tip here we can leverage smart accounts deployed at deterministic addresses across chain because for example you support Ethereum and base and then your smart account is deployed at a deterministic address which means it will have the same address on Ethereum and base. So even though you switch the chain uh that the same the same address will will be there for for the users. Then a thing that's pretty much connected to the uh multi-chain experience is abstracting wallet addresses.

We have to give wallet names that won't confuse even grandma. Um we see Drake agrees on the first image. We have our usual way to represent addresses on chain. And then we have my proposal which we'll see what it means. So we can buy a dedicated eat subdomain for your DAP.

For example, if your DAP is called my DAB, you can have my dab. And mean for free or paid uh ENS to your users once they join the platform. So what does it mean? This can be seen also as a user cost. you can give them you know um dedicated ENS subdomains connected to your app and this way can you know they can be incentivized to use it across across the ecosystem.

Uh for this we can use ENS based solutions such as namestones during project which can allow one to issue uh subdomains on any or on almost every L2 out there. So you don't have to worry about the cost of uh paying for having your um users subdomains. You can have your um ENS subdomains register on base and then you know the gas fee is very cheap and you can sponsor that as a as another tip. You can pair this with a smart account deployed across multiple chains, right? Because having the same address across multiple chains gives you the opportunity to have the same subdomain across chains and you know namestone during project resolves across chains.

So if you send uh for example any rc20 on gabriel.mmyabit on base it will be received uh on base and you can do that the same you know on ethereum. The bonus topic here is that you know web two has Siri and I I think web 3 deserves better. Um imagine your DAP being able to autooptimizing gas fees or suggesting trades based on each user behavior. Um it's like Siri but on steroids and onchain and smarter.

Um we know that onchain AI agents are coming. It's like the B buzz word in the space right now. We have Conbas agent kit. Um, and this concept can enhance user experience by orders of magnitude. Think about, you know, having your own AI assistant that can, you know, have access to your users onchain data, your personal calendar, your wallet, and yeah, you have your companion.

So now I think you are wondering if there's if there's any app having all of these and I say yes almost you can see it in action um at work.pro Pro. This is a web three software for freerance companies. Um, I've been building this for a while and I try to put everything in there. So, to wrap up everything and prepare for for the Q&A, um, I would say AI uh, account obstruction for web two vibes, crosschain experiences, um, wallet addresses abstraction and subgraphs for uh, real time data.

Questions? Far away. The guest fees are sponsored.

Amazing by me.

They're going to come in now. Please give a hand for Gabriel for that amazing go through.

You really cover like all the synonyms of everything that I never heard about.

Well, no, I heard a lot lot about it. Don't worry. Even

No, even agents I even started working with. I work with I met a guy that making an AI agent wallet literally transacts for you.

Really?

Yeah. It was crazy. So next time maybe we have the next presentation.

Oh, I'll give it I'll give you the address later. Do we have any questions from the audience today?

Of course that Gabby does is the revamp, right?

Hi Gabriel. Uh I see you not uh you mentioned 7702 the IP. What do you think uh in point of security uh concerns? What do you think about it?

Yeah, that's that's a good question. So first thing first, I think 7702 is more like a companion for account obstruction and really depends on the needs of your business. So if you want top level security, you should go for for a smart account for sure that's you know created and audited by uh well-known companies, security companies in the space. Whereas if you want flexibility and be able to adapt flows, you should go for 7702. Uh in terms of security, I see a lot of companies creating their own 7702 implementation.

For example, MetaMask has its own. Uh I feel like even though uh it unlocks a lot of things in the space, we should only allow uh you know um the most audited contracts to be used for for mass adoption. For sure.