Simplifying Smart Contract Integrations with Bonadocs

Transcript

GMGM. Welcome to what's going to be another fantastic episode of Devantel. So, if you didn't know, Devantel is a 30-minute podcast held every week allowing founders, hackers, and anyone in between the opportunity to come on the show and showcase their product. And today, I'm excited to welcome back on the show David Atand from Bonadox. So, if you didn't know, Bonadox allows web3 engineering teams to collaborate and build applications in a very intuitive way by simplifying the documentation, interaction, and integration of smart contracts. So, if you stick around for today's episode, you'll see David give us a overview of all the new things um they've developed on Ponox and show us how the Ponodox toolkit can help developers more easily build web 3 applications. All right, let's get into

it. [Music] GMGM, welcome back on the show, David. Ecstatic to have you back on, man. >> Yeah, definitely good to be back. Um, it's been a few a couple of months and a lot of progress within that period. >> Yeah. Yeah, I I imagine so. I was taking a look at the the website and and the docs and whatnot. It looks like you guys have uh built uh quite a bit more uh than the first time you were around. Um but just in case um folks didn't catch you the first time on Devontel, uh did you want to just give a brief introduction about yourself?

>> Yeah. Um I'm David usually like after David. It's on on Twitter. Um yeah, I used to do engineering at Consensus after which I decided to start reading Buna. So, Bunardoc is a tool set that allows um applications built on top of you existing like smart contract protocols um that are on chain. So it's basically like bridging bridging the gap between you know application um and smart contract integration very very similar to like you know what we have in Postman for regular like APIs but this time we're like building the same thing but like for smart contracts to ensure that um we improve developer experience of what currently exists today. Um I

think people have done a really good job even like before brand came on the scene like you know folks at EAS and like folks at DM they've done really good job building out the front end stack for application devs right ensuring that you know you're dealing with like you know onchain transactions directly from your react app or your you know nextjs or your view app you're able to do that um pretty seamlessly with this um tool set and like even like the past year we've seen a lot of good work like preview that's even got acquired by Stripe right it's basically the same thing we're being like you know a better like developer experience user experience um on the user side of things or like on the application side of things so it's

it's really a lot of progress on the application stack over the past since the last time we spoke >> excellent excellent yeah I'm I'm really excited uh for you to share um all those updates with the the folks watching here or listening here today. And uh just curious before we get into all that um you mentioned you were uh previously at Consensus uh just curious like how did you find yourself in in tech? Um like was web 3 the first kind of exposure that you had to um the tech world or or was there something that something else that kind of brought you in?

Um so pretty much like I started like with technical writing um and also like front end engineering so I've always been on the application you know side of things right I've always like written the regular you know front end frameworks react view as long as it's like JavaScript script I've always been good at at that um then I think in 2020 2020 2021 I think it was during the whole like bull market euphoria and all of that was really when I really got um into the web three space. um and post that we went to like the entire you know bit like beer market and the rest and then I started digging like the engineering side of thing built a few um tools which like from the angle of you

know sending the wrong wallet address like it just was really weird to me that if you send a wrong wallet address that's like a 42 character right it just like goes missing and so I was really like curious like what was that about so at that time we built like a tool that enabled able to like you know send links wallet addresses and the recipients can or the sender in this case gets the link and they also connect their wallet to the link and send to the person and basically we just like thinking around um that was the point where I basically got then I applied to content right after that then I got in um and after that period I joined like the fellowship like the content fellowship um with Bonadox and yeah from there it's just

been it just been That's awesome, man. And yeah, uh it's always interesting to hear um like how people got into tech and and how they u basically evolved themselves up up to this point and the Yeah, the that point around like making sure the wallet address is like correct and like one thing is off and it's like oh no, where did my money? Yeah, that's like Yeah, it that's >> and irreversible like that's the >> Yeah. Yeah. Exactly. Exactly. It's just like, oh, whoops, there goes my uh there goes my ETH, there goes my USDC or whatever.

>> No good. No good. >> That's a bad experience. >> Oh, yeah. 100% 100%. Um, and yeah, I guess um during during your time at at Consensus was and um your experience with the the web 3 ecosystem, was there a particular moment or something maybe it was just like the this bad user experience with wallets or whatnot? Um was there something that kind of led you to um working on Boner Ducks? Like uh what what was the inspiration behind you um getting involved there?

Yeah. So, um I'm a co-founder. We we're basically working with XL team on like a side project where we we wrote this smart contract. We needed these guys to integrate into their app. And there was just too much confusion because they basically has to like you know jump on calls say oh yeah this is the correct um contract method to call and this and in my head I like okay usually when we write APIs and we shared API with front end developers right we basically just use like a soal postman and you're able to like call everything directly in that sort of like playground environment then I just realiz in web 3 this didn't exist right we didn't have this sort of like

integration environment that just allows people to import contracts um and basically interact with it like they're on a front end app before they even like integrate it into their actual real life app cuz like once you're able to sort that like um middle ground that environment it basically ensures like there less confusion so I could basically write the JavaScript that does this let's say for instance I think we'll demo that after right um I need to resolve an ENS name so if I wasn't web three incline. Let's say I'm just a regular web 2 front end developer. Now I need to understand how do I actually like know resolve an astro eat into the actual address I'm trying to send um

whatever stable coin to right I I need an environment to probably like show me how to do it and I can run that code within the environment right so by the time I'm ready to integrate this into my app I just like take the code paste it into my application and it works right so that's that middle ground that bridge um that we're actually trying to ensure that we build out >> that's that yeah that and that's like a really really important point um and and an area a lot of people >> uh it maybe like the web 3 native devs kind of take for granted but like a lot of people that um aren't exposed to um blockchain development might be like oh

like why can't I do some of the same things I'm already well accustomed to right >> yeah exactly >> yeah Yeah, >> like developer expresses miles apart. >> Yeah, exactly. Exactly. And it's great to see that you guys are um trying to bridge this gap and and fix this like legitimate problem in this space. So, and I think this is a great segue to kind of get into um all like what Bonodox is. Um did you want me to pull up your screen or >> Yeah, I think you can we can do that right now.

>> Let's do it. >> Yes. like a short demo, not going to get into like too much um technicalities, but um here we're able to set up an environment right for ENS NS playground um just before the call like up. But usually um you have to like import the correct contracts, right? So here I imported um resolver. I added you know the project name description. Um I added like the public resolver that ENS uses.

Um added the contract the contract address and I have the AI right. So this contract is already um imported into this playground and just need to show that just for clarification. And under here we have something action. So under action what happens is you're able to write JavaScript code that interacts with the smart contract. Um so in this case I had imported VM. So you can like import Ether and VM. We're just like limiting it to these packages for now. Um so you can ether and VM which are like the two major JavaScript libraries that allow you to interact with um contracts on chain. So here we

imported like the mainet um object from VM also from VM and the normalized method from VM. So what's going on here is we are able to set up like a public client and we're able to get ENS address. So ENS get ENS address behind the scenes uses um resolver that is being used. Yeah, I think I lost second. But yeah, um so this is being used by by um VM like this method this gets ENS address

method. If you go into the documentation um let me open that up just for clarity. So here we have get ENS address. So this get ENS address right is the same thing we have here basically that we're trying to call within the docs within the playground rather. So this method itself is being used is being um abstract the universal resolver. So we go to universal resolver here.

So like do forward resolution. So um because in VM right you don't need to like call the resolve method on you know on this particular um contract cuz like here is already integrated into VM and ENSJS. So you don't use directly anymore. So that's why I'm actually not using directly. I just directly from VM in this case. So we pass in I have a sub name. Right. And I can console log the ENS address it returns. So if you click on this um we're basically querying the method to get back the address and here we have the address attached to that um name and

I believe if we use the actual base name a um we should get back my actual address which is this. So what this does for like let me put in the context of a front- end developer right I'm building an application and I require like you know ENS resolve resolving an ENS right and this in the user has imputed their I need the address if I have like no understanding how this the docs and start looking for like oh how do you do this or oh I'm confused how this would work. All I need to do is have this

environment and integrate and like maybe get on a call with the solidity dev and able to like have and out all of this action that need to be done on the app and we can call it directing this environment. So whatever works here would work when I'm actually building the actual app. Right? So, let me open up a second playground. Um here. So, I'm bringing up this playground that basically shows you how to perform a transfer. So, the user has like editing the address and they to send it to another um user, right? So, I will just create a new one here. Let's say

transfer and we call let's use actually it's tenderly term create action. So let's clear this out. I already have the code written out just so there is no need. Okay. U let me ensure we have VM here. So you can have like the VM package into your playground environment.

So what's happening here is um instead of using a test net, right? I'm using like a virtual test net. So a virtual test net is a service that tenderly offers. So what they do is instead of you going to like look for test net tokens, you know, looking for a foretite that works, they basically have this sandbox environment here that allows you to have like a like private explorer. They allow you to like, you know, have your contract. They allow they give you like a dedicated foret token you need. So I had already like set that up just before and all you need to do is basically use that the RPC URL for that particular chain because basically it's a network

it's just like a private sandbox of some sort instead of using like the test net right so I had it here um I also used to initialize the um public client like I did earlier with the VM VM method and here we also set up like a wallet the client and the latest nons just for the transaction. So here we have like the right contract. So we added like the USD address, the USDT ABI and the transfer method. So we are transferring like 10 USDT to this particular address and once it's sent we get like a USD transfer confirm. So what this does is that it

shows whoever wants to like build [Music] Oh, here is actually how to do it. Get like the lowle to do this particular transaction. So, it's not like you're just form like an environment where you can share with other people. So, if you share the playground with somebody else, they they understand exactly what a contract is trying to do for the user. All right? So a lot of time I think about things from the point of view of what does the user need to do on the application right and how do I use this smart contract to do it. So you have um a protocol like unis swap okay how do they actually perform a swap um on the actual app right so you need that logic

so so it's just similar to that right you have this environment we're able to write out JavaScript logic that interact with the contract to perform a user action so I said earlier you're able to see like has been transferred and you have been confirmed and if you go to your little virtual test net here you'll see that it has been um completed. So you can see here transfer. This is like our block explorer similar to like an ether scan but like because private um that's why it looks like this. So this just shows you like what the playground um can currently do. Like the first time that we spoke, we just had like the doc gen where you could

have like a widget that interacts with a particular you know contract method. But like now you have like a full-blown playground whereby you can actually check that oh um how do I perform this completed action because in order to perform an action many times you need more than one method you need like maybe perform like some JavaScript um logic can be a conditional or you know whatever logic you need to perform. So this presents you opportunities to like actually write out full-fledged actions for your users. >> Yeah, this this is amazing. Uh David, and um the the libraries um that you were showing that you can pull in, are those fixed or can people pull in other libraries um um as as they need them?

>> So for now, we just try like limited to VM and it has. So we just try to like limit to like just the onchain logic you're trying to write. So most of the other thing you probably need to you know add here are things that you can basically hard code like external libraries but I know you can also add load dash so there's that but um we're trying to limit just and VM so like even being functionalities on our end is much more direct. >> Gotcha. Gotcha. Gotcha. And um are you only limited to a single file that you can um uh play around with? Uh is it possible to create uh more than one file

that interacts with each other in in this playground? >> Yeah, for sure. You can add like new actions here. So we see actions too for instance. And so here you can choose like a simulation engine. So we chose like um tenderly virtual test net there also like build beer and there's mainet directly with no test net with no simulation and we have like an inbuilt um simulation engine. It's still experimental right. So but basically you can have like different um actions.

This is like a boiler plate um to start up. But yeah, you can have like different actions um that can you know dedicated files like show you how to do different things. >> That's that's awesome, man. And um I guess um these virtual environments um is there a way for them to kind of persist? You mentioned that you can share these um with other people to see for them to get an idea of of how they work. Um so is there kind of like an account system where people sign up and these um playground sessions are are are kept around or is it um like a oneshot kind of deal?

Um, so you have an account. I didn't show that earlier, but basically you have an account that's tied to your um, so let me just log in. So you can see here like login Google. Um, give me a second. Yeah, >> it's all right. Live off. >> Yeah. So like you logged into the account right and you can see like a list of so you create a team first of all. So I created a team called main protocols and I've been creating like these different um playgrounds within here but you can also invite team

members right you can also invite team members here you add a team member you add their name email and they also have access to and they can see all your playgrounds but besides this you can also create um a link probably need like a one off link to share somebody outside that you don't add to your team internally. So if you go to your playground like let's say I think this particular one uh okay I think this is it but basically if you need to like share it you can like

publish to server um and get this link. So with this link for instance if you open a new tab you can open it. So this saves to like um the server and you can share it to other people. But besides this if you need to like have a playground that is like immutable probably I don't know your documentation or for whatever reason you can also save to IPFS. So if you let's come back here uh let's close this. you can see publish to IPFS and also get like an IPFS link that pretty much does the same thing. So that way you can share either your internal team or you can share external

people or you can just share to the public right just to have to have an understanding of what your contracts actually do because you know like web three we are um open source we are open by default right so if you save something like this IPFS and share with somebody they they can be sure that it's exactly what you you did and you want them to see right it cannot be edited after right as long as that's in IPFS ash so that way they making sure that this is exactly your contract and this is what you want to do. So, um yeah. >> Awesome, man. Yeah, the you certainly weren't holding back when you said uh you guys made quite a bit of progress since the last time you came on the show and uh

>> Yeah. Yeah, that's amazing. Uh just curious um any plans to integrate u perhaps like um AI chat um uh feature in this? I I think it would be kind of neat to um have like a playground and have something kind of sitting in the wings to help you. Um uh maybe maybe you're copy and pasting some code you saw online and you're trying to make sense of it and see how it works. Um any plans to integrate uh AI uh into Bonoc?

>> Yeah, so I've been doing a lot of like autocompletes. So for instance you have like code and you're typing and you know if you use like cursor or like copilot you have like autocomplete feature. So I'm thinking about that and I think that would be a good ad and also like for documentation. So I'm thinking about whereby you can um open the envir the playground import your contract and the like generate documentation for it. So documentation per um contract and documentation per method. So we have like a place for it right now. So if you go on documentation you can see this um and if you click on here you can add

like you know documentation for each contract. So I've been thinking about way to like have detailed documentation generated by AI. So once you import the AI import your contract address. So yes, it's definitely something I'm thinking about and it's like part of you know um things I'm hoping to build in the coming months. So yeah, definitely definitely on the way. >> Awesome. Great to hear. And I guess on that, is there anything that you can share about the Bonavox road map um from here on out or um any anything you can tease as to what's coming?

I feel like what we're trying to tease right now is kind of outside the playground. Interestingly, it's like a So, we've seen like what stable coin can do um over the past, you know, three, four years. It has like gone mainstream fully. Um but I feel like the next thing I'm betting on right now is defy protocols. Um so, I'm I'm saying this from the point of view of yield. So how can we get this stable coin to generate yield for people like reliably? So the same way people will invest in like ETFs, same way they invest in stocks and they hope like you know at the end of the year they have like five yield on their investments. Um I'm

thinking about same thing for like a lot of people are holding stable coins now whether like cross transaction whether for payments and the rest. So like how can we get the stable coins to give them yield reliable yield at the end of the year. So we're thinking like being like an API. So because like bonox itself is like around integrations into application. So we are kind of like thinking of being an API right that enables um regular fintex provide this to their users. So a lot of regular fintex right now have integrated stable coins. So it's like how can we give them yield on that stable coin without while without while abstracting all of the complexities of like you know rebalancing portfolios and the rest. So just like a single API integration app

and the users automatically get a certain percentage of yield you know every year. So that's basically what we are we're working on like they were thinking about um right now. >> Interesting. Interesting. Yeah, certainly a hot field um particularly this year or this year, sorry. Um so yeah, uh that that would be uh very interesting to see how that plays out. Um but I guess for um the developer audience that's um watching today and wants to get started with Bonodox um like what's the best way for them to kind of do that? Um uh obviously they can sign up for the playground, but is there any particular um uh tutorials or

or starter repos they they should um be on the lookout for? >> Yeah, so there is the documentation, but there's also like a quick start um tutorial we have on YouTube. That should be a good place to start, I think. Uh remember our let me just see on YouTube YouTube. Oh, here it is. We need to go so far.

[Music] >> No, there's your first episode. Let me just get the link and paste that here in private. >> Yeah, it's right there. And uh we will share uh this link in the uh description below. So uh for those of you watching, don't worry. Or listening uh we'll have that for you. And um >> Yep. I think I think Go on. Oh, >> you go. Go.

Well, I was going to tutorial basically just shows how to set up like um the playground quickly. So, I don't know if you don't go through the docs. Um this is a quick start for for users. >> Awesome. Yeah. Uh we'll definitely share this with with folks and um in case people were also interested in contributing to Bonodox um is there opportunities for them to to help out or um how how can they get um involved if they um if they're curious to >> um so we only have um I think two reples that are currently like um open for the

public. like as we keep going, we're going to open up most of our ripples actually. Um, but right now it's just uh I think the widgets the widgets um rep is currently open source and the protocol registry. So we have a registry where you can basically add so if you have like a playground like built out and you want like anybody to just view it, right? You can add your your playground into the registry. So let me search for registry kind of slow right now.

Uh okay. So yeah, registry is right here. So you can add your playground to the registry and it will pop up here. So we have like a public registry for smart contract which is registry.

You can find playground there and like test it out. So if you're done building yours and you want to add it to registry. So right here you can basically just add we have like the steps on the read me of the ripple and pop up here. Oh, interesting. So, theoretically, um um developer relations engineers or protocol engineers can come in and basically upload working code samples um to this. Correct. That's the idea.

>> Yeah, exactly. >> Ah, right on. Right on. Yeah, I mean it makes sense like a lot of a lot of code is kind of like dispersed in big uh or all these different uh GitHub repositories. So like having these working samples in like a central place I think would be really neat. Um so I I guess if you're a devro watching this uh definitely you'll want to give Lunodoc a try. And uh yeah uh unfortunately we we've come to time here. Um but yeah, David, this was uh amazing to see uh all the all the progress you've made here.

Um and uh yeah, definitely we will share all those um resources for people to um check out. Bonadox, >> you still there, David? Or did I lose you? Yeah, I think um just had like a bunch of stuff and yeah, I think with the resourc um both the docs and you know the videos and the reples like we definitely figure things out but yeah we we covered a lot actually on for each for each um feature

in this instance. >> Yeah. Yeah. And and it shows and it shows for sure. Um, and yeah, I I guess with that, um, thank you again, David, so much for taking the time out of your day to come chat with us today. Um, and, uh, for all the folks watching here today, uh, definitely give Bonadoc a spin. Um, all the resources will be in the description of the, um, the video below. And, uh, yeah, with that, just want to wish everybody a very, uh, happy Friday, happy weekend, wherever you may be. And uh yeah, we'll catch you on another great episode of Devontail next week.

>> Yeah. >> All right. Have a good one. Cheers.