deBridge 🛠 Build powerful cross-chain applications where value and messages flow seamlessly

[Applause] [Music] hello everyone my name is alex smirnoff and i am ceo and co-founder at deep bridge we provide a secure and decentralized interoperability infrastructure for web 3. and yeah i would just like to greet everyone who is participating in this hackathon and during this workshop i'll provide some insights on how cross-chain messaging is working and at the same time i will probably give some ideas of what can be built using the bridge infrastructure and at the end of this workshop my colleague our solidity team lead alexey will guide you through the process of the technical integration of like how the bridge infrastructure can be leveraged from your smart contract or from your applications so yeah let's get started and first of all i would like to highlight also that the bridge project itself has started as the hackathon project so last year back in april we won the global channeling hackathon and the hackathon itself helped us to bootstrap the protocol and kind of attract a lot of attention and interest from vc's partners and industry in general and today we are excited to partner up with uh youth online to help other fellow builders to build really cool d5 primitives and web 3 projects as well so let's get started um so yeah the bridge is a secure interoperability layer for web 3. the point is that we provide infrastructure that allows to interconnect any smart contract in any blockchain so dbridge protocol enables seamless question transfers of value and messages across different chains so in order to pass messages between different smart contracts you just need to interact with the deep breach protocol smart contract which is deployed in every blockchain supported by our infrastructure and what is needed for cross-chain interoperability because bridging of assets is not enough like many of the existing bridging protocols are purely focused on the cross-chain swaps or value transfers but in fact in order to build really capital efficient cross-chain solutions we need to be able to transfer value and messages simultaneously and we should be able to do that not only between users and smart contracts but also between smart contracts themselves so that smart contract in one blockchain let's say ethereum can open up positions or send a commands to smart contract in another chain and that's and that blockchain can be not even compatible it can be like non-event chain theoretically so in in addition to that we should be no like the receiver of the message should be able to know who are the sender because like when we are sending the message through some messenger like a telegram we can identify the sender using like the id same really cross-chain messages like receiving smart contract should be able to know the address and the chain id of the sender of the message itself and the last point here which is also important that like somebody needs to trigger the transaction the destination chain the transaction should be executed because any question interaction consists of two transactions the one that initiates the interaction and the one that finalizes or executes the message on the destination chain and yeah the bridge infrastructure provides all these features so you can know who the sender and you can also specify the small incentive which we also call execution fee to incentivize to incentivize bots or keepers to execute your transaction on the destination chain and uh yeah i will not go deep into the technical details here but the idea that in order to send a message your smart contract or externally owned account like regular users address just need to call the send method of debridge smart contract and as soon as transaction is finalized as soon as it became reversible the bridge infrastructure will validate your transaction and it will be claimed in the destination chain where the bridgegate smart contract is called like the claim method and the same transaction the bridge gate calls the bridge call proxy to execute the message that was passed and basically this external call will or like the message itself will be passed to the receiver that can be smart contract um or that can be the ua wallet as well in case there is like liquidity transfer and yeah so d bridge is a secure and composable and powerful infrastructure that allows you interconnecting any smart contract in any chain so basically in order to do some kind of cross-chain interaction you need to develop the sending sending smart contract in one chain and receiving smart contract that will receive the message and process the result of this cross chain interaction and one of the powerful concepts that we enable is the transaction bonding so basically debridge is an infrastructure that allow to perform any complex cross-chain interaction in a single transaction and that became possible due to our integration with the multisend library from gnosis c so basically the message which has been transferred across different chains can encode the arbitrary set of transaction calls and when the message is executed on the destination chain the call proxy uh we'll call the multisound library so together with the message you can actually find fine-tune the execution flow of the transaction and specify the special multi-send flag if there is a multi-sun flag the debridge call proxy will understand that this message encodes the trans the set of transaction calls and will execute them sequentially through multisend method where like first call can be executed to the first smart contract like another one will be will interact with the second smart contract etc until all the transaction calls are sequentially executed and the this kind of framework allows building very powerful cross-chain applications as well as cross-chain primitives you can actually have cross-chain swaps to perform like conversion from any liquid asset in one chain to any liquid in another and one of the solution that we already have is called dswap and we have an api that allows you to perform arbitrary cross chain swaps if the asset is liquid then it can be swapped through this one and you can use actually this swap in order to pass value and message simultaneously and you can do that to uh achieve various questions let's say you can build cross-chain lending protocol where you deposit liquidity in one blockchain let's say ethereum and in the same transaction your users can draw credit from smart contract in another blockchain for example polygon um other use cases can be crosston yield farming where your liquidity is automatically balanced and kind of managed across strategies deployed in different chains and the liquidity in each strategy can be automatically rebalanced based on the instant or like current apy of each strategy so yeah there are many interesting primitives that can be done another one is like multi-chain governance where the voting like governance voting can be conducted on chain simultaneously in different layer twos and then at some point the result of voting can be passed as a message to layer one let's say ethereum and can be settled so we can collect results of governance voting let's say from polygon avalanche arbitrome and some other chains and then at starting timestamp we can subtle this result in a theory and that's also interesting as well because that makes the governance voting to be very cheap and settles transaction in layer one which makes the overall process to be very efficient and yeah so in addition to that you can use cross-chain infrastructure to combine uh different protocols to create money legos because normally we sold these protocols to be combined within one blockchain let's say theory where other is integrated with maker or curve is integrated with convex but we have not seen many examples of cross-chain solutions or cross-chain protocols that combine different d5 primitives across different blockchains and let's say one of the ideas would be to create the stablecoin protocol like trucks which can open up delta neutral positions in perpetual markets in different chains simultaneously and the protocol where the position will be open is peaked based on the funding rate so the more [Music] the barrier is finally great the more positions are open right and that allows to have this stable coin protocol to be way more capital efficient since it's not tied or locked by one single perpetual protocol but it can diversify the positions that are open across different perpetual markets and uh yeah so the overall idea that with having decentralized cross-chain interpretability layer you can combine protocols and smart contracts deployed in different blockchains in order to enable more capital efficient solutions another direction that you can pursue here is the interoperability for nfts and for metaverses since we can pass arbitrary message we can also pass arbitrary acid right and in deep breach we have the uh bridge for energies which we call dnft and it's open source you can find it in our github wrapper and this bridge allows to breach any arbitrary nfts so you can leverage that in order to build interest in mechanics or like applications with nft nfcs or nft projects so let's say you can bridge nft from one chain to another and in the same transaction listed in some marketplace or you can buy or sell game assets directly from the game interfaces without being locked to one specific chain right and that also allows to make assets to be interoperable between meta versus let's say you may have nft from uni swap v3 which represents certain position or liquidity provided to the protocol and you can use that nft as a collateral in default protocol deployed in different blockchains so it's it's really up to your imagination to come up with the idea of like all these interesting cross-chain scenarios and if you have any questions about nfts or any ideas of the projects that can be built feel free to reach out to us on our discord and uh yeah the the last thing that i would like to mention the new question paradigm because like basically with so many projects that are that fork themselves and deploy in different blockchains simultaneously but with a decentralized interoperability layer you can make your protocol or application to be globally accessible you just need to pick one blockchain that suits your needs in the best way and then through interoperability layer you let users and protocols from other chains to interact with your project let's say users from polygon can interact with your protocol in arbitron without the need to switch wallets switch networks and you can leverage that in order to enable global accessibility for other protocols or like for existing uh smart contracts deployed in certain blockchains let's say you can also as a as a part of this hackathon you can also combine d bridge with protocols that are partnering up with is online to participate in a several sections simultaneously you can build question application application and at the same time you can like leverage the technology or protocol which is also part of the like of the list of partners or like part of the technological stack um yeah so let's move on the last thing that the that like through global interpretability layer you can uh kind of let users and protocols to interact with your protocol so you deploy your smart contract in one blockchain where you need to have like synchronous compatibility with other protocols but then you just let protocols and users from other chains to interact uh with your smart contracts and in debrief our goal is like to maximally facilitate this process that's why we also provide the whole side of development tool that you can find on our website that includes d swap api and d swap features so basically api allows users to construct cross-chain transactions to build cross-chain transactions to interact with your protocol so let's say if we have ave deployed in ethereum we can do a cross-chain swap from avalanche and provision of resulting liquidity into other and the same transaction and you can also have utilize dissolve widget that's the solution that allows you to build this question interactions in your ui very quickly so you just integrate the widget it takes like 30 minutes or so and then users can have can can leverage global accessibility of your protocol from any chain where user has this like any liquid asset um so yeah that's a bit of the overview of what can be built using dbridge infrastructure and again there are so many things that can be created and i encourage everyone to check out our documentation to see what upper changes the protocol enables and now i would like to pass the award to our solidity timli alexey who will guide you through more technical process of integrating with a de-bridge infrastructure and of course i wish you good luck with the hackathon and feel free to reach out to us whenever you have any questions thank you hello everyone my name is alexey and i'm the solidity lead at the bridge first off thank you all to come into my workshop in this video my plan is the following first i will give you a brief introduction to the dev bridge architecture which is really important to understand to start to build and to run your cross chain application successfully for instance i will let you know how our technical stack works i will show you how to construct a message to be broadcasted to another chain how to monitor such message and how to handle it second i will show you a set of smart contracts that communicate with each other liberation the debris particle in the wild this means that we will we together will make a call to one smart contract with intention to finish this call on another smart contract on another chain and finally i will introduce our new development toolkit which we developed to simplify the development of cross chain applications leveraging the debris product that's it let's go first uh what is that bridge from the technical point of view debris is a generic messaging and cross-chain interoperability protocol but simply speaking this means that your smart contract on one chain can craft a message containing instructions and assets with and send them to the dev bridge contract with intention to broadcast this message to another chain where the debris infrastructure will unpack this message and execute the instructions inside that such message along with the bridget asset so how is this possible the bridge consists of two layers the protocol layer and the user structure layer the plot the protocol layer is represented by a smart contract with the name debris gate which has been deployed to every supported blockchain currently there are ethereum bnb hakko arbitrom polygon avalanche and phantom the same smart contract is responsible for sending messages uh receiving messages verifying them and executing on the destination chain then the infrastructure layer comes into play when the message is being submitted so when you submit a message a special event is emitted by the smart contract each validator is responsible for monitoring and capturing such events from every support blockchain and each time the new event is captured the validator must again verify the message and if the message is correct it signs it with their own private key then when all the signatures are collected they with along with the message can be submitted to the debris gate contract on the destination chain where the contract verifies each signature against the public key which is known and trusted and if the signatures are correct and the message is consistent it unpacks the message and executes the mass the instructions inside this that's how it looks uh from the high level perspective and from our point of view this uh this architecture along with the delegated staking and slashing mechanism makes our protocol truly permissionless and transparent let's dig deeper so now let's dig deeper into the life cycle of a cross chain call so let's say there is a target contract which is being deployed on the destination chain it is and it exposes a target method which accepts the bunch of arguments and we want to make a call to this method from another from from another chain from the origin chain how shall we do this to construct a cross chain call we must call we must make a call to the debris gate contract which resides on the origin chain the debris gate contract exposes a method with the name send you can find the api of our contract either on our website or even at other scan because the source code of the contract has been verified you call this method either from externally owned account or from your smart contract providing the values for each argument specifying flags that affect the behavior of the message and last but not least you provide enough native blockchain currency to cover the protocol fee uh the debris gate contract accepts all these arguments and verifies them one by one checking if the values are correct and if they are the wga contract stores all all these arguments as a message in its own storage after in its own storage and if they are the contract emits the sent event which just replicates the contents of the submission shortly after the validators catch this event and the submission enters the confirmation phase so the validators need to wait a specific number a specific number of block confirmations uh for this particular transaction where the sent event has been emitted to ensure that the transaction got accepted by the blockchain though they need to avoid network diversions they wait at least 12 blocks for most blockchains but they weight 256 blocks for polygon blockchain so after the transaction where the submission has been submitted it got confirmed they start validating the message they additionally to what all the contracts already indeed so they again validate the state they validate the values and if the message is correct they sign them off by signing the message with their own private key the resulting signatures got pulled to the dab rich storage of signatures currently you can cure them using the debris api so it's a centralized solution but later we will introduce at that centralized solution like ipfs so that's it how the submission the cross chain message was submitted on the origin chain after the submission got verified it should be somehow related to the destination chain directly into the debris gate contract along with the signatures that verified this submission for this purpose the debris gate contact exposes another interesting method called claim this method accepts the message itself along with the signatures that verify uh this particular message so you see this you can see this uh dark blue balloon which consists of signatures which are coming from uh the signature storage which can be retrieved using the dev bridge api and the message itself which is the same message that was submitted on the origin chain so the contents of this dark blue balloon got submitted to the bridgegate contract by calling its claim method and the claim method so this process is called claiming when called the claim method again verifies the message and verifies is its consistency by using the provided signatures so the debris gate contract knows uh the public key of every trusted validator and it can verify if this if each signature is authentic if it comes from the known and trusted validator and if the contents of the message is has been changed during submission so if the signatures are correct if they are verifiable the message is marked as consistent and it got executed by the double gate how the execution is performed the bridgegate contract unpacks this message and takes all necessary arcs like receiver and call data and passes all them to the periphery contract called call proxy the call proxy executes the instructions that it finds in the call data field and in our case uh the call data field contains the call to the target method so the code proxy makes a call to the receiver contract it's a target contract in our case and it executes the call to the target method after the call has been executed uh the execution flow goes back to the leverage gate and the debris gate emits another event called claim claimed uh this event indicates that uh the cross chain message or submission in our case has been successfully finished that's how the life cycle for cross chain call occurs across that across our infrastructure i believe that the only way to learn new technologies is to practice them so now i propose to move to the real world example of actually a conceptual example imagine imagine that we want to build uh as a smart contract with the counter inside that can be incremented by a call from another blockchain so for this purpose we develop a counter smart contract here it is which holds the counter property and exposes the receive increment command which may be called by a trusted smart contract from a known blockchain uh and we also built an incremental smart contract uh which when called must craft a cross chain message which will be uh passed through the debris infrastructure with their segment to make a call to the counter contract for simplicity uh the incremental contract will expose a public method uh with the name increment which can be called by anyone so in other words there is an incremental contract which can be called by anyone uh and the incremental command uh creates a cross chain call to the counter contract which would be on which can be called only by the incremental contract on the specific chain so let's move to the code uh this conceptual example i will talk about is already have been built by our team and has been published in our github you can find it in our corporate github account i will show you yeah the reach cross chaindab example this example is developed as a complete uh production ready project so it contains uh uh and a lot of documentation uh a lot of helper scripts they discovered these tests extensively and of course it contains uh the contracts uh we are talking about right now so let's move to the source code of the uh of each of these contracts first of all let's move to the counter contract uh so the counter contract as we already decided is uh will will store the counter internally and we here it is it is defined as integer and the same contract exposes a function with the name receive increment command which is intended to increment the internal counter property so it accepts the amount we are willing to increment the counter by and the initiator to the the address of of the wallet who actually initiated this increment uh the contents of this method is very simple and straightforward we see that the internal property is just added by the amount that has been passed as an argument actually that's the whole code for this method but for simplicity and for more clarity uh i decided to add the additional event with the name counter incremented so we can always check the logs and see who incremented the counter and when [Music] what's more important here to mention is how the authentication is implemented of course we don't want anyone to call this method we don't want anyone to call this method either on the chain where this contract is being deployed and we don't want anyone to call this method from any other chain so we want some kind of authorization layer uh this can be implemented uh using the modifier so i uh the name i i give the name only cross chain incrementer let's go to the implementation of this modifier uh yep here it is the modifier only cross chain increment so we we created this modifier to prevent unauthorized calls to this particular method uh this modifier is expected to prevent from any unauthorized call and give the ability to call this message only from the chains that are supported by this contract and by a trusted contracts i mean the contracts that are allowed to call it the white lists are stored internally in the counter contract you can inspect the properties by yourself um so uh how the modifier is implemented so uh when the call to uh this method is uh is performed we need to read the data from the debris gate contract to understand the details of this cross chain call for the purpose of this you need to define the interfaces of the bridge gate contract you can take it either from our github account you can go to the debris finance account find the debris contracts version 1 repository and take the interfaces of our contracts here or you can use an npm package which contains those interfaces which which is very useful to plug in your these contracts to your uh to your project you can find it at npm gs i'll show you oh yeah here is the debris protocol evm interfaces uh you can just install it to your package.json file and import all available interfaces of the dubridge gate set of smart contracts you see the imports of these interfaces coming right straight from the package um so the contents of the modifier is quite complex not as easy as uh the receive increment command function itself so i will describe it live by line so first we need to obtain uh the address of the call proxy for this purpose we uh carry the debris gate contract obtaining uh the address of the call proxy here is and wrap it with the icon proxy interface that's how we obtained the uh call proxy instance the callpox instance is a periphery smart contract which contains uh the metadata of uh the question call during this call execution so when the device gate initiates uh the call on the destination chain it injects the metadata of the call rights into the call proxy so during this during the execution of the call you can get this information by curing the call proxy uh the first check that we must do here is to be sure that the contract has been called by the call proxy again we cure the call proxy contract by calling the submission cheney from gather and check if uh the id exists in uh our internal mapping called supported chains so and uh the second and the final check we must perform is to ensure that the call has been initiated by a trusted contract to contract on the origin chain for this reason we again call the call proxy contract calling the submission native sender getter in mind that the native sensor is represented in bytes but not the address this is because the bridgegate is going to support more chains not only evm chains and the addresses between incompatible chains are incomparable that's why for compatibility reasons every every cross chain address is represented in bytes however in uh evm we cannot compare bytes directly that's why we compare the hash of these bytes so we take uh the hash of the native sender that we obtained from the call proxy and we compare the resulting hash with the hash of the trusted contract that we already registered to this contract in case they are not equal we revert the transaction otherwise all checks have passed and the execution can enter the contents of the receive increment command function so sounds quite simple and really straightforward just one more thing to mention is it's up to you to decide how the country contracts should be configured in this particular example uh we've added uh some administer administrative methods like set the bridge gate which is important for counter t and q read and to make some checks and we also added at chain support which has the trusted chains and trusted uh contracts on these supported chains uh but you can move this configuration anyway i like to you can move it to constructor or it's up to you to decide how to design this so that's how the counter contract is implemented let's move on to the incremental contract uh so again the incremental contract uh is responsible for crafting the cross chain code uh so uh most of its code is related to crafting the uh a call to the average gate send method so for simplicity we implemented uh two methods the increment method which can be called by anyone so we don't uh design any restricting modifiers and there is also a pair method with the call with the name increment with included guest the included guest uh or the execution fee is a portion of the asset you're going to breach you're willing to pay to the executor on the destination chain so say you breach say one either to arbitrary and the cost of the execution uh of the transaction on arbeit's room will cost say uh is 0.1 error so you can specify uh the the included gas at as uh 0.

0 0.1 and the protocol it's the is the design of our the bridge protocol it will uh pay this amount this exclusive amount to the claiming service who will broadcast and execute the transaction treat it like a prepayment for gas for the destination chain so again what does this method do it accepts the amount you're willing to [Music] increment your counter by then it encodes the call to the counter by calling this internal method let's inspect it here it is in code or receive command the method is quite simple you see that it takes the interface of the counter and encodes the call to receive increment command by taking its selector and bypassing the amount that you specify when calling the increment method so in other words uh when you want to increment the counter you specify the amount in the origin chain at and this amount is being broadcasted along with the call to the destination chain where the call is performed so when you api encode the call you uh should wrap it with the message and pass to the leverage gate um so where is here is the call to this internal sent method is performed let's impact it as well the send method is more complex than there is method first we must check that this contract their incremental contract has received enough uh asset to cover the protocol fees so the pro the damage gate takes two kind of fees uh the fixed uh protocol fee uh it is measured in uh the native blockchain currency of the origin chain you can uh take it it costs typically about one uh usd one dollar but in the currency of native blockchain so for example for uh now for matic it's about uh 0.5 matrix and for ethereum by the way i don't know the exam the exact number but you can always obtain uh the exact numbers by curing the d bridge gates and global fixed native together so i suggest you to do this right now so let's go to elder scan let's find the debris a contract the source code of the debris gate contract is verified so we go to this tab uh we select the writer's proxy tab or read this proxy and here we find the getter with the name global fixed native theme global exit native here it is and we see that the fee to send the message from ethereum is this one um let's take it let's copy it and open the calculator yeah so that's the amount uh you out you need to supply to the bridge gate so that the bridge gate accepts your message so you need to supply 0.001 others mind that in other event chains the fees uh differ so you need to carry the the actual fixed native fee amount on every supported chain explicitly please don't recall these values so let's go back to the incremental command so here we ensure that uh during the call to increment or increment with included guys enough uh value has been provided to cover the particle fee and the optional execution fee that you are willing to pro pay for the executor on the destination chain after that uh we need to uh calculate the exact execution fee amount so again the execution fee is the optional fee you are willing to pay to the executor of the transaction on the destination chain and the execution fee is a portion of the asset you are going to breach so in in our example we are bridging the native blockchain currency of the uh origin chain so say if we breach from if we make a bridget uh call from ethereum we breach ethereum and uh we must supply at least the protocol fee and the optional execution fee but uh for the uh but the bridge gate takes additional cuts off the additional fee of the bridget asset it's around 10 dps again don't hardcode these values but rather curate from the damage gate so here here we carry the percentage the bridge gate will cut off the bridged asset so we expect to see 10 dps here so uh and we see that we breach amount to reach will be equal to the execution fee and the amount that we are we will receive after the beach on the destination chain is the amount to breach uh reduce it by the 10 dps that's all about the preparations and then we are going to construct the question call first we need to construct the submission out of arms structure which contains a lot of flags and operational fields [Music] at least the submission of the parents contains the execution fee so we set it to the amount that we are going to receive after the breach we also set flags there are a lot of flags that you can look up in our source code but in this particular example we need to set two flags the first platform is the proxy with sender which may which tells that the bridge gate to expose the address of the caller in the original chain uh if in case you don't set this flag uh the check on the counter contract won't succeed because the call proxy won't expose the address of the incremental contract [Music] and the reward is external fail is the behavioral flag that tells the debris gate to reveal the whole revert the whole transaction in case the call to the counter fails so there are two ways we can handle it say the call proxy makes a call to the counter and the counter uh fails for some reason it may uh if if you set this flag then the call proxy will fail too but if you don't sell this flag then the call proxy will gracefully handle the failure of the counter and uh shut uh and mark the submission as successful so it might so you can operate how to the submission should be finished either gracefully or with failure then we set then the submission of the forms uh contains the data filled that's the call data that we are containing the instructions that need to be executed on the destination chain we already prepared them by calling the abi encode and the very important flag is the fallback field is the fallback address here you must provide the address on the destination chain where the bridged money bridget asset will be transferred to in case of the failure the rich gate uh requires you to specify this address even if you are not going to breach any assets and lastly the call to the deep bridge gates and method is reformed you see that we provide the value with the amount that we provided during the call to the incremented incremental method again just reminder that the value must contain it must cover at least the protocol fee which is equal to the to the global fixed negative p on the origin chain uh and here are the arguments for this uh for this method uh in in the first argument the token address you specify the address of the talking on the origin chain you're going to bridge to uh the destination chain uh it can be either a zero address and this means that you are bridging the uh your region the native blockchain currency of the origin chain or it can be the address of erc20 token on the origin chain next you should specify the amount you are going to bridge the the amount of the token specified in the first argument uh it can be zero so don't include the prodigal fee to this amount just include uh the execution fee and any asset your and the any amount you are willing to receive on the destination chain uh the third import argument is the id of the chain you are willing to bridge this message to the list of supported chains can be found at the chain list.org or anywhere in the internet then you need to specify the receiver uh [Music] this is the packet address that mine the asset should be sent to and the instructions the call data should be instituted against so we specify the address of the counter here the other arguments like permeate user set fee and referral code right now are not important you can find the what what they mean in the documentation and lastly you need to include uh the structure that you we've prepared right right there so uh in case you uh made this call the debris gate will validate all these arguments and in case they are valid in case the value contains uh enough either to cover the protocol the fixative radical fee and in case the amount you're going to breach is more than the value you have provided then the message will be submitted and the sent event will be will be emitted so right now i would like to show you how these two contracts are operating in the wild in the main net chains so for the purpose of this i already deployed both of these contracts to the chains and configured them i mean i deployed the incrementer uh i called set davidgate and add counter so that these contracts are already know about each other and the same i did for the counter contract i deployed this contract and called that set the bridge gate and add chat support so they can operate with each other all right now i will show you uh how these can be performed uh let's go to other scan uh i i deployed and verified the source code of this contract so i deployed incremental contracts to the bnb chain you can see the verified source card here and i deployed the counter contract to the avalanche let's try to perform the call so i go to go to the income matter contract uh and i am but before we start i will show you the current state of the counter contract for the purpose of these let's go to the read contract section uh yeah and you can see that the counter the state variable of the counter contract and already has the value five this means that i already performed uh several cross chain calls to this contract to test if everything works correctly um yeah let's go so just remember that the current value is five so let's go to the incrementer let's go to the right contract subsection and find the increment method uh here it is [Music] if i will check if the metamask is connected now it's not connected i will connect it right now i just used an actual network uh yeah right now my wallet is being connected to other scan at the bnb gym right now we are going to call the increment method of the incrementer command uh for those of you who didn't do this before on other scan interface uh the first field is not the argument of the increment method it's the amount of native currency you are providing to this method this is because the increment method is marked as i will show you so here is the incremental contract source code and you see that the increment method and the increment with included gas method our market is payable that's why they are ready to receive value that's why the interface of elder scan shows these field so i don't remember the protocol fee on dnb so let's cure it first for this purpose i will go to the discount find the double gate again go to the contract tab or our radius proxy the global fixed native fee is that has this value it means that it is yeah so uh 0.

005 bmb should be supplied to the debris gate contract when calling the send method so i copy this value and put it uh put it to this field so that's the amount of bnb i need to supply to increment so that increment will pass this value to the average gate contract to cover the protocol fee okay and the first and the only argument of the increment method is the amount so that's the amount i'm willing to increment the counter property by let's say i want to increment by 10 so the current value is 5 i will increment it by 10 and the resulting value i expect to receive is 50. so let's call the increment method i see the meta mask pop-up i confirm the transaction yeah let's do it let's wait a few seconds until it get caught it's currently independent state yeah the transaction has succeeded this means that the submission has been accepted on the origin chain uh by the dev bridge gate contact but that's not enough let's take the transaction hash and and go to the leverage gate x to the debris explorer where we can view the status of submissions so we go to the debris dot finance open the explorer and enter our transaction hash uh inside this transaction there was only one submission now here we can see it it's uh this submission that was made during the call to the increment method let's open it uh yeah we see that uh while i was talking uh uh 12 blocks have passed and the the bridge validators started confirming this you can see in the bottom of the page the list of the validators that have already confirmed and signed this submission so we see that 12 [Music] 12 signatures have been pushed have been published to the dev bridge server and so yeah it's time for the submission to be broadcasted to the to the destination chain uh as you remember we didn't cover the execution fee and the payment for execution on the destination chain so we need to execute this transaction manually uh for the purpose of this uh the explorer provides an easy interface for making such transactions so i just so you see the button not the claim button i click on it um something happens i need to change the network yeah i change the network to avalanche the target chain and i will relay the transaction yeah so uh the the explorers uh construct the transaction uh where the call to the double gate on the avalanche will do to the claim method so i can firm uh let's check the status of this transaction yeah uh the transaction has been accepted by the avalanche chain and i suppose that uh the status of the the state of the counter has been changed so let's go to check it uh by the way you see that the transaction uh initiates a call to the debris gate contract not to the counter contract but to the debris gate contract which should verify the message check the signatures and only if operation is valid it will unpack the message and execute the call to uh to our counter contract so let's go to the counter contract and let's uh read it i will reload the page yeah yeah you see that the counter uh variable has been incremented up to the expected uh value 50. uh worth mentioning uh the events let's take the events of this counter contract [Music] we can see that one minute ago that was the event with the encounter incremented has been emitted uh which means that the counter has been successfully incremented uh let's let's check these values so the new counter value is 15 that's correct uh the amount the value has been incremented by istan that's the same correct uh the chain id from so the che the call has been originating from bnb its id is 56 that's also correct and the initiator it's the address who actually performed the call to the leverage gate is my wallet you see uh 0x4401 i will confirm it using metamask yeah that's my address uh zero is four row one yeah so uh that's how the cross chain call is handed by that breach in manual mode but in most cases we want uh these transactions to be executed automatically so we want to create a cross chain call on one chain i can expect it to be executed automatically on the destination chain so we don't need to go to the explorer and construct this transaction for the destination chain uh for the purpose of this we need to supply some money that the protocol will pay to the executor on the destination chain to show you how it may work [Music] there is an increment with included gas method which accepts the second argument the execution fee so the execution fee is a technical definition of the amount that the protocol will pay so again let's try to call it um now before we call uh let me tell you how to calculate the execution fee so again the execution fee is the part of the bridged asset and if you breach uh the native currency of the origin chain uh then uh you will receive the rapid version of asset on the destination chain but the currency on the origin chain and the currency on destination chain are incomparable and also it's important to understand that the gas price which is the mixture of execution of the transaction uh the gas prices are different across chains so we can't take the gas price of the origin chain and estimate the cost of the transaction on the destination chain and what is more important we need to uh understand the amount of gas we need to execute the transaction on the as of the destination chain so it's a quite complex topic but for simplicity uh let's take the transaction that we already submitted manually that's it so i go to the claim transaction on the avalanche uh open the details and i see that it consumed uh almost 340 uh oh sorry um almost half a million of gas here and the gas price was uh 26 so we need to multiply uh the gas for this transaction to the current uh gas price which we currently see and convert it to the dollar equivalent uh according to the current price of the avalanche and then we must convert the amount uh back to the bnb uh native currency so we can understand how much bnb should be provided to cover the cost costs on avalanche uh for that purpose let's go to our calculator so uh the gas price is 26 now let's take 30. then we multiply it by half a million of gas i take an extra amount of gas to avoid accidental spikes and then uh the so that's the amount of of a wax that you need to have to pay for gas but we need to convert it to bnb so we use the dollar equivalent it's around 20 dollars so we subtract it yeah that's the amount of dollars we need to have and then we multiply it by the price of the b yeah uh that's the amount of uh bnb that you need to supply as an execution fee that will be passed to the bridge gate and then to the executor so right now we can uh after we know the amount of execution fee we can craft another transaction so again uh how much uh bnb should be provided uh previously we provided only the amount of the protocol theme which is 0.005 but right now we want to uh but right now we want to add uh the execution view so we probably specify more which at 0.

005 plus let's take 0 3. and this amount will be provided to the average game the amount we are willing to increment by is 10 and the execution fee we are willing to pay is uh 0.3 that's it let's send the transaction ah yeah the execution fee uh should contain that small so we um multiplied as uh the execution fee by the debts and notes that's the amount uh that's the inconsistency of the interface of erdogan's cup in this field we can uh specify uh the human readable amount and in this field we must specify the amount with decimals included let's go let's write oh yeah i need to switch back to bnb that's it and right now i will write the transaction finally yeah that works confirm uh view my transaction wait until it until it included in the blockchain yeah it was included let's take the transaction hash and go to the explorer again yeah here is the submission um yeah already enough blocks uh enough block confirmations have been passed and we are now waiting for signatures from uh the debris validator services so it's you see that it's pretty fast enough signatures had been already published so 10 is more than enough to relate the transaction but you see that i'm not going to send the transaction to avalanche i'm waiting for the automatic execution server to relay this transaction to the avalanche so i see you see that we are waiting for it may take some time [Music] because the claiming service must be ensured that transaction has been included to the blockchain but it usually takes a couple of minutes yeah you see that i didn't sign the transaction on the avalanche it has been signed automatically let's check it so i go to the claim transaction i click on it yeah you see that uh the transaction has been submitted from another address not from mine mine is uh mine is uh 0x41 and this one is the address of the smart contract which is related to the transaction claimer and the claimer with this address has been paid for the bridge for the amount we have bridget to pay to eat and now let's go to the to the counter contract again here it is and check the current state so i reload the page read the contract yeah we see that the counter again has been incremented by 20 by 10 and the current value is 25. let's check the events uh yeah we see yet another event has been emitted a minute ago and uh the new counter values 25 is correct the amount it was recently incremented by is 10 and the originating chain id is 56 and the origin the initiator is again my address 0x4401 so two uh two events that we uh that that were omitted during this demo we show how the calls can be crafted and broadcasted across different chains either manually or automatically so so that that's probably all for today that i wanted to show you during the demo uh but i would also uh welcome you to our uh website the bridge.finance where you can find a lot of useful information and tools for developers so go straight to the developer section where you can find links to the documentation to the api of our solutions that are built on top of the bridge infrastructure for example ps4 the cross chain swapping solution uses the bridge contracts but it implements it is implemented as a server a separate product you also find that this will fidget uh which is useful for webmasters uh to integrate uh the crosschain swaps right into websites and uh for developers uh there are two important uh tools that we open sourced uh the first tool is hard hard developed hard hard damage is a plugin for hard hat framework to simplify testing and validating your cross chain messages so you saw that the debris infrastructure is quite a complex stack and it's almost impossible to replicate it locally but uh this plugin simplifies it by providing an emulated environment which replicates uh the debris infrastructure on your local machine so just install this other package to your product uh where you use uh the hard hard framework and then you will be able to run the the bridge emulator locally which deploys the vanilla uh the source code of this of the dev bridge gate smart contract so you can test the calls to it using your local blockchain and it also provides uh some extension to the uh test framework of hardhat so you can write tests again uh the contracts you are developing uh that should be should communicate with the average gift contract by the way uh the cross chain uh dab that i was talking about is built solely on uh heart heart so if you go to the bridge cross chain depth example you will find that uh tests uh uh using uh the heart had the bridge plugin to test uh the integra the communication between these uh between each other uh also we uh developed a software development kit d is the game which is also open source it's a production ready product for complex installations of complex products complex protocols who need a graceful way to main uh to manage and handle cross chain submissions so simply speaking i show you how i submitted a message on one chain user using other scan and check the status of this message using uh the dexplorer but probably you want to do this programmatically without going to our interface without relying on our infrastructure and here's where dsdk will help you it provides a lot of handy methods that are useful for creating submissions programmatically checking the stages of submissions again programmatically and if you don't want to pay the claimer and you would like to for example create gas less submissions or submit them on behalf of users claim and relay submissions on behalf of users uh you can use uh again these decay to programmatically uh make this happen on your product so dsdk again a production ready product for complex protocols so feel free but it's quite easy to use so you can use it in your pet projects and i encourage you to use it in your protocols and products that you are going to build during this hackathon so that's all for today thank you for watching uh i hope to see you all in our discord channel in the discord channel uh of yeah online so feel free to ask me some questions uh and uh see you soon bye good luck