Connext 🛠 xApps with Connext

[Music] [Applause] so you have mostly talked to each and every person here in the room so mostly you guys are already worried about what is connects and simply explaining um there we have been here in this space for three years we have been focused on interoperabilities and we have built like multiple projects starting with expansion victor indra and we well the latest the before this the project we did was vector and we hit 500 million volume in it but we were using state channels so we hit a limitation of the scalability in it because we have to uh basically maintain a same db at all the all the nodes which we which are getting created so that means each and every user we realized this problem and we started doing interchange that is nxt v0 where we started and uh we realized that also that right now with the current stuff which is running which is supported for 15 chains and more the only problem which is coming in right now is the segmentation of the liquidity because the way it works is that when you put your funds on the sending charge chain people receive funds on the receiving side so assuming that there is a lot of users coming onto this specific sending chain then the liquidity gets collected over there so now what it is is that we have been working for like six months to produce this new solution which is called amarok you have seen our swags which have a wolf kind of figure and that is that animal is known as amaranth so we are calling this heart folk and amarok and uh we now we are collaborating with nomad which is a messaging layer uh cross chain which is a slow one um it is based and inspired from ruler so it takes an around a half to one hour to provide and prove that this message is which is coming from the sending chain instead uh would love to deep dive into how this works technically nomad itself and how uh connects is working but we'll start with the basics what is what has been with the connex uh what we have been building until now uh starting with my introduction i'm i'm a project manager and engineer at connex uh more or less like engineer which cuts a lot and uh we have been we have been a transitor we have been uh a thought leader into this ecosystem so we're gonna make sure that everything is crystal clear to the people who are coming to this ecosystem and uh naming it because there are multiple chains which have maybe strain id or not or which have their own ecosystem which have their own vms or maybe not no vms like mina so we want to make sure that we can be interrupted we can be with any any chains which are coming in uh live and that's why we are uh we are naming any sort of domain from which one chain to another or a domain to domain you can connect and it could be l1 l2 side chain or non-evm so it could be near optimism polygon ethereum itself so we are calling these domain these are the execution environment where you can run your uh your uh across chain application and connect it with the other one on the side uh on on the other chain that is going to be our domain and we are calling these applications not app not tap we are calling it them zap because they are cross domain communication so we can do a native application uh integration with cross cross domain so any any change we are calling cross domain we are calling is cross domain native dap so that is zap uh not going to take much time off now but uh going to quickly skim through all that all the slides uh why zaps because we have seen interoperability problems coming in um in last five years we have seen why we needed e2 and then there are multiple chain came in but now how the liquidations and liquidity segmentation bridge hacking and all these things are coming in so we want to make sure that when you are using or building a domain zap that time you make sure that there is a significant security available onto your bridge you are not making a trust assumption and you are making a winning l1 l2 tap which can be used by user so user want to use any any app any chains right now so you want to make sure that your application is available with them and there are maxis but which maybe are more favorable to it or polygon near uh add a scalar mina and there are many apps but we want to make sure that you are with the user so you want to build an app which is available to all the users all the chains so you can be a you can have more users into your ecosystem onboarding user is very easy if you are an ad it's going to be very hard because it's very very you have to pay a height they have to be a high fee so it's better to avail it on multiple chain so they can come from anywhere again security is very important we have seen a lot of bridge hacking in last year and why it is important everyone knows now and that is what connects validates now that security is very important you want to make sure that whatever you are building is very secure so uh we don't do any trust assumption it's a trust minimization solution but you want to make sure that on whichever dap about whichever chain you are deploying it is secure so the only trust only thing which is available to your uh which is threatening your uh app with the security is the thing itself which is on deploy on uh here it is going to be a domain uh cross chain chain deployments is already here there are multiple apps which are which are live with ours leafy the layer two sorry layer swap so there are multiple dap applications which are already building in rv is doing the v3 version which is going to be using natively and xcp so it is going to be amazing uh how you can improve the zaps so you want to make sure that the interface interface which you are using is same to all so it is easy to actually scale and build and make sure that it is easy to for the user to actually start with something so you don't want to want to change things for the user when you are switching with the applications or with the chains or the domains so you want to make sure that the interface stays the same the the bridge is abstract it doesn't have many uh many layer of securities involved so that is why clinics is ideal for you guys and you can pass call data so you can um you can call uh contracts from the receiving side you can perform multiple things like downtown interaction metabolism whatever's you can build walls apps you can um you can have so many possibilities and so many use cases i don't i don't really imagine right now we are waiting for the developers to come in and actually build some cool on us thank you very much sir and uh we we are trying to we are trying to support as many as developer as possible there were couple of right directions which were taken and controlling the protocol bridge which were availing a user single user who comes in he doesn't have to know that which chain he is on he wants whatever the application is built for they should actually perform that so if you are talking about zaps they want to get most apy they don't really have to know which in they are on they simply want to get a benefit out of it so you this is the ideal world where the protocol bridging is coming in it is more or less they don't really get right now also in web 2 they don't really care where the data is saved it should be same but now they should realize slowly they are realizing there's a security aspect of it but they don't want to move it move ahead with that but now if you can have some sort of interface which can allow them in to move in uh in a very secure or in a in a very ux friendly way that will allow the users to come into and pour for getting to the blockchain system and that is what we are looking for uh challenges so these were the challenges which we have seen throughout the time which we were facing for the last years that deploying the contracts gets very hard because there are multiple chains so you have to keep a track of it and managing these deployed address so when whenever you are sharing with the application it gets complicated with them because uh uh on some changes that address are different on submarine chain it's not and uh reading from the chains the data which is available from the chains when you are reading from the sub graph itself there are uh a lot of blocks think uh they they are not synced to the latest there could be a 200 blocks delay so you want to make sure that whenever you are reading the data you are on the latest so this is something which we have been solving a problem with the graph itself and many many many multiple companies we have been talking to we have beware we we where we deployed multiple graphs so we want to make sure that the data is available all the time so the a piece of infrastructure shouldn't be the failure of your application so we want to make sure that doesn't happen so we are we have like two to three backups when you are deploying you're using a rpc you don't use a single rpc you have multiple rpcs which are in there so these are the things these are the steps we have taken to make sure that the ux doesn't suffer for the user and your dab billing with connects so it is quite simple the one way is that you can do a simple transfer very simple you use a sdk you make a x call and that is all required and the user will receive their funds like in ten to two minutes depending on whatever the change they are interacting with so if you are in polygon we will so any chain we we simply waiting for the safe confirmation to be happening we want to make sure that no reorg happens the router won't lose the money otherwise a router can actually take the risk but more or less if it is polygon i would say 20 seconds is more than enough where we are making sure that 150 safe confirmation happens and then we that are receiving site transaction happens so in 2016 people are actually moving their money in the most cheapest way possible and the most secure way so this is the incredible uh solution we have we are offering for the app developers to actually scale the users uh other than this we have uh instant look at bridging now uh because uh the liquidity uh will be available uh if it is not then we have less a slow liquidity which will be done in like 30 minutes or so so there is if a user is creating a transaction you are sure that it will be done within a 1r and it could be done instantly it wouldn't if it doesn't happen then we will show you that that is the slow activity there are parameters which where you how that's how you can check it uh other than this uh there are so many possibilities using the call data itself you can call adex where you can make swap you can call a dao where you can vote uh in cross scene mechanism where you can move the liquidity from down to daw in the most restless manner so these these things are possible with amarok you when you build with the next uh anatomy of zab this is something we have been talking about uh when we are saying that uh how you can do a contract to contract interaction uh you can have your origin contract which can be built upon the connect connects where you will have a x call in into it so you do a contract to contract it doesn't have to be off chain you don't have really have to use a sdk even if you make a direct call to x call then also it it will be big so it it doesn't require any sort of off chain piece of infrastructure to be communicated from the user or are required at the part of the uh at the part where the dab is interacting so you can do a contract to contract interaction you can do a simple sdk call or you can simply call the contract itself so anything any any of these are possibilities which can happen so once when we are talking about uh how does this basically work we have a connext connex contract on both the chains on sending side you will call xcom which will provide you um you will provide the basic data where you are providing the amount or the piece of information you want to deliver and mention the call data if there is a receiving receiving site call you want to make in this is the only information which is required on the sending chain this happens there are routers one of the key infrastructure in connects which are the liquidity provider or the message layer i would say so once a router sees that there is a transaction happening on the sending side so what they do is that they basically compete with each other and one other router or couple of the router who can collectively provide the liquidity or the message they will send their request and the relayer will send their uh their transaction on the receiving side this happens user receives their information and proceeds said whatever they were doing in case of permission contract which will be a part of the starter kit we will tell you about it uh which is required in some cases where you want to make sure the origin sender uh this the sender on the sending side is this is the is the one you want to trust so in case a dow to down interaction you don't want to trust the user who is creating the x call you want to make sure the user who's calling the x call is your dow contract so you want to make sure that origin standard which is coming from the sending side on the receiving receiving chain that this is the person this is the contract which called it so you can have some modifier on the receiving side and have this permission way so this is this is all you can actually get at the zap starter link if you go there we have three three ways to actually start interacting and we didn't mention um uh if you go to docs.connects.network you can get start you will have a getting started very simple uh where you can do an instant transfer maybe start just you just have to download the sdk itself and then just get started with it i can show it to you guys right right now if you can start and do some coding that is cool with you guys any any question till then i will take it disgracer um so i'm gonna use the bridging you mentioned that um next is much more trustless yes right okay so that would require a couple of comparisons but uh i would simply say why we are trustless because we don't have we don't assume any uh any any any sort of uh validating validation or there is no set of validators who are actually you where you are depending uh your money onto them the router who are providing their their liquidity they are actually they are making sure that okay i'm fine with completing this transaction so they are not actually giving out the money to any any third party okay please validate for me that is not the case router is actually checking that there is a transaction happening on the sending side they make sure because they are reading their own data we are not the person who are who are providing them that okay this happened please make a transaction that's not the case router have their own key infrastructure where they're making sure that they are reading the correct data and then they are creating a transaction and we don't want to erase it so we create a competition and a way where they can actually send the transaction on the receiving side so using using this logic right so like right i'm not familiar with the technical aspects of how deeper bridge packs are the exploits actually function but like so these wouldn't be possible right uh so uh the only trust minimization so we were trustless until now we we didn't had any sort of trust assumptions now we are depending on trust nomad in this case where for the mess railing of message that's where we are where we are saying trust minimization but that is all the the risk which is will be taken by it will be route so how this is working with us right now with amarok upgrade is that once the user is creating their transaction router creates a transaction on the receiving side they complete their transaction that is going perfectly fine now how does the router actually receives their money so basically they wait for the nomad which is which takes around 30 to one hour to complete the message sending on the receiving side and receive their money on the on the through the slow liquidity path so we provide the fast interaction for the user and router will receive the slow one uh through nomad and for that they will charge 0.05 and if that is some something subject to change that will be present on the docs any other question i can entertain with okay awesome uh we can get started uh with couple of we i'll just go or do an overview how you can actually get started and build some cool so we have a zap starter we have kept it very uh very low level and we didn't provide any sort of uh starter like our ui which we are not very much interested in so even if you don't really have a ui even if you are doing a contract or contract inspection that is completely fine with this we want to see the use case that can be possibly happened with you guys and have the potential to build it so that is the only requirement we are not looking for any sort of ui so uh when we when i said that you can build some x domain uh when when i said that you can what what are the possibilities of the use case you can build with so uh the only the very simple one would be like a 10 minute integration of five minute integration would be simply download this uh sdk and then just create which will be an initiation and the sdk config consists of chains uh like chains where you are mentioning the provider as well as the addresses of the tokens which are there and that is all all the config which is there which will be which will be available we will update the docs better or uh we will you can search the dock to search the sdk requirement itself other than this we have x call which is the main function where you will provide whatever you want to transfer from one chain to another so we will mention the two address where you want to the target it is where you want to have the interaction to be happening or the receiver of the funds uh call data will be something it could be 0x if you are not interacting on any contract on the receiving side if you are then the call data will be uh a function encoded encoding function which is an interaction which is happening on the receiving side we can help you with that we have examples so nothing to worry about origin domain and this destination domain so instead of chain id again we are using domain to make sure that all the chains possibly can be supported all the chains uh l2s uh rollups and uh non-evm chains so you want to make sure that we don't stick to the chain id standard so we the domains documentation is available right now and if you have any questions we are happy to support with it you mentioned these couple of patterns and other than that you mentioned the what is that what is the transaction uh transacting asset id you will mention the asset id you are tran uh trav transferring from one chain to another so you will mention that and amount this is all required and this simply you call x that is the only thing you require and you will instantly receive the money on the other side right now the test net is available on rinkiba and go on so you can test so it's over there sorry other than this when you are trying to build some cool things uh you can do sorry could you repeat the test uh go on and drink thank you um when you when we are doing the interaction from contract so what what can you build you can actually hold a governance vote on one chain and have the interaction happening from multiple chains so you don't have to actually create the proposal on e on all the chains but and then you can't come you will be combining it but it's not traditionally decentralized so you want to make sure that it is decentralized so you can have uh have the voting done on a very cheap chain and if some person is there who is not actually working on with that specific chain he can call it from the under the chain so this can happen uh you can hold the proposal uh uh voting uh on one chain and have the votes coming from all the chains so and the address will stay same you can have the validation done and you will be creating some middleware contracts above the connects to make sure this happens um we can uh we can go through the details but it is going to be the permission one which is mentioned under the starter kit so you once you go through in the overview we have mentioned couple of things where we have permissions and permission here you can have the use cases as well as we have explained what is the requirement for those contract to be built uh coming back to all the all the possible uh fun use cases token bridges this is nft bridging which can be happening you can create two one contract on the sending side where the burn can happen or lock can happen and on other side you can you can mint so you can this is an ft bridge which can be done and build using connext and other than this i think we have a hacker who is building the nft bridge and it is going to be super cool if you can build uh during time we are very looking forward to it uh a swap and a transfer on the receiving chain so assuming that you want to do a swap on uniswap or one inch or any any sort of decks you can actually provide the call data uh when you are call calling during uh during the next call and then you can make a transaction on the receiving side other than this we have dex liquidity zaps critical protocol operation which can happen uh to make sure the global uh constants which are there will stay the same uh you can build uni v3 trap which is very exciting uh you can have chain agnostic v token occurrence which is done which will be soon done by ave but we'll we want would love to see one of you building that and metaverse to metaverse interoperability this is very strong so these can happen all uh if you go through uh we have put in some examples possibly in the starter kits where you can see that what are the requirements if you have to go through the permission layer or if you have to go to the permission list if you are going with permission glare then you will have to use the slot there is no possibility to use the first one because you want to make sure the origin sender which is coming from the sending side is the one which is which is your contract and fast security permission as the uh the fast fast interaction is possible so these are some of the examples uh which you can go through uh through the documents and if you have any question we will be here all day uh tomorrow too so yeah thank you i think i will conclude here [Applause] any question if you have good thank you very much [Music] [Applause]