The Next Advancement in Cross-Chain UX

Transcript

hello everyone hey guys uh thanks for thanks for making your way down i'm jazz i'm from ren labs and today i'll be talking to yes one fan a bit about our learnings over the years working at ren and our shift from the protocol side to the application side we'll be going through some user experience things that we've learned specifically with regards to cross chain yeah let's get started and before we start actually can we get a quick show of hands as to who has used a cross chain application before okay cool and

keep your hands raised if the experience you had while using that application is seamless um to the point where uh you know you'd recommend it to your retail friends to use and wouldn't have to yeah that's what i thought um yeah so let's get started i think these these points might be useful for some of you guys um hopefully um sorry i forgot i had to press a button so start with a brief history lesson on uh the internet very brief i'm sorry i'm sorry yes so in the early days back in the um around the 60s i think the internet was primarily used for

military purposes there were a bunch of fragmented networks all disconnected they did you know they were communicated from point a to point b but there wasn't much intercommunication between them this was before the internet was called the internet that changed when tcpip was introduced uh communications protocol about a decade or so later which all of these networks had to conform to in order to interoperate and this really opened the internet up to the all kinds of use cases that we see today and we're at a similar sort of place with blockchains up until recently you know you see um you know bitcoin ethereum avalanche all of these independent blockchains up until

recently had no real communication between them and over the last couple years we've started seeing some approaches that are trying to fix this so different kinds of solutions some are you know cross-chain messaging services others at ren we have kind of like a central hub which connects to all of these blockchains and brings them all together there are approaches like ibc which is like a protocol standard that all of these blockchains have to conform to they all have their trade-offs but they all they also all have pretty similar user experience when you interact with them so we'll just go over a simple example of trading two assets bitcoin and gmt so bitcoin obviously on

the bitcoin blockchain gmt is steppen so that's on solana so the current user experience step one you send bitcoin to an address step two receive gmt on solana i wish um there are a few steps missing here so let's um let's break that down a bit so first you need to traverse the internet to find a bridge that has this pair i think it'd be unlikely to even find a bridge that has this space we might need to split it up into multiple trades but for the purposes of this example let's assume such a pair exists next step you send the bitcoin to an address that's given by the cross chain protocol and then you have to wait for some amount of confirmations in the case

of bitcoin that's usually six confirmations which is like 10 minutes each so an hour or so twiddle your thumbs for a bit and then you make sure you have a solana wallet because some of these cross chain applications require you to submit a transaction on the receiving blockchain in order to receive your asset if you don't you install one and then you make sure you have enough salina for gas even though the trade you're doing doesn't involve solana you need to have soul in your wallet which is convenient if you don't you find your solana address from another account maybe you have to go to a centralized exchange to convert some fiat into solana most important step uh pray to the cross

chain gods that everything works as expected and that's about it then you receive your gmt on solana if you're lucky defy guards crosstalk is there a fair few guards in our space vitalik so some of the pain points in that process let's go through them you might have noticed a few as we're going through so the first one is the user needs multiple wallets generally when they're doing cross chain trading cross chain anything really um this is a screenshot of my browser don't ask why i have terror explorer still but yeah it's not great for new users when they have to you know you're showing them an application and they have to

first go to the google web store or use a different browser to install a new wallet um it's overall not great next pain point is gas this is kind of self-explanatory everyone has spoken about this already today uh i'm sure in the user experience talks um so the two problems with gas are well the main problem is that you have to interact with an asset that you might not even be wanting to deal with so it's lana in the example and that's even worse in the cross chain space when there are a bunch of different native chains you're dealing with this was some uh nft uh drop i think it cost more to receive yeah

questionable choice and then we have confirmations um as mentioned you usually have to wait for some amount of time before you receive your assets and there are some ways you can improve this which we'll get into a bit later then there's the onboarding process so how does a user get bitcoin or whatever asset they want to play with into their wallet so there's a fiat aspect of onboarding but then there's also the onboarding of new concepts so things like impermanent loss or liquidity pools or you know amms these kinds of concepts a user a user sorry generally has to get a a good idea of what they mean so they don't lose money and then lastly we have the concept of

fragmentation so this is also kind of kind of broken up into two different parts there's a liquidity aspect so liquidity can be fragmented across a bunch of different blockchains for example at ren we support bitcoin and with every new layer one that we support we need to deploy a wrapped representation of this bitcoin on that chain so that means you have a new pool suddenly for this chain that might be drawing liquidity away from the other pools you need to provide incentives for this pool to get people to use it so that there's sufficient liquidity and overall it's not really sustainable the more chains you support and then the second component of fragmentation is just generally fragmentation of action so you usually have to interact with a bunch of

different applications you have to jump through certain hoops in order to do what you're doing so it's not usually the case that you can do all uh all your tasks from one spot so how can we fix this so i'll give you a quick overview of how catalog works which is a dex we're working on which is built on top of the ren protocol so ren itself is a layer 1 blockchain and in in the coming months we'll be introducing support for evm so you can deploy your applications that are already on ethereum and other blockchains onto the rent protocol itself and then the nice thing about doing that is you immediately get access to all of

the assets that ren supports so inside your smart contracts you can imagine you can suddenly interact with bitcoin and these sorts of assets so catalog is the first application uh first example of an application being deployed on onto the ren layer one and it's a decentralized exchange with a few key features the first of which being it has a single wallet one of our one of our key key values i guess a catalog is to to have sorry wrong slide is to have to replicate sort of the centralized exchange experience um so the way the catalog wallet works is a

user deposits funds into their account and they can do their trading they can do lending whatever they want and then they can withdraw their funds once they're done so kind of dissimilar to uni swap and traditional dexa is more like a centralized exchange experience but the difference being being it's all trustless so with catalog you can deposit your bitcoin ethereum all sorts of assets and then have them all in the same place secondly we abstract all of the gas costs away for the user so this gets abstracted so the catalog wallet that i was just referring to the user interacts with it using their web3 signature so any wallet that they currently use whether it's metamask or trust or something else they can use that to control their catalog

account so they just have to sign messages in order to trade or to do any sort of actions using their funds inside catalog so what that means is they don't have to pay gas they don't have to deal with any sort of new assets um that are irrelevant they don't have to pay additional gas fees that just gets abstracted away either the protocol pays those fees and they get deferred to the protocol to get subsidised by the fees that the protocol is earning or it gets hidden away into the price of the assets you're receiving thirdly we have reduced confirmations so instead of having to wait six confirmations for a trade that might only be you know a 10 bitcoin trade you can just wait for one or two confirmations and be pretty confident that the user isn't

trying to do a double spend because if they were i think they'd be trying to go for a bit more than that and generally you can you can cap this amount that you're um that you're reducing confirmations for at the block reward for the blockchain so ethereum you might have a reward for mining a block and you can cap this amount at that amount you can cap the amount that they can trade with reduced confirmations at that block reward so it's actually you know if they're receiving more by mining a block then they'll just go to do that instead of double spending on your exchange and then fourth we have a fiat onramp which is a simple way for the user to onboard bitcoin and other sorts of

assets into their catalog account we use bankser for this service it's pretty nice the the user they have to kyc to use it but there's no reason not to let the user go through that process if they want to get some funds into their catalog account instead of having to leave the exchange to go to a different sort of service and then finally we extend liquidity from all of the different blockchains so one thing we do at catalog is we don't try and recreate any liquidity pools that already exist on other chains for example if there's an eth to a pool that exists on uniswap on ethereum um and that has all the liquidity we won't try and recreate a east to a pool on catalog it does it doesn't make sense to

try and pull liquidity away from other pools that are already doing their job instead what we do is we have a concept of cross chain liquidity pools inside catalog so these are pools like btc to eth or btc to avax btc to sol the kinds of pairs that you don't see on native dexes and we use them combined with dex pools that are on other exchanges to allow for some pretty cool trades so a user could go from btc to ape and all they have to do is send their bitcoin to catalog they have to deposit it submit a trade and catalog will break that up into two components into the catalog side so the side of the trade that's being executed on catalog and the portion of the trade being

executed on uniswap and this is made possible by catalog being deployed on rainvm because it allows catalog to have to guarantee that the trade either gets fully executed or not executed at all so catalog can execute the second side of the trade which is in this case die to ethereum on uniswap and wait for that to be confirmed before doing the btc to each side on catalog so you're not the user is not stuck with any kind of middle asset in between and then [Music] finally we have some an exclusive access form for you guys uh if you want to you can fill that out you may or may not get access to catalog we'll be launching in the next few

months so keep an eye on that um and then we'll have um hopefully we can get some feedback from you all and inspire some other projects to take some of these uh ux concerns and cross chain pretty seriously yeah that's about it thank you guys [Applause] okay maybe take a photo of that for now and we'll get my man in the corner to fix that up it's actually my fault but i'm gonna blame it on him any other yes

thank you how do you guarantee the security how do you guarantee the security with uh so little so you had this chart with two bars and five bars or six so yeah how do i guarantee the security this way yeah so maybe i didn't explain this too well so if a user is doing a trade that's you know 100 bitcoin um you know they want to convert that to eight or whatever then you will wait for the full confirmations if there's only one trade happening throughout the catalog network there's only a single trade and it's for a small amount then you can sort of reduce the amount of confirmations you wait for additionally that's one thing you could do you can also offload that risk to someone else who's willing to take on that risk and they can get a fee for the trade so if

they're happy to wait for four confirmations instead of six they can do that they can take on the last two confirmation risks themselves and then they can get paid for that do you issue your own synthetic assets or you use other synthetic assets we leverage the assets that are deployed on renviem so rand native assets um catalog doesn't have its own synthetic assets okay yeah yeah um i was going to ask um if i'm going between say optimism and arbitrary is that a potential use case

where i can use this then do i have to like what's the sort of the trust profile there do i have to trust something or is it a trustless solution or what does that look like you have to trust that renviem is trustless um there is a trust in a decentralized network that we've been running for the last five years it's a cross-chain network and that's about it you can have a look at the contracts on either chain that will be interacted with in the process but that's about the level of trust you need to have there's no single entity that you need to trust throughout so i haven't been following up with the run project that much but like maybe six or nine months ago when i checked uh your node was still not open source it was kind of gray sourced or portions

of it was open source are you guys going to open source the entire project before you release this yes we are um so we actually we have a roadmap that will be released as soon as we're back from this strip um including which will include timelines for things like open sourcing um the reason we haven't been completely open source so contracts and things are open source the node itself hasn't been that's for security reasons which i think in my opinion has paid dividends given we haven't been hacked probably the one a few one of you cross chain protocols that hasn't but you're right that that will be open source before the release yeah you guys were not 100 sure about it so

yeah so two two reasons one was just um you know closed closed source um um one one was because the mpc protocol that we had developed in-house was our own and we didn't want our projects to be you know just ripping that and claiming it as our own but i think we've sort of uh passed that now so we're happy to release that to the public um two quick two questions uh first is could you just go back to the slide where you listed all the steps again um of the current ux yeah this one am i missing something no no no uh that's it i just wanted to take a photo of this i didn't um and then second one was um uh how do you select the decks um in in

your routing like you you mentioned uni swap but like uh what if like um there's a cheaper dex or do you like operate similarly to matcha um yeah so it is it is aggregating through one inch to begin with will support other aggregators in the future so um hopefully one inch is picking the cheapest option but as the catalog relay is developed there'll be more aggregators that we support okay because like i've heard cow swap was the cheapest for example yeah we'll look into that okay all right thanks man is there any other question no okay thank you thank you very much [Applause]