**A** (0:08):
Good morning, Byzantium. Your general is here. Thank you all for coming this early morning. Today, I am talking about something that we've been working on for some time at Osmosis, and I'm really excited to share it. So before diving into what our solutions are, let's talk about what the problem is. Right. So you know Osmosis, the interchain liquidity hub, what does that mean? We have a talk tomorrow. Saeed and Alpin are talking about this. What does that actually mean to be a liquidity hub? Thinks a very interesting framework of how to think about it. But for this perspective, you know, we're an exchange, right? That's a liquidity hub. Fancy way of saying the interchange exchange. And so the question, I was on the Rack FM Twitter Space last week and I was like, what? They asked me like, oh, who is our biggest competition? And you know, was it like Kojira? Was it Uniswap? Was it Thor Chain? It's like, no, our biggest competition is Coinbase and Binance. Right? Like, if we're being serious about building decentralized finance, we have to like, actually go after the centralized exchanges. And I think that today, like, very few Dexs are really taking this mission seriously. Right. Like you, you look at centralized exchanges, they have all the users because they actually capture the users and deal with user onboarding. Today, almost every Dex treats itself as a utility of the chain that it's built on. Uniswap expects that Arbitrum is going to go get users and then they're going to just come use Uniswap on that chain. Right. But, you know, Coinbase and Binance are the ones who are out there onboarding the next hundred million billion users onto crypto. And how are they doing this? Why are Dexes unable to capture these users early on? And I think a lot of the problems come from the onboarding workflow. So what I did was actually like last week I basically asked one of my friends, one of my close childhood friends. He is a software engineer, works at Fintech, but has never used crypto before. And I gave him a simple challenge. Buy $10 of Maker on Uniswap. It took him about an hour and a half to figure out how to do it, which is absurd for a pretty competent technical person. I took notes throughout the entire process watching it, and I realized there were basically three main challenges that we came into. You had Fiat on Ramp ux, which is a little bit out of scope for today's talk. I think the Cato team is doing some really cool stuff out Alpha leak. But, you know, the second one was they had. He had a huge problem understanding fees, right? You had this like, he couldn't grasp the concept that you needed ETH on Ethereum to buy eth on Ethereum. And it was this like, weird cyclical issue. And so, you know, nice thing is in Osmosis and Cosmos, we've actually kind of basically solved this using fee abstraction. So now on Osmosis and soon on more and more Cosmos change, you'll be able to pay your transaction fee in any token you want. But the third biggest issue that we ran into was the wallet ux. So I'll just like quickly have a couple clips from that. Oh, I guess there's no audio, so maybe that might be complicated page download.
**B** (3:21):
For Chrome if I do that.
**A** (3:24):
So he got very confused that you have to go install this separate thing just to use this application. He's like, oh, where do I put this thing? Oh, let me put it in a text document, right? Like, okay. Then he like minimizes it next.
**B** (3:37):
Oh, fuck. Where was it? Ah, there it is. Oh, no. Okay, better. Unable. Oh, no.
**A** (3:50):
And then like later on, he's trying to like, find the extension. It's like, you know, the UX of Chrome extensions is very hard. They get hidden away. And like, yeah, it was a mess, right? Like, this UX is not okay, right? And centralized exchanges today, they give users this, like, very familiar web2ux that they're familiar with with like a username and password and a login system. Meanwhile, in Defi, we have these like, wallets. So the question is, why do we need wallets at all? So today, how blockchains work is every account is equal to one key. And the problem here is if you lose that key, there's no recovery system, right? Like, you're fucked if you lose that key. I mean, I'm sure this has probably happened to most people here at some point that they've lost a crypto key. The other issue is this single key has infinite power over the account, right? So, you know, this key is like a nuclear bomb. It's a tesseract. It's like the ring of power. It can do anything on your account. And the thing is that the browser is a very scary place from a security perspective. And putting crypto keys into that, into the browser. Oh, sorry, I was looking at the wrong thing. I'm like one slide behind the whole time. This isn't working. Oh, okay, cool. Yeah, don't put keys into the browser. Right? So just like the ring of power taking through a dangerous place like Mordor, you need a fellowship to protect it. If you're holding keys in a dangerous place like the browser, you need something to protect it. And that's what the browser wallet, the Chrome extension security paradigm provides you. What about mobile, though, right? Like why the mobile security paradigm is actually far better than what we have on the browser, but at the same time, we still have all these wallets. You know, you still need the MetaMask wallet and the Kepler wallet. We actually have a slightly different issue happening on mobile. So many years ago, there's this ECDSA cryptographic key called the SEC P256R1 curve. Remember that R1 which was standardized by NIST as this standard ECDSA curve. But when Satoshi was building Bitcoin, he said no to this curve because he was paranoid that the NSA had maybe potentially backdoored this curve, which, fair enough, the NSA has historically backdoored cryptography before. But. And so what he did was he instead chose to use this K1 curve, which has become the standard throughout all of crypto today. But the problem is, in the many years that have, in the 10 years that have come about since then, this R1 curve has become the standard of this, like the security paradigms that we have in the mobile OS system. So Apple Secure Enclave does signing using the R1 curve. The Android key store uses the R1 curve. The, you know, your desktop OS uses the R1 curve. And there's this new standard now called passkeys, which you guys may have seen in the last couple months, they have been popping up on more and more Web2 apps, where it's basically this standard by the FIDO alliance, which includes basically every web 2 giant you can think of. Google, Apple, Facebook, Microsoft 1 password, they're all standardized on this passkey system of moving away from passwords and into cryptographic keys, which is really cool. That's kind of what we've wanted as the cryptocurrency industry. But they're all using the R1 curve, and we are, like locked out of that. And so that we can't actually use any of the secure enclaves and all this security stuff that's being built by this rest of the industry. And crypto is kind of sidelined here. So you have this issue. You must use the SEC B, the K1 curve. And then next you have the issue we have to copy private key material between devices. So let's say I have a wallet already, but I want to go download the 1 inch app. In order to start using the 1 inch app, I have to paste my private key into this. This is like kind of insane, right? Because that means I have to have my private key on hand at all times just because I want to be able to install and try out different applications. This is an absurd security paradigm. And finally there's no key rotation, right? Because you only have a single key. You put it on your phone or something and you lose that phone, your entire security system is done. You'd probably have to upgrade all your accounts. That would be the same as hey, you logged into Google on one phone and now you lose that phone. You have to cancel your Gmail, you have to upgrade everything. That would be insane. But that is how it is today in crypto. So to solve this we've had this concept of smart contract accounts where instead of using an externally owned account or like a traditional key based account, you can use a smart contract as your main account. And this allows you to write arbitrary verification logic as contract code. You can do things like have multiple keys, you can have multisig. So in fact multisigs on Ethereum were sort of the first smart accounts, right? Where you had the gnosis safe. Because Ethereum doesn't have a native multisig system. You had smart contract multisigs as the original ones. But you can also do other things like key rotation limits. We'll go into some of the other cool stuff you can do in a bit. But the evm, you know, counter traction has become a big buzzword in Ethereum world these days. But there's a lot of limitations with the way that the EVM has done it. So one is that smart contracts can't originate transactions. All transactions need to come from a legacy account, which means you need someone to pay that gas and pay the fees for you. And to solve this they've come up with this like very complicated thing called ERC 4337 where it requires this like off chain mempool based system with bundlers and paymasters and it can get very confusing and messy. It's also very difficult to add new cryptographic primitives. So you know There is a EIP up to add the R1 curve as a pre compiled to Ethereum. But historically, you know, adding new cryptography to Ethereum has been a slow process. You know, adding the Blake2 hashing function took like, like three years before it finally got added. The BLS12 curve which is used in Ethereum's consensus layer doesn't even have a pre Compile at the execution layer. So adding new cryptography to Ethereum is an extremely slow and tedious process. Next you get a lot of fragmentation. So you have projects in Ethereum world today trying to build smart contract wallet frameworks, but they all are building their own non composable frameworks. You have Amber, which is one that I really like. You have Avocado from the Instadap team, great frameworks, but these are not composable at all. And basically you're like getting a lot of vendor lock in. You make an account using Avocado, you can't use it with any other smart contract wallet framework or you can't go use it with one inch or anything like that. So lots of fragmentation and there's no way of upgrading the current eos to smart contract accounts. So you look at some of the L2s with, you know, tend to have more progressive users than mainnet Ethereum and you see that the number of EOAs are magnitudes bigger than the number of, you know, smart contract accounts. And most of those smart contract accounts are gnosis safes. So if you discount gnosis safes, the difference is even starker. And the reason here is most current crypto users they onboarded via EOAs and they're not, it's just they don't want to upgrade their account, right? Like I have been using the same EOA on Ethereum for five, six years now, right? And it's like it's not just my tokens and NFTs, I can transfer those, but my that, that that account is part of. I have DAO memberships as part of that account. I have future airdrop potential as part of the account. I don't want to switch accounts, I would want to upgrade my account, which is something you can't do in the Ethereum paradigm today. So you know, you have all these limitations of the Ethereum account abstraction system. You know, the can original transactions, the cryptographic primitives and the stack ends up looking something like this where you have all these different players at different levels of the stack. The mempool layer, you have a lot of these off chain MPC signers, you have these fragmented things and some people look at this and be like, oh yes, modularity. What I look at this and I see is massive points of centralization with these MPC signers. You have rent extraction and MEV capture happening by these paymasters and bundlers. You have security risks and privacy leakage happening from this. So many layers. And then you have all this UX Fragmentation happening, it's going to be a mess, right? It's going to get very confusing. And so with osmosis we want to solve it in the way that our thesis at osmosis has always been one around vertical integration. Taking the Apple model and building vertically integrated systems provides the best ux. So this is why we decided to build a smart account framework at that native at the core of the blockchain, similar to our takes on Token Factory, right? We were like, we heavily rejected CW20 tokens because we were like, no, no, no. Tokens are such a fundamental thing to what a blockchain is. It needs to be built in natively into the protocol. It shouldn't be relegated to the contract layer. In the same way, accounts are even more important to what a blockchain is. And it's important for this to be baked into the chain itself for, you know, UX reasons, security reasons, composability reasons that we'll get into in a bit with our native smart accounts. Smart contract smart accounts can originate transactions directly. So you don't need any of this complex mempool middleware stuff. You can plug in third party account abstraction frameworks. So you know, there are people already building account abstraction frameworks. You have OB and Vectis and stuff, right? And you can take all of these frameworks and plug them into this, you know, more native account abstraction framework. And we allow upgrading from legacy accounts. So let's dive in. Oh, so let's dive into what actually is a smart account in osmosis. So what is a legacy account? A legacy account is basically you start with a private key, you know, use a sec B256K1 key and you derive an address from it. And that account, that address on chain is, is forever statically linked to that private key. You can never change it. But now let's make the upgrade button. You want to upgrade to a smart account, what happens? It basically nothing changes. It remains the same. But now you have the ability to do a new transaction type where you add what we call authenticators. And the classical key that you already had is, is your first authenticator. But you can say, hey, I want to add a new authenticator. Now I have two keys attached to my account. Or you can say, and what you can do is now that you have two keys, you can delete your old key, basically giving you key rotation. You can also add new cryptography types, right? You can have two different keys. You can say, hey, I'm going to keep my K1 key in my Kepler wallet. I'm going to keep my R1 key on the secure enclave of my Apple device. So you can have these multiple keys for different use cases. You can even make it so it's an and system like a multi sig where you say, hey, I want to be able to use the touch ID of my laptop, but only if my Apple Watch is in vicinity of this thing. Right? So you can have this additional security paradigms. And so these types of keys, these K1R1 keys, these are written as like go based code, cryptography code in the Cosmos SDK. But we also built a system for people to write new authenticators from scratch. Not just as go code, but also as Cosmos code or in the future things like zero knowledge verifiers. So let's look into what kind of stuff you can do with CosmosM code. One of the nice things with Cosmos being this Rust based smart contracting language is we can leverage existing cryptography libraries and import them to, you know, write new cryptographic cryptographic verifiers, but as contracts. So you can say, hey, we're going to import, you know, some open source OAUTH code and say oauth, you know, just call that library to verify oauth. And now you know, you can log in with Twitter and Google, not using these off chain MPC signers like you see everywhere else. But actually doing real OAuth OAuth is basically RSA and doing that real RSA verification on chain. And these things are composable, just like the keys are composable. You can say hey, I needed my phone and my Apple Watches key. You can say, I need this Cosmos authenticator and this classical authenticator to approve something. So what you could do with this is you can write cosmwasm authenticators as middleware. So you can say hey, I want to write this authenticator that all it does is restrict a certain message type. It says, hey, if the message type is an IBC send return an error. But now you can compose that with a classical key and you get this restricted key. You can say hey, on my phone I can do any message. This key can do any message except IBC sends off of osmosis, right? This is valuable for like providing these security limits. You can do things like trade limits. So authenticators can be stateful as contracts. They can have state and they don't have to be memoryless, right? So you can say, hey, this key is allowed to trade up to this much per day and so you can track that in the contract. And then if the Trade amount that you're trying to do is greater, hits the limit, it will just reject the transaction. Basically you can do things like balance change limit. So we added this thing called a post transaction hook where not only can you run your authenticator, run contract code at the beginning of the transaction, you can also run it at the end of the transaction. So you can say, hey, when the transaction starts, it'll note the balance of the account, it'll run the transaction and then at the end of the transaction it will say, hey, if the balance change is greater than some limit, it can throw an error and it will revert the entire transaction. So for example, you might want a key on your phone that you use for things like voting and stuff, but you want to make sure that it doesn't never has any side effects. Where it can spend money from your account, you can use one of these balance change limit authenticators. And what's really cool is because it's all Cosmos and base, you can plug into external protocols, right? You can say like, hey, we're going to just plug Pl build an integration into something like Daodao as a authenticator. And you know, this is going to get really fun once you start to do things with like, you know, Mars and Defi protocols adding authenticators. So let's go ahead and make an account today. So we'll walk through a little bit of the UI of how this is going to work. So you come in, you sign up, first thing you do, choose a username, right? That's like what you do in normal systems. Next you choose an authenticator. We're going to support things like passkeys, normal crypto wallets, hardware wallets like Ledger and Yubikey and OAuth systems. We'll go ahead and do the passkey one then we want people to still have a backup system. You can download it, but we'll also integrate with providers like 1Password and iCloud, where you can just easily securely back up your key. Next you can choose to add additional login methods, right? You're not restricted to only Year one, so say, hey, I want to be able to use my laptop, but I also want to use Google OAuth as a backup system as well. And we also have this feature called One Click Trading, where what it's doing basically is you're creating a hot key that's going to be stored in the browser. So basically what have we created here? We created this passkey based one. We created the OAuth based one, we had the backup key, but that one thing that I just told you at the beginning, never ever do hold a hotkey in the browser. Well, that's what we're actually doing here. But it's okay, it's safe because we're building all these restrictions. It'll be capped at how much of your accounts balance it can spend, how much it could trade. Can it actually move assets off of the chain? Maybe, you know, as long as it's only doing trading but not sending off. This is kind of what happens with like centralized exchanges today, right? When you want to do a trade, you don't have to like re log in every time you want to do a single trade. But when you're trying to withdraw off of binance, that's when they make you re verify to make sure that's really you doing it. So wait, great. With this system, Osmosis is going to have the most sophisticated smart account system. Obviously you're going to want to keep all your assets on the osmosis chain now, right? So to do this, we're going to make it very easy for you to take all the assets from throughout all your crypto wallets. You know, your Kepler, your metamask, your leap, your phantom. You can choose, hey, I don't want to import my EVM assets, I only want to import my Cosmos assets. And boom, boom, boom, you'll have all your assets swept into Osmosis and Osmosis will become your account, your asset hub, your wallet for the interchain. But great, now you have your assets on Osmosis, how do you actually still use all the other defi apps? This is where we get into interchange smart account. So today you have these legacy, you have the wallets that have a static key and you have these legacy accounts. You create an account on Osmosis, it's statically linked to that key. You create an account on stride, it's statically linked on that key and you have the same address on both and it provides actually this pretty nice seamless UX and composable between them. But once we start to get into smart accounts, things are going to get difficult because smart accounts are not this stateless thing. They are stateful, right? And so let's say on osmosis I added a new authenticator. I want to be able to use my touch ID on osmosis. I make the transaction on Osmosis to add that as a key on my Osmosis smart account. I have to remember to go add that to my stride smart account, right? Otherwise the system is going to get out of sync. If I delete a key, I have to remember because maybe I thought I lost. I think my Kepler key got compromised. I'm going to remove it from my osmosis account. I have to go remember to do that on my stride account. This is going to get complicated. And now you have this new awesome project that's coming. They want to airdrop to awesome holders and they're going to airdrop to your address. But your original address was based off of this original Kepler key that you don't actually have access to it anymore because you deleted it. This is going to get messy. How do we solve this? Well, chainopsis, one of the core contributors of Osmosis, many years ago they came up with this idea called interchain accounts, which is, you know, the idea that an account on one chain can make transactions on another chain. And so far this has mostly been used by protocols, right? You have stride using interchain accounts for the protocol to stake on other chains. Or you have quasar using interchain accounts for the protocol to do like actions on other chains. But now we're going to start to see this for normal accounts as well. So you'll have a smart account on osmosis. And like, you know, the analogy I like is like in Avatar you have like astral projection where like, you know, Korra's body stays in the physical world, but then you know, her astral projection goes and does stuff in the spirit world even though her physical body is still there. It's going to be a similar situation with interchange smart accounts where your core smart account is still going to be on the osmosis chain, but you'll be able to astrally project using interchain account and do actions on the stride chain. So as you add keys, you change your authenticator. You don't have to make any transaction on the stride chain because your account on the stride chain is just a projection of your smart account on the osmosis chain. How is this going to work UX wise? So there's two main ways we see this happening. One is this concept of osmosis mini apps. So today osmosis is for probably most people already the way they access their primary thing that they do in Cosmos. So let's make it easier for people to do anything they want. So we have this quick launcher system. You can go and do these quick actions right from the osmosis chain. You want to use Mars, you want to use stride, you can do that from here. And if you want to go to the full app you can and it will auto connect you to the interchain account for that app. We also have this option of sign in with osmosis. So you come just like using Cosmos kit, just so you can connect to a different wallet. If you want to connect to your Osmosis smart account, it will basically pop open similar to sign in with Google. It will open up the osmosis site, let you authenticate yourself, and then you'll be signed in to this other site. So basically this is how we solve this UX issue of how do you make smart accounts actually usable with an ecosystem of apps, not just special case for a single app. So, you know, our goal here is, you know, we want to build the best account abstraction framework, make it safer than anything that's come before. Better than anything that's on Ethereum, but also better than anything in like tradfi systems, right? Like you can't go tell your bank, hey, I want to put like, you know, rate limits on what my phone could do and all this stuff, right? Like you, you're kind of told what they tell you to do here. You have the power to do that. And using these smart accounts, you'll be able to make transactions on stride, on neutron, on the Cosmos hub, and hopefully one day Ethereum as well. So, and that is how Osmosis becomes not just the liquidity hub, but the account hub. Thank you, Sam.