Automated Security Testing for Web3

GM GM! Welcome to what's going to be another great episode of DevNTell. So if you didn't know, DevNTell is a 30-minute podcast held every Friday, allowing founders, hackers, and anyone in between to come on the show and showcase their product. And today I'm excited to welcome Josh Quintal and Dipesh Sukhani of BuildBear. If you didn't know, BuildBear is a platform for automated testing and security analysis with support for shareable sandbox testing environments, faucets, and plugins. If you stick around for today's episode, you'll see Josh and Dipesh discuss automated testing, security best practices, and how BuildBear is able to help streamline those processes. Alright, let's get into it.

GM GM! Welcome to the show Josh and Dipesh. Thank you so much for taking the time to come on today. Before we get into all the goodies you have prepared for us for automated testing in Web3, perhaps you'd like to start off with an introduction about yourselves, just in case folks aren't familiar?

Yes, I can start. My name is Dipesh, I am the co-founder of BuildBear Labs. My background is actually been as an international tax lawyer right before I jumped into Web3 in 2017. So I used to do, I practiced 11 years for international tax. And then since 2016, I got introduced to blockchain and I really loved what this was doing. And then I just really had this one thing that I want to become a smart contract developer. So I quit everything in 2017 and said let's go to a library and start studying how to code, so it's a self-taught journey. And honestly, Web3 is fantastic. Right after my job, I actually got some opportunities to basically kind of do an internship, basically help them out with a lot of stuff. And then I can study JavaScript and slowly, slowly build my way into coding. And yeah, then did that for approximately around five years until 2022 when there were just a lot of inefficiencies that I was facing in terms of development. And I had this one thing that I'm competing with some of the finest people in this thing, self-taught, I mean I have a lot to catch up. So what can I do to just help myself? And I started building this small tool and then started sharing with a couple of friends of mine that does it help you guys, and if it does just give me feedback because I wanted to basically cut a lot of development time. And one thing led to the other and it's what BuildBear Labs is today. Josh?

Yeah, very cool. Yeah, hey everyone, I'm Josh Quintal, I'm the product manager at BuildBear and I've been in the space since about 2017. I had previously worked at a marketing firm, but I had heard a little bit about Bitcoin and about Ethereum. And then coincidentally actually like a contractor that we had at that agency invited me to an Ethereum meetup in Detroit where I was at the time. And yeah, I went and the bug bit me, I thought smart contracts seemed really cool, really useful. And then from there I discovered Truffle, the developer tool, and actually made a series of boilerplates called Truffle Boxes. I think actually maybe like truffle-box.github.io might still exist, but so I made those boilerplates and it was pretty early on so like no one had really done something like that at that point. And it caught the attention of Tim Coulter, who was the founder and CEO of Truffle for many years. And so then he messaged me through Reddit actually through that Reddit post and then the rest is history. I worked there at Truffle throughout our time both at ConsenSys as an incubator and then when we spun out as an independent company and then were later actually re-acquired when ConsenSys split into ConsenSys Software and ConsenSys Mesh to make a dev tool stack. But yeah, other than that I've also I've always been in the developer tooling side or at least like the developer end of crypto for sure. Other than Truffle, I've also worked in the NEAR ecosystem building dev tools there and also on the infrastructure side at Infura as well before BuildBear.

Amazing, amazing! So both of you are pretty well versed in the Web3 space and seen your fair share of security exploits, I'm sure, and things people should have been doing better than they did. And I guess how did you both find yourselves- or Josh I guess how did you find yourself at BuildBear? Was it at a conference you met Dipesh or vice versa?

I don't remember, I mean we definitely met first in person at a conference. I think Dipesh correct me if I'm wrong, I think Amal actually introduced us first.

Correct, yeah. So the thing is when I was learning Solidity there was this ConsenSys used to have this bootcamp for smart contract development. And I thought that let me join that. I had already learned smart contract development but I thought now I'm looking for career opportunities so this might be a good place. And Amal, who is my mentor since I had joined ConsenSys, Amal and Josh have worked together a lot. And that was the offline connection that happened and then we met at ETHDenver, I think last year. And then we've been just chatting a lot on this one. And there are some things that what we're doing was something that Truffle was on the roadmap to do, so it just kind of let's say stars aligned where Josh was looking at, yeah this is what we've been building, we should build together.

Amazing, amazing! Yeah, I am always very fond of hearing everybody's origin stories and how things kind of came to be, so thank you so much for sharing. Yeah, I guess without further ado, I know we've had a very interesting 2025 in terms of security and late 2024, so yeah very keen to hear what you have in store for us today.

Cool, good stuff. Thank you. Yes, so yep, automated security testing for Web3. Let's talk about it.

Dipesh and I, yeah I'm laughing because we talked about this previously, we were like, I bet we will have already introduced ourselves before this, so we can skip that.

All right, so testing in Web3. Let's talk about it. What does it look like? What's the current state of it? And I'll note before we dive in, this example's going to be, you know, a fairly robust dApp, right? Like something like a Uniswap but like Biconomy for account abstraction, things like that here. So there will be some moving parts. First, the tried and true, we know it, we love it, are smart contracts. And when it comes to smart contracts, and we're going to talk about unit testing each of these components, you know, we've got fuzz testing in Foundry, also our Solidity unit tests. If you're in the Hardhat world and you're writing JS tests, you're familiar with Mocha and Chai. And then these smart contracts, right, we're connecting with them through- if you're not, you know, connecting with them directly, maybe through your wallet or something like that, you're connecting most typically, especially your end users, through a frontend or a backend. And so your frontend, typically ReactJS, you know, we've got Viem and Wagmi, maybe some lower-level libraries if you're using those. And those get unit tested via Jest and the very, like, large unit testing ecosystem for JavaScript there. Similarly on the backend we've got NodeJS or a Go server and we're unit testing with the tools inherent in those as well.

And you know, maybe this seems relatively simple up to this point, you know, we've got the unit tests for each piece. But thinking beyond this, you know, these moving parts, they integrate together, right? Like we've talked about these being tested in isolation and that's typically what's focused on because the complexity starts to grow here, as we'll see. So in the case of a more complex dApp, you know, again like a Uniswap or something like that, really anything beyond your basics, you might have like an SDK or even just like your own connection library you're starting to maintain, so you've got this now working between your backend and your smart contracts. And all of this going back to the integration testing point and kind of the difficulty inherent here, you know, we have local environments, we have cloud nodes, right? We can run these things, we can have everything kind of talk through that. But integration testing is still difficult. This is definitely not the whole story, right? Because all of these components, they don't exist in isolation. And starting again with smart contracts, you know, we have these services that are hybrids, right? They have off-chain and on-chain components, right? Account abstraction, bridges, oracles. You know, these are all things very commonly used, especially if we're talking about DeFi. Most modern dApps are multichain at this point, so you're definitely dealing with bridging. And again, these are not going to run necessarily in your, you know, local or even most cloud environments.

And then on top of that, beyond integrating all of these various services, you know, we've got the team working on multiple pieces at different times, so things are on different branches. You know, there's a lot to keep track of and you can see especially with there being multiple pieces here and now multiple branches, it's almost like growing exponentially in a way, the complexity inherent in doing an integration test. And so many times they either just get overlooked or they'll be incomplete, right? Like maybe you have most of these pieces but you're missing some of the hybrid services.

And so, you know, really at BuildBear what we've noticed is this being a big hole and it's even caused security issues that we'll talk about later. And one of our missions is to definitely make this process much easier.

So put another way, Web3 testing is incomplete. So just to put a bow on this, make it very clear, you know, there's an isolation of these off-chain or hybrid services, right? So they're usually a pain to test, they get overlooked, typically mocks are used in place of some of these services. We'll talk about why that can be a problem. And then the lack of just integration tests overall is definitely the broad message here. So, you know, a lot of these components, even you know the smart contracts, backend, frontend, they're tested in isolation, but really these components, you know, all interact with each other and so need to be tested together.

And you may be saying, well of course, right? Like maybe you've done some work in Web2, this is all very integration testing in general, the concept is nothing new. And so we can definitely take some lessons from Web2 here. Right, so even in this first example, just a simple C# to-do app, right? And here even this, this even has an integration test, right? Granted it's very C#y, it's using a factory, all these things, but it's still spinning up all the components and testing them together. The REST API endpoints, the database, which in this case is SQLite. Even the GitHub OAuth flow and the frontend pages themselves. So everything here, it's all bootstrapped and tested together.

And then similarly a more, even more complex example, you know, in Web2 that is not dissuading anyone, you still need to do integration tests. Something like Django, right? Which is for those who don't know, is a popular Python web and application framework. Even with all the moving parts inherent in Django, you can still perform integration tests, right? Including services like your token-based auth, again your database, even things like serialization, validation, all of that.

And so, back to Web3. Again, there's mocks usually are the solution to this issue. So even something as complex and well respected as Aave here, they're using mocks in many places in their tests. And so in this example, we'll kind of focus on here, the oracle is being mocked. And there's a few issues here, right? First we'll kind of start neutral and then we'll get into why they're a problem. So a mock oracle, right, sets the price instantly. You know, the price updates without any like failures or any, you know, deviation limits. It's basically like always going to be reliable when that might not be the case in real life. And then similarly functionality-wise, right, liquidations always trigger as expected.

And so this can be a problem because in, you know, in reality, right? Like these oracles, they have update delays, they have failure scenarios, you know they can stall, right? Like functionality within the application itself, or within Aave in this case, right? Can actually be completely prevented. And you know, putting it together it's like the problem here really is that the mock never fails and so it can actually hide these risks, and you're not even really testing these these integrated scenarios. And so I'll pause here just to say that it's not that mocks themselves are a problem, right? I mean there's certain scenarios that you may, you know, want to test in this way. Like let's say, you know, we want to know if the price of a token blows up or goes to zero, we want that price to always be zero or some low amount, that's totally fine. But the problem is that mocks don't go far enough and that to really have a complete and secure testing experience, you're going to want to go further and use integration testing as well.

And so here, yeah, don't take our word for it. We've got two specific examples here. This first one here is about frontend integration. So in this case, we've redacted any names of the actual dApps, but if you're curious maybe you can ping one of us and we can give you the sources for these. But in this case, this was actually a type, a type error, data type error here. So using Web3JS, this frontend, it was actually passing a uint value- or sorry, excuse me, passing a string instead of a uint value. And so the EVM was actually reverting when the smart contracts were interacting with the frontend. And of course, because of that, right, the dApp was just unusable for end users actually going through the frontend. And of course this again just happened because of a simple lack of integration tests, right? The frontend wasn't tested with the smart contracts and so this, you know, fairly basic bug was never found and made it to production.

And so secondly here, this one, this is a bridge, bridge-based issue and also backend server. And so similarly like in this scenario, because of the lack of integration testing, the attacker could actually deploy a fake bridge contract, which would then let them, you know, perform a deposit. And then because the backend API wasn't checking certain validities, they could then like use those fake bridge transactions to initiate a withdrawal of funds. But so in this case, thankfully this was caught in an audit so you know, wasn't actually any fund loss, but either way yeah, the backend failed to validate the smart contract and this could have been a hugely catastrophic here, right? Who knows how many millions of funds could have been lost there.

So again just to like really put a, sorry my cat is- his cat tail was on there. Really, you know, put again just put a fine point on it. Testing is currently mature in Web2, right? It's just taken for granted that of course you're going to be doing integration tests. Your frontend, your backend, your database, each piece gets unit tested, they all get integration tested together. And external services even support robust testing environments, right? Like I'll just focus on Stripe here. Stripe, you may know, actually has like a full testing dashboard, right? You can send transactions to Stripe in a test mode, you're able to view them and again, you can do an entire integration test including that Stripe as that external service.

And so now here, this is where BuildBear actually matures Web3 testing with a similar setup that we'll show you today. So of course your frontend, backend, smart contracts are all unit tested, but BuildBear makes the integration portion easy and in many cases just possible, simply possible, because of its ability to connect to these hybrid services. And some other features that we'll show you that make it easier to perform integration tests. So here we've got examples of Pimlico for account abstraction, we've got Chainlink for VRF and for price oracles, and Gelato for their Web3 actions here.

And so just to continue to drive this home with some of the pieces listed there, you know, BuildBear really takes an ecosystem approach. So, you know, we are a platform for smart contract testing, for running sandboxes, but we don't try to build everything. Like we really like to focus on the fact that like dApps, smart contracts, don't exist in isolation. There's all of these different services. And so we're aiming to support the key ones here. Again, yeah we mentioned Chainlink, Gelato, and Pimlico from the realistic testing environment side. But even for the tooling that you use within BuildBear, right, like I can tell you right now that we have our own internal explorer, but we also support using other explorers like Blockscout as well. So we're really aiming for flexibility. And on the debugging note as well, we'll check out Sentio today actually, Sentio integration. But we also integrate with other tools, you know, noting the security point, right, Solidity scan for automated security scanning and testing there, and then for the realistic environment for those tests that require time advancement, BuildBear has got you covered there as well.

And so yeah, recently we have been very fortunate to have a really nice amount of growth. We've actually have surpassed over 110,000 sandboxes just in the last month here, and over the last four months we've actually had almost 20% growth there. So super happy about that.

And even beyond those plugins that we mentioned, BuildBear's ecosystem's just continuing to grow. So I mean we've got some of the plugins that we mentioned here. We're happy to call, you know, companies like ConsenSys our clients. And just, yeah, a lot of exciting stuff happening in the ecosystem. Sourcify is another good plugin, Remix, Remix support for BuildBear is really great. You can install the BuildBear plugin, run our sandboxes through there, and then claim them for your own user account, really nice experience. Stay tuned there, we're doing some great stuff with Remix specifically.

All right, cool, without further ado, let's dive into the demo. And so because of the way that screen sharing works here, I'm going to have to like unshare and then reshare the demo real quick.

So just to recap, and I guess we'll see in the demo, BuildBear is basically a platform for developers to be able to tap into to like sandbox a test environment essentially and test their smart contracts before- during development and after development too I'd imagine.

Yes, I mean we would like to say it's a platform for testing the application, the entire Web3 application. Because in smart contracts, people are doing phenomenal job when it comes to unit testing using fuzzing or other tools. It's the entire application which needs to be tested thoroughly. Because there we have lot of gaps which people completely miss and that has eventually some or the other impact over there.

Gotcha, gotcha, gotcha, excellent. And perfect segue into the demo. There you go.

All right, let's walk through using the Pimlico Paymaster with a BuildBear sandbox. To show a real-world use case, we're going to execute a Uniswap V3 token swap. Soon we'll be releasing a tutorial and GitHub repo that goes over this content, so stay tuned for that too. Okay, so this is the entire flow of the transaction. You'll need to have a private key for the EOA, which will be used to set up the smart account. The smart account will send a user operation through the Pimlico Paymaster. The smart account will pay in DAI for the gas. The Pimlico Paymaster will pay the gas on behalf of the smart account and send the transaction to the sandbox. Then the sandbox will execute the swap and finally the transaction hash will be returned to the smart account.

So let's get started. First off we need to get a sandbox. So let me pop into BuildBear here and we will get one. I'll note the script we're using today is written for Polygon Mainnet, but of course we could use any other network that Uniswap supports. We can use a random chain ID. All right, so now that we have the sandbox set up, let's go to the dashboard.

And we'll go to the plugins. We want to install Pimlico Alto, of course, with just one click because we want to look at account abstraction. And then for later analysis, we'll also install Sentio. Okay, so now that we've got the plugins installed, we'll head back to the script and walk you through it. With our sandbox URL, we'll set up the sandbox network and define the chain. Using it, you can then create the private key, which is totally optional. If you have a private key, you can use it in the environment file, or you can also generate it using Viem. Then we create the public client using the BuildBear sandbox network. Now we can create the Pimlico client using the sandbox URL and we'll also define the entry point. We'll be using version 0.7 for this tutorial. Then using the private key we'll create the signer. Then using the signer we create a Safe smart account. And now with the smart account, we create a smart account client which will then send the user operations.

So these are some of the parameters. The account, you know, we'll be passing in the account, the chain, the bundler transport, and for the paymaster we provide the paymaster endpoint, which will be our Pimlico client. Then user operation, estimate gas fees, which are totally optional. Okay, so once you have the smart account set up, these are some placeholders for getting the balance and printing it. These are the helper functions. You can get the balance of the accounts for the DAI address, similarly for the USDT address, and then we format it into 18 decimals and 6 decimals respectively.

Okay, then continuing the script, we put a check if there's enough DAI in the account to pay for the gas, we'll execute the script further, otherwise we just print the address and ask for funding and then exit the script. Once the script runs successfully, you'll have a smart account address. So now let's go to the faucet. So we head over here, paste in the smart account address, select the DAI stablecoin, get 100 tokens. As you can see, we've got the 100 tokens. So let's go ahead and continue. We print the before balance for the native tokens, the DAI token, USDT, and we also define the swap parameters. Continuing, we're just doing some logging here so we know what's happening. Then for the user operation, we'll be sending the calls that will be part of the user op. In this case we're first approving the DAI to the Uniswap V3 router and then we are calling the swap function with the exact parameters and the amount etc.

Okay, so once you have estimated the user operation, you can calculate the max user operation gas and then you can also apply this formula to calculate the amount of gas in the token. So this step's totally optional, you can go ahead and skip it, but that would give users an unlimited approval amount in the Pimlico Paymaster. Okay, so let's go ahead now and send the user operation. The calls for this are as follows: we first need to approve the DAI to the paymaster V7 address and the calculated amount of tokens that we did in the previous step. Again you can do the max approvals if you're unsure of the limits that you want to set right now, but at some point you should align this with production. So after that, we approve the swap amount to the Uniswap V3 router. We approve the one ether and then we fill in the parameters for the exact input to execute this. And then you need to define a paymaster context, which is essentially defining what tokens you're choosing to pay for the gas.

All right, let's do this. And once the user operation has gone through, you can see we didn't have any native balance, but you can see that some amount of DAI is deducted for gas and we get this amount of USDT in exchange for one DAI. All right, now that we've got it done, let's go ahead and actually view the transaction in the BuildBear Explorer. So you can see the transaction's gone through, we can view the logs and the token transfers. All right now, let's also check out Sentio too. So over here in Sentio you can also view the trace, so we can watch the flow of funds. We can look at the call traces, the entire call graph actually. And then lastly here we've got the gas profiler where you can see the gas that was estimated and the actual gas used. You can see the events that were emitted, the accounts deployed, the Safe account setup, the user operation, the paymaster address etc. You can also use the debugger in here as well.

So now that we've seen this flow with a script, which could again represent a test or a backend here, let's check out a frontend integration example. So here we're going to walk through one of our clients' dApps, Bruwit. Bruwit lets you swap tokens and easily create subaccounts that can manage portions of your portfolio. You can imagine a feature, right, where agents could control one of these subaccounts, but I'll let you discover that for yourself. Today I just want to demonstrate another great feature of our sandboxes for frontend devs. The sandbox is a great place to also test your dApp with end users. So let's check that out here.

So here I am in the Bruwit interface and we can see I've got access to a few different networks here. All for sandboxes running on BuildBear. I'm going to remain on Base here in this case. So first things first, let's get some tokens from the faucet. We can use the faucet to fund our account like we did previously. But notably I don't own this sandbox, right? This is Bruwit's sandbox, so we're able to access that here. It's a nice flow for your users, right? You can distribute your test URL and the faucet URL. You could of course also pre-fund a list of accounts let's say maybe from a mailing list for your dApp or something like that. But either way you've got options. So here I'll get 100 USDC on Base. Notably we'll actually be getting USDC, I had DAI on the brain from the previous demo. So we'll check out here in Bruwit. Yes, I've got my 100 USDC.

So now let's spread the love and send these to someone. So here I'm going to click transfer and I've already got Dipesh in my address book, so I'll send him 30 USDC. And look at that, we've sent it successfully. So I know this part looked super easy but actually it went even further than our previous example in that this integrates not only the Pimlico off-chain services, but also a frontend, a backend, and all of that in the sandbox environment. So you can see that this could all be automated in your tests or shared with users like we did here for live testing. BuildBear makes all of this much easier than piecing together these services yourself and we are really excited for you to try it.

Oh that was pretty neat. Yeah sorry go for it.

Oh ConsenSys, just going to say I've got a few more slides to wrap it up, don't let me interrupt you while I'm switching here.

One of the critical things that is that for example if today someone is building any account abstraction like the the client one that we showed, they actually reached out to us couple of months back. And they were like what we are building, they're building a little bit more complicated this is just the first version they're going to do multiple versions now. It's going to be doing some Uniswap related trades and Aave for management and all the thing. And they had this issue that the only place that they can test is mainnet. That's it. And they were absolutely clear that they will not do that. I mean who's going to test a lot of these things on mainnet with real money, right? Testnet is not working local is not working and that's what this is like. They were like okay you support a lot of plugins, can you help us just with the Pimlico thing and we built that. Obviously we work with Pimlico on building that thing. So what essentially happens in your sandbox, it's the actual Pimlico's code base which is running. So which runs on the mainnet which is exactly running over here. So thus we are just the engine provider platform for providing the sandbox. And then these plugins can attach anyone can build and attach these plugins and it's thus extremely simple that okay I'm going to use the things that is there on the mainnet for my testing. That's the kind of the bridge that we want to fulfill.

Amazing, love it. And you mentioned it, but anybody can build these plugins? So can you briefly touch on how that would work from a developer perspective if they want to?

Yeah, so what's happening today is that we getting these requests. Now currently we are swamped with a couple of requests on the bridge side. So what we're doing is we haven't opened up for anyone to essentially go ahead like our documentation or the open source like okay this is how you got to build it and then just submit, but that's on the roadmap. Today we are taking the request and then we reach out to the team. For example in this case we built with Pimlico. And then we just build with them so that it's official, right? The first few plugins which actually determine the strength of the platform essentially, right? So we don't want to just dilute it by any random plugin come over there and kind of difficult to control the quality. So that way we going brick by brick and then one point of time hopefully we'll just let people build and attach it and attach to their own sandboxes or give it out publicly so that anyone can use it. Obviously it will be open source people will have to verify those kind of things. So that's still part of the roadmap which hopefully we'll be able to achieve in 2025.

Awesome. Yeah, love to hear it. And yeah, sorry Josh, you said you had a couple more slides to bring us over the line. Go for it.

Yes, yes. No, no, that was good discussion always. I appreciate the questions and everything. Cool, cool. So yeah, just to yeah, quickly summarize and again kind of put a fine point on it. Yeah, in this example already with Pimlico we saved quite a bit of time and added a lot of realism as Dipesh just mentioned. And I will note that, you know, it looked like a lot of steps because we were just walking through like line by line setting up a script for this. But in, you know, your actual test or anything like that, most of that's just setup that you would only do once. And I encourage you to check out the Pimlico documentation. There were many, many steps we did not have to do in setting up any of that infrastructure that was completely abstracted away by us just clicking the install button, so yeah definitely a lot of time saved there. And then similarly when we looked through Sentio, you know, we displayed really notably here a complete workflow, right? So not only did we actually like run a script or let's say a test in this case, but we were able to then, that sandbox persists and we're actually able to then go and inspect the results of that with that Sentio debugger there.

So just to kind of wrap it all up, put a nice bow on it. So when it comes to BuildBear sandboxes, a lot of great benefits. You know, support for Foundry and Hardhat. We support 45 of Foundry's most popular cheatcodes. You can share them with the team just by sharing the URL, or as we showed with that Bruwit example you can share your frontend running on the BuildBear sandbox and the faucet. We've got the realistic testing with the off-chain services. Coming soon, we're working actually on our first bridging plugin with a cross-bridge, so that even like complex multichain scenarios can be tested as well. And again, that complete workflow. But something that we are really looking forward to that we're working on now, and I'm sure we'll talk about here in one second beyond this slide, is actually automation. So all of this is great, but we're still, you know, just talking about the sandbox environment. But again from a security standpoint, right, we want people to be running these tests on a periodic basis, you know, especially when it comes to integrating again with those like hybrid services. Right, you're going to want to be checking regularly whether your integration tests are running or not. And so to that end, we are working on a CI/CD pipeline. It'll be very easy to use, familiar uses familiar tools you already know, GitHub Actions namely. Everything that we've mentioned today will work out of the box, right? Plugins, all that stuff. There's no restrictions, there's no like oh this only works without CI/CD type of thing. And then again with that across-bridge plugin, even something as complex as like a cross-chain scenario can be tested automatically and regularly there as well. So I also encourage you to read this article that Dipesh put out, yeah why automated security testing is essential for Web3. It was a great rebuttal to an article there, but it brings up a lot of great points about automated security testing, some of which we didn't even have time to discuss today.

And if you want to try BuildBear sandboxes, you've already kind of heard the pitch throughout this presentation. So you can just go right to app.buildbear.io, no need to go to our home page or anything like that. And you can dive right in and try it out. So yeah, that's all for the slides. Thank you!

Awesome! And when people do want to start using it, do they have to sign up? Is there any pricing attached to it or can they just like get up and running right away?

No, it's just sign up and start using. There is no paywall, there is no enter your credit card, there is nothing. They can just directly start using it. Actually, the core is that since the last three around years, the core has actually been to automate all of this stuff. It's just that we wanted to make sure that what things need automation needs to be absolutely clear. So let's not go run down and build a big factory where no one wants to come and visit. So that's why this entire sandboxing like where people are, we give them the ability to manually test and we are also manually testing. But the idea is that that should not be the case. The high throughput testing should be completely programmatic as is in the case of Web2. You don't go ahead and launch an app on the Android or iOS Play Store and let the world test it with me and figure out if there's a bug let's go back. That is not what we foresee Web3, right? It has to be smooth and simple.

Yeah, I wholly agree. I don't know why all those so-called rules a lot of developers hold in Web2 get broken in Web3. Maybe like we were discussing, maybe they just didn't exist up to this point. But yeah, it's really awesome to see a platform like BuildBear out there.

Correct. We find it funny, the interesting thing is when I speak to developers, you find it funny even now, which I'm surprised because three years back fine, maybe five years back fine. Even now people test on mainnet. They actually just hold their hand and say yeah, we test on mainnet because there is no other place that we can test. And we were like how do you expect to go with the billion dollar app on a production say we test on production and then we let everyone come and test it and then we kind of scratch our heads come on, that's not going to happen for long, right? We have to fix that thing.

Yeah, yeah, yeah that's certainly eye opening. Maybe those people have really deep pockets and don't care. But even still, even still, not recommended. And finally, unfortunately we're coming to close, what's the best way for people to follow the latest and greatest with BuildBear or reach out if they have questions for either of you or the team?

Well, I think as soon as they sign up like on the platform they'll get the- they'll get a welcome email which is saying this thing and there they will have the link to the social otherwise that's on our website. But on Twitter it's @_buildbear, that's good enough. I think that's the only place where we collate a lot of stuff. But we write a lot of technical blog posts and all that thing. Actually that's the main thing that we kind of do, we're not the best in marketing so we write just technical tutorials a lot. And that has actually been just the best way that people get to know us.

Amazing, love it. And yeah, with that, just want to thank you Dipesh and Josh so much for giving us a very thorough walkthrough and presentation. I think today more than ever, having security and testing forefront in your mind is very paramount to ensuring we don't see massive exploits, or at least reduce them going forward here. And oh, we have a question come through if we want to quickly bring that up. How does BuildBear handle state persistence in its private testnet sandboxes? From Alex.

Well yeah, thank you Alex. But if the question is that how does the state like state- thankfully BuildBear sandboxes are perpetually perpetual in that sense, which means you leave them- you create a sandbox today and you come back five years later, it'll still be exactly at the same place unless obviously we're auto-mining blocks. But then also they'll be just empty blocks. And thus you can continue. And that's the way we manage it is because we were always designing a sort of a high throughput scalable CI/CD solution that was one of the core things was that, to be able to go back in time and inspect and debug any git push, any commit hash that okay what really happened at that point of time. So it was really important to us of how we maintain these states on the sandboxes side.

Great question, great answer. And yeah thank you for that Alex. And yeah I guess with that, for folks who have watched us live, I just dropped a link for you to be able to claim your attendance badge through BitBadges. So if you're into collectibles, definitely check them out. And with that, just want to wish everybody a very happy Friday, happy weekend, and that will catch you back here for another great episode of DevNTell. Alright, have a good one. Cheers!