DAPPCON 2025: Relationships in App Building: Who Needs to Know What? - Gregthegreek.eth

Transcript

Hello everybody. Uh my name is Greg and I'll be talking today about effectively data duplication and you know what do you really need to know when building an app and what can we get better served to us. A little bit about me you know I'm one of the co-founders at Sprinter uh which is solving team and chain safe a protocol development shop. The history for me is uh a little bit interesting. I started in protocol development. I started the loadar consensus client for Ethereum and then eventually became a core one of the core developers and lead maintainers for web3js and that eventually led me into the solving space and and it's quite relevant because if you look at the course of where I focus on and things I

do um from core development uh that shouldn't have been there well the user group rather is uh to developer and then you know I've started ended up on the user UX level and even though most of my time now used to be core development and then kind of moving into the solving space. The end goal where I got to is UX and it's fundamentally where I think there's a lot of improvements we can still make back down through the provider libraries back into the protocol to improve everything. And so, you know, simply put, users are have a very simple narrative in the space.

They really don't care about much aside from performing an action. they really just want to do, you know, buy a very simple NFT. And in the development life cycle, when we think about when you're building that kind of, you know, as a developer, you build out your front end, there's a good chance you end up having an API. This is due to the fact you might need like indexing services propped up and in doing so, you're doing your indexing, maybe something through Ponder a little bit easier, or you're just doing it yourself. Um, and you have like this connection where you're, you know, a lot about both the app you're building and the users coming to your websites, right? They connect to your they connect via wallet. You know who they are. You might be fetching the balance to help progress the the state of the actual app

through, right? Progressing them through the user journey. Um, but in Oh, can you see that? Okay, you can. Coincidingly though, you know, the wallet's the one that actually does the transaction signing and it's the one submitting to the chain. But they're also built upon typically an API that does in indexing and does you know therefore also indexing via RPC and so we kind of have this like duplicative work happening right like if you look back we're both looking and trying to get the balances and understand the users so we can progress our state forward and there's it creates a lot of duplicate work a lot of duplicate data that's not really needed because you might not as an app you don't really know the user

And so if we go back to like the simple story, right, they want to do something. Now, as we've gone like multi-chain and as Connor, you know, previously just presented there, things get complicated. And so we provided people with, you know, more simple tools, bridge swap, and purchase if they're not on the chain you want. Uh, and we solved this further by providing bridges and intents, which connect to like 10 other chains, and your user is still in the same position. you know, all they really care about is this, right? They just want to buy your NFT. Um, and what this has done to the data model when it comes to apps actually building their applications, it's it starts to grow and it starts to bubble. You know, in this image that we

saw before, the big difference we start to get is now the RPC now you're just indexing like 10 different chains. Um and really the core reason for this for those that have built an app you typically need balance as like a primitive to understand do they have you know USDC or do they have ETH or die to just do something and if they don't you block them at the UI level right like you just do not progress them through the app and doing a simple get balance simply is not sufficient enough in nine time most of the cases because they probably don't have balance on the chain you're on uh might be a new L2 or your own custom L2 to or whatever, but they just don't have the balance where you need it when you need it. And so, you know, the intent space has tried to fix

that. This is just creating more duplicate work because again, the data is just constantly flowing between the exact same providers, right? As you you know, that was the right one. You know, like you're collecting the exact same data here that you're collecting right here. There's like it it's we're all collecting the same data. And again we observed this was a problem for the apps. So we decided to try and solve it. You know the chain abstraction movement came to be and so we gave them a bunch of SDKs and now app developers have about 50 different about 10 different decisions to make. Right? It's like which chain abstraction provider do I use? What are the tradeoffs? Some have custom accounts you have to built into them. Some don't. Some use existing

systems. Some are brand new systems. But either way, we basically offshoot trying to like get rid of the fact that you don't have you shouldn't be indexing every chain to understand your user and instead just index maybe the data to your contract. But what's happening under the hood here is borderline the exact same story. They're collecting the exact same data. The data problem is constantly going where they need to know what balances you have, what positions you have open in DeFi as a user. uh and we're constantly pulling in the same data and then basically giving an alternate way for that money to flow or the funds to flow from the end wallet. And this is where the story in my mind gets a lot simpler and we can actually improve a

lot of this. So a lot of what we've been doing and especially in the chain abstraction movement you know as a solving team right we deal with this all the time solving intents on various platforms some like cow swap or like across and so on so forth where a lot of this abstraction is taking place vast majority of applications do we have app developers here but like vast majority of applications do not need to do complex flows right a complex flow might be okay I'm you're a portfolio manager and you're moving and rebouncing funds between chains. So, you need to do all these like complex build these complex crosschain queries. Nine times out of 10, you do not need that. Most apps are like deposit into my LP

position, deposit into this vault, you know, move on, come back in like a week. And so, for 90% of the cases, you do not need all this abstraction. It's just simply too much. And for that cohort that does, these SDKs fulfill your requirements. But because they're being sold at every app needs this if you want to get multi-chain support or crosschain support is a complete farce. It doesn't make sense, right? Like you shouldn't have to think about how to get the user to your app because you deployed into an ecosystem. The user should be able to just get there by interacting with just the call data that you want on the chain you want it. And I like to look at it like this. We have to look at it from

the world view of like who's best posed to actually do this work, right? The world view of a user like a wallet interacting is at the wallet level, right? They have the best understanding of the user and the application by no means would ever understand the user best. And this is because users express preferences, they express desires with their wallets. Wallets are moving towards this scene now with the intents especially that they can start to be very expressive. They can say like how they want their assets to be managed within the context of the wallet.

Applications just simply express an intent with the user. They're just saying I need you to do this if you want to progress through the UI, if you want to progress through the user interface. And there's a stark difference here, right? It's like in your onboarding flow, should you always be asking the same 10 questions that every other app is going to start asking you, which is like, do you want to treat all your stable coins as a single balance? Do you want to spend from a every network or only spend from certain networks? This shouldn't be a question of the app developer. This should be a question that is just like naturally imposed on the user at the earliest point in the journey, which as I said before, you know, it's the best world view that exists is at the wallet level. They know the user best. the application doesn't

and the application shouldn't know you that well they should just know that you should be able and can execute on something and so I give this example you have 5,000 die and in that balance it's a mixture of die sorry so you have NF you want to buy an NFT for 5k and you have about 100 die 100k in USDC or 10k in USDC and 100k in an a position of USDC the best way to compose this shouldn't be up to the app to decide side because the app has no idea what you are and what you prefer. They have no idea that you would want to spend from your USDC balance in a it's just unknown to them and they can ask you and you can brick your UI and make your UI

really overloaded and complex or it just sits at the wallet level. And this is where wallets are trending to, right? They're trending to giving solutions like merge all your stable coins. They should be treated one to one, right? They're all USD. They're all USD based. Why shouldn't they be one to one? Spend from your lending positions. you might want to spend because it's the most cheap and optimal way to move funds is out of your a position or your morpho position and then it starts to get more complex but you know you can optimize for speed optimize for latency depending on cost and things and so forth but your wallet has the world view of the user and as a consumer application why should you be integrating SDK through SDK to try and get a better understanding of the world of the user's preferences and

desires instead just have it supplied to you. And so it's really just a problem of communication and it's because we haven't really updated or augmented a lot of our API specs at the JSON RPC level and the wallet the wallet API level. I'll give you an example. This is ETH get balance and egget balance is works for a single chain. You know you call an RP you call a node via RPC. It returns you the balance of ether. You can then morph this a little bit and throw in the token contract get the balance of a specific token. You're stuck to a single chain. It's quite simple. You have address and block number and that's just where you want to go.

There's a few competing proposals out there. Um, and this is the simplification for it. And this would completely remove a ton of the data duplication problem. It would allow an application to get crosschain natively without having to think about an SDK. It just comes directly from the wallet. Uh, and there's already quite a bit of support to have something like this implemented in some of the major wallets. The change is to basically upgrade get balance to get available balance which is based on user desires and user preferences. What is the balance that the user has for something?

The change is super simple. You get the chain ID of where the call data would be executed. This might be base, optimism, mainet, wherever. And then you give it the address or addresses of tokens, whether it's the native asset or random tokens on that chain that you want to accept for this whatever to progress your UI. You might supply the USDC address on base. You might supply the USD the USDT address on base or even native ether. This small change right here. Ah, I had transitional slides. Um this small change by the chain ID and the asset removes all the complexity from the app developer gives native

multi-chain by default because then what you do is you offset the entire chain of who's executing what to the wallet. You tell the wallet, here's the call data. Here's the chain. I was able to progress the user through the application because you told me it has, you know, nine in my previous example, you have 99k worth of die to spend even though I only had 500. I can progress them through and with a small change to the wallet API spec and it looks almost identical when you compare like what the spec, you know, what a user would be doing. It looks almost nearly identical. there's very little lift and the provider libraries can basically just upgrade get balanced by

default. We're able to go fully multi-chain day one as an application and not worry about, you know, okay, I've got my idea, I've built the contracts, I have to spend like 20 hours of engineering work on the front end to figure out which SDK is the best for me. You just get out of the box and if you're more complicated, you can use one of the SDKs. What it does is it removes the need for infrastructure. You know, apps historically if you know from the crypto ethos back in the day, it was like we should run this all in IPFS. You shouldn't need to have anything. You get a hashed piece of the front end. You know exactly what you're running. It just works. You don't need all this API complexity. And so we can

slowly remove the SDKs for the non-complex apps. we can slowly remove all the indexing needed unless you need specific, you know, your personal contract data indexed or whatever API requirements. You never call get balance yourself. You offshoot it directly to the wallet and the wallet returns you exactly what you know is available to spend. And what this the you know the the log the step the next step in this process is that when you go to submit call data the really simple path is you've got in the balance you know what they're able to spend you say okay here's the call data given their available spend the wallet teams now can deal with the actual process of getting

the funds there and executing the call data as needed. Wallets are moving towards solverbased systems. They're leveraging third parties, whether they're market makers, solvers, solutions like we just saw previous on the previous presentation. They're leveraging these solutions to do it natively. So they can embed it and have their direct flows. And we can completely remove all this infrastructure and we can completely get rid of this infrastructure. We can stop selling applications that they need to go spend like enormous amounts of effort implementing other stuff, making decisions for users that they're not qualified to be making. And we can simplify the entire development process so that it's like, you know, you deploy your contracts, you whip up a really simple front end, and it just works. And

it's just one API, one very simple API because the wallets are already doing all this work anyway. They're vetting your transaction. They're verifying it. They're running it through security policies. They're indexing every token you have and every DeFi position you have. They already have this data. We just haven't given them the ability to expose it to frontends in a clean way. And you know, you might ask, what if the wallet doesn't support it? It's really simple. You just fall back. You know, you fall back to the most basic get balance and it proxies it through and it just says on the chain you're currently on, my user has no funds. And that's just because the wallet doesn't support it. You're back to the old experience.

This is purely an augmentation with like next to no downside. Um that is that you know if you believe in a intent in a solverbased system like future like this is a logical next step to like really remove a lot of the infrastructure we're selling from this chain abstraction movement slimming things down and making it easier and offshooting it to the people who know the user and who the number one customer is the user which is the wallet. They know the balances. They know the portfolio. They know exactly what that person wants. And app developers shouldn't have to be focused on that.

They should be spending more time on their other acquisition strategies instead of having continual thirdparty libraries falling over or having res reliance issues because they're trying to extract the exact same preferences and desires for a given user. Um, and so that's that. I want to make apps simpler. I want to get back to an IPFS deployed world where we can have very simple apps deployed. Um, and yeah, let's let's make apps simpler. can follow me, Greg the Greek, or Sprinter UX, uh, and learn more about, you know, our hot takes on UX.