Simplifying Smart Contract Integrations with Bonadocs

GM, GM. Welcome to what is going to be another fantastic episode of DevNTell. So if you didn't know, DevNTell 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 Atanda from Bonadocs. If you didn't know, Bonadocs 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 an overview of all the new things they've developed on Bonadocs and show us how the Bonadocs toolkit can help developers more easily build Web3 applications. All right, let's get into it.

GM, GM. Welcome back on the show, David. Excited to have you back on, man.

Yeah, definitely good to be back. It's been a couple of months and a lot of progress within that period.

Yeah, I imagine so. I was taking a look at the website and the docs and whatnot. It looks like you guys have built quite a bit more than the first time you were around. But just in case folks didn't catch you the first time on DevNTell, did you want to just give a brief introduction about yourself?

Yeah, I'm David, usually like astro-david.eth on Twitter. Yeah, I used to do engineering at ConsenSys, after which I decided to start building Bonadocs. So Bonadocs is a toolset that allows applications to be built on top of existing smart contract protocols that are on-chain. So it's basically like bridging the gap between application and smart contract integration. Very similar to what we have in Postman for regular APIs, but this time we're building the same thing for smart contracts to ensure that we improve the developer experience of what currently exists today.

I think few people have done a really good job even before Bonadocs came on the scene, folks at ethers and viem, they've done a really good job building out the frontend stack for application devs, ensuring that you're dealing with on-chain transactions directly from your React app or your Next.js app. Even the past year we've seen a lot of good work like Privy that got acquired by Stripe. It's basically the same thing, we're building a better developer experience and user experience on the application side of things.

Excellent, and I'm really excited for you to share all those updates with the folks watching or listening today. And just curious, you mentioned you were previously at ConsenSys. How did you find yourself in tech? Was Web3 the first kind of exposure that you had or was there something else that brought you in?

Pretty much I started with technical writing and also frontend engineering. So I've always been on the application side of things, writing the regular frontend frameworks, React, Vue, JavaScript, TypeScript. Then in 2020 or 2021, during the whole bull market euphoria, was when I really got into the Web3 space. Post that, during the bear market, I started digging into the engineering side and built a few tools, especially from the angle of sending to the wrong wallet address. It felt really weird to me that if you send to a wrong 42-character address, it just goes missing.

So we built a tool that enabled people to send links instead of wallet addresses. Then I applied to ConsenSys and got in. After that period, I joined the ConsenSys fellowship with Bonadocs and from there it's just been up.

That's awesome, man. It's always interesting to hear how people got into tech. And that point around making sure the wallet address is correct is so irreversible, that's a bad experience for sure. During your time at ConsenSys and your experience with the Web3 ecosystem, was there a particular moment or inspiration that led you to working on Bonadocs?

Yeah, so my co-founder and I were basically working with this external team on a side project. We wrote the smart contract and needed these guys to integrate it into their app, and there was just too much confusion. They basically had to jump on calls to say, 'Is this the correct contract method to call?' In my head, I was like, usually when we write APIs, we use a tool called Postman and you're able to call everything directly in that playground environment. In Web3, this didn't exist. We didn't have this integration environment that allows people to import contracts and interact with them like they're on a frontend app before they actually integrate it. Once you have that middle ground, it ensures there's less confusion. You can write the JavaScript, resolve an ENS name, or perform a transfer, and once it works in the playground, you just paste it into your app.

That's a really important point. I think this is a great segue to get into what Bonadocs is. Did you want me to pull up your screen?

Yeah, we can do that right now. It's going to be a short demo. Here we're able to set up an environment for ENS. You have to import the correct contracts. I've imported the Resolver, the project name, description, and the public resolver address. Under Actions, you are able to write JavaScript code that interacts with the smart contract. In this case, I've imported viem. You can import ethers and viem, which are the two major libraries. Here we set up a public client and we're able to get an ENS address.

This method abstracts the universal resolver. I'll open the documentation for clarity. This 'getEnsAddress' method in viem abstracts the resolver, so you don't actually need to call the resolve method on this particular contract directly anymore. So we pass in a subname, bonadocs.astrodavid.eth, and console.log the result. If we run this, we're basically querying the method to get back the address. There it is. If we used the base name, astrodavid.eth, we should get back my actual address. For a frontend developer, if I need to resolve an ENS and I'm confused how it works, I can just use this environment, run the code, and once it works, I move it to my actual app.

Let me open a second playground that shows you how to perform a transfer. This demo uses a virtual testnet, a service that Tenderly offers. Instead of looking for testnet tokens or a faucet, they have this private sandbox. I initialize the public client and a wallet client with the RPC URL for that particular chain. Here we have a write contract for USDT. We're transferring 10 USDT to this address. Once it's sent, we get a confirmation. I'll run this logic. It shows the low-level JavaScript needed. It's like creating an environment to share with others so they understand exactly what your contract is trying to do. I can check the virtual block explorer and see that the transfer has been completed. It looks like an Etherscan but for the private sandbox. This shows what the playground can currently do compared to the first time we spoke.

This is amazing, David. The libraries that you were showing that you can pull in, are those fixed or can people pull in other libraries as they need them?

For now, we've just tried to limit it to viem and ethers to keep it focused on the on-chain logic you're trying to write. You don't usually need external libraries besides those, but I know you can also add Lodash. We're trying to make building functionality on our end much more direct.

Gotcha. And are you limited to a single file that you can play around with, or is it possible to create more than one file that interacts with each other in this playground?

For sure, you can add new actions here. You can choose the simulation engine, like Tenderly or BuildBear, or use Mainnet directly. This gives you a boilerplate to start up. You can have different actions in dedicated files to show how to do different things. To perform an action many times, you need more than one method or some conditional logic, and this environment lets you write those full-fledged actions.

That's awesome. With these virtual environments, you mentioned you can share these with other people. Is there an account system where people sign up and these playground sessions are kept around, or is it a one-shot deal?

You have an account. I'll log in with Google to show you. You create a team; I created one called 'main protocols'. I've been creating these different playgrounds within here. You can also invite team members and they have access to the same team and playgrounds. Besides this, you can create a link for someone outside your team.

You can publish to the server and get this link which you can open in a new tab. This saves it to the server. If you need a playground that is immutable, perhaps for your documentation, you can also save to IPFS. This generates an IPFS link. That way you can share either to your internal team, externally to people, or to the public. Being in Web3, we are open by default. If you save to IPFS, it cannot be edited later and people can be sure that this is exactly your contract and what it's supposed to do.

You guys have made quite a bit of progress since the last time you were on the show. Just curious, any plans to integrate perhaps an AI chat feature in this? I think it would be neat to have something helping you make sense of the code or helping you write it. Any plans for AI in Bonadocs?

Yeah, I've been thinking a lot about autocomplete, similar to Cursor or Copilot. I think that would be a good add, and also for documentation. You could import your contract and the AI could generate documentation for it per method. If you go under documentation here, you can add it for each contract. I'm thinking of a way to have the detailed documentation generated by AI once you import the ABI and address. It's definitely on the way in the coming months.

Great to hear. Is there anything you can share about the Bonadocs roadmap from here on out? Anything you can tease?

What we're trying to tease right now is kind of outside the playground. We've seen what stablecoins can do over the past few years, but the next thing I'm betting on is DeFi protocols from the point of view of yield. How can we get stablecoins to generate yield for people reliably? The same way people invest in ETFs or stocks and hope for a 5% yield, we want to bring that to stablecoins which people are already holding for cross-border transactions or payments. We're thinking of building an API that enables regular FinTechs to provide this to their users, while abstracting the complexity of rebalancing portfolios. A single API to integrate into your app.

Interesting, that's certainly a hot field this year. For the developer audience that's watching and wants to get started with Bonadocs, what's the best way for them to do that? Obviously, they can sign up for the playground, but is there a particular tutorial or starter repo they should look for?

There is the documentation, but we also have a quick start tutorial on YouTube. I'll find it here... yes, this tutorial shows how to set up the Bonadocs playground quickly. We will share this link in the description. For people interested in contributing, we have a few repos that are open to the public on GitHub, including the widget and the protocol registry. We have a registry where you can add your playground if you want anyone to be able to view it. You can find that at registry.bonadocs.com. If you're a DevRel or protocol engineer, you can upload working code samples here so they're in a central place rather than dispersed across different GitHub repositories.

That makes sense. Working samples in a central place would be really neat. Unfortunately, we've come to time here, but David, this was amazing to see all the progress. We will share all those resources for people to check out Bonadocs. Thank you again for taking the time to chat with us today. For all the folks watching, definitely give Bonadocs a spin. All right, all. Have a good one. Cheers.