Relationships in App Building: Who Needs to Know What?

Hello everybody, my name is Greg and I'll be talking today about effectively data duplication and 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, I'm one of the co-founders at Sprinter, which is a solving team, and Chainsafe, a protocol development shop. The history for me is a little bit interesting. I started in protocol development, I started the Loadstar consensus client for Ethereum, and then eventually became one of the core developers and lead maintainers for Web2.js, and that eventually led me into the solving space.

And it's quite relevant because if you look at the course of where I focus on and things I do, from core development, that shouldn't have been there, well, the user group rather is a developer, and then I've sort of 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, simply put, users 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 lifecycle, 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 it's something through Ponder a little bit easier, or you're just doing it yourself, and you have, like, this connection where you know a lot about both the app you're building and the users coming to your website, right?

They connect to your, they connect via wallet, you know who they are, you might be fetching the balance to help progress the state of the actual app through, right, progressing them through the user journey. But in, can you see, okay, 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 indexing, and does, you know, therefore, also indexing via RPC. And so we kind of have this, like, duplicate of 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, and we solve 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. And what this has done to the data model when it comes to apps actually building their applications is 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.

And really the core reason for this, for those that have built an app, you typically need getBalance as, like, a primitive to understand, do they have, you know, USDC, or do they have ETH or DAI 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 getBalance is not sufficient enough in most of the cases because they probably don't have balance on the chain you're on. Might be a new L2 or your own custom L2 or whatever, but they just don't have the balance where you need it, when you need it.

And so, you know, the Intents 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 wasn't the right one. You know, like, you're collecting the exact same data here that you're collecting right here. There's, like, 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. And that's what, 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 trade-offs? Some have custom accounts you have to build 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 contracts. 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.

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 Cowswap or like Across and so on and so forth, where a lot of this abstraction is taking place. Vast majority of applications, I don't know, do we have app developers here? But like vast majority of applications do not need to do complex flows.

A complex flow might be, okay, 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 cross-chain queries. Nine times out of ten, 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 cross-chain 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 intensive specialty 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 which is like do you want to treat all your stablecoins as a single balance? Do you want to spend from 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, 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 DAI and in that balance it's a mixture of so you want to buy an NST for 5K and you have about 100 DAI, 100K in USDC or 10K in USDC and 100K in an Aave position of USDC. The best way to compose this shouldn't be up to the app to decide 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 Aave. It's just unknown to them and they can ask you and you can break 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 USDC. 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 Aave position or your Morpho position. And then it starts to get more complex, but 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 after 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 with 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 API level. I'll give you an example.

This is ETH get balance. And ETH get balance works for a single chain. You know, 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. You have address and block number. And that's just where you want to go.

There's a few competing proposals out there. 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 cross-chain natively without having to think about an SDK. It just comes directly from the wallet.

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, mainnet, 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 USDC address on base, or even native ether. This small change right here, ah, I had transitional slides.

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, 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 don't 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 it 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, you know, from the crypto ethos back in the day, it was like we should run this all on IPFS. You shouldn't need to have anything. You get a hash 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 steps. 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 balanced yourself. You offshoot it directly to the wallet. And the wallet returns you exactly what you know is available to spend. And what this, you know, the next step in this process is that when you go to submit call data, the really simple path is you've gotten 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 solver-based systems. They're leveraging third parties, whether they're market makers, solvers, solutions like we just saw previously 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 front ends 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. That is that. You know, if you believe in an intent and a solver-based 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 those people who know the user and who their 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 third-party libraries falling over or having reliance issues because they're trying to extract the exact same preferences and desires for a given user. 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. And yeah, let's make apps simpler. You can follow me, Greg the Greek, or SprinterUX and learn more about, you know, our hot takes on UX.