Automated Security Testing for Web3

Transcript

gmgm welcome to what's going to be another great episode of devel so if you didn't know Devon tell is a 30-minute podcast held every Friday uh allowing Founders hackers and anyone in between to come on the show and showcase their product and today I'm excited to welcome Josh qual and thees suani of Bill bear you didn't know Bill bear is a platform for automated testing and security analysis with support for sharable sandbox testing environments faucets and plugins if you stick around for today's episode you'll see joshh and depes discuss automated testing security best practices and how build bear is able to help streamline those processes all right let's get into [Music]

it GM GM welcome to the show Josh and the PES thank you so much for taking the time to come on today thank you for inviting us and having us this platform yeah defin excited to be here yeah yeah excited to have you all here um yeah so before we get into all the um all the goodies you have prepared for us for automated testing in web 3 uh perhaps um would you like to start off with introduction about yourselves just in case folks aren't familiar yes I can start uh my name is the be I am the uh co-founder of build by Labs uh my background is actually being uh an international tax lawyer

right before I jumped into web 3 in 2017 so I used to do uh I've practiced 11 years for international tax and then since uh in 2016 I got introduced to blockchain and I really loved what this was doing and and then I just really had a simple thing that I got up I just want to become a smart contract developer so I quit everything in 2017 and said let's go to library and start studying how to code so it's a selftaught journey and and you know honestly web3 is fantastic uh 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 uh yeah then did that for approximately around 5 years in 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 selftaught I mean I have lot to catch up so what can I do to just help myself and I started building a small Tool uh and then start sharing with a couple of friends of mine that does it help you guys and if it does just give me a feedback because I wanted to basically cut a lot of development time and one

thing led to the other and it's what bill be ABS us today Josh amazing yeah Josh yeah very cool yeah hey everyone I'm Josh Quintel I'm the product manager at Bill bear and I've been in the space since about 2017 um I previously worked uh at a marketing firm but i' had heard a little bit about Bitcoin and about ethereum uh and then coincidentally actually like a contractor that we had uh at that agency invited me to an ethereum meet up 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 uh and then from there I discovered truffle the developer tool

and actually made a series of boiler plates called truffle boxes I think actually maybe like truffle dbox.jpg and CEO of truffle uh for many years and so then he messaged me through Reddit actually through that Reddit post and then know the rest of was history I worked there at trouble um throughout our time both at consensus as an incubator and then when we spun out as an independent company and then we're later actually reacquired when consensus split into consensus software and consensus mesh to yet make a de tool stack um but yeah other than that I've also I've always been in the developer

tooling uh side or at least like you the developer end of crypto for sure so other than truffle I've also worked in the near ecosystem building dead tools there and also on the infrastructure side at infura as well before build there amazing amazing so both of you are pretty well versed in in the web 3 space and seen seen your fair share of uh um security exploits I'm sure and and things people should have been doing better um than than they than they did um and I guess uh how did how did you both find yourselves uh or like Josh I guess how did you find uh yourself at bbear um was it at a conference you met the pesh or or vice versa oh I don't remember I mean we

definitely met first in person at a conference uh I think and Def correct me WR I think AAL actually introduced us first correct yeah so uh thing is when I was learning solidity there was this consensus used to have this uh boot camp for smart contract development and I thought that let me join that uh I already learn learn smart contract development I thought now I'm looking for carer opportunities so this might be a good place and Amal who is my mentor uh since I join consensus Amal and Josh have worked together a lot and that was the offline connection that that happened and then we met at the Denver I think last year uh and then we've been just chatting a lot on this one and uh

there are some things that what we doing was something that trle was on the road map to do so just kind kind of let's say stars align but Josh was yeah this is what we've been building we should build together sorry uh amazing amazing yeah I'm always very uh fond of hearing everybody's origin stories and and how things kind of came to be so thank you so much for sharing um yeah I guess uh without further Ado um I know we've had a very interesting uh 2025 in terms of uh security and late 2024 uh so yeah very very keen to hear um what you have uh in store for us

today yeah definitely I can oh sorry to P I saw you mute there if you want to say something else while I'm getting the slides ready here and uh folks um while uh Josh is getting the slides up um if you have any questions um for the team please post them in the chat and we will get those questions answered for you and yeah you good to go Josh go for it cool good stuff thank you yes uh so yep automated security testing for web 3 let's talk about it uh to fession I I'm laughing because we talked about this previously we were like I bet we'll have already introduced ourselves uh before this so we can skip that all right so testing in

web 3 let's talk about it what does it look like what's the current state of it uh and I'll note before we dive in that this example is going to be you know a fairly robust dap right like something like a UNIS swap like a you know bomy for account abstraction uh things like that here so there will be some moving parts so first the Trident true we know it we love it are smart contracts uh and when it comes to Smart contracts uh 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 Hard Hat 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 front end or a back end and so your front end typically reactjs you know we've got VM and wagy maybe some lower level libraries if you're using those those get unit tested via jest and they you know a very like large unit testing ecosystem for JavaScript there uh similarly on the back end we've got nodejs or a go server and we're unit testing with the tools inherent those as well and you know maybe this seems relatively simple up to this point um you know we've got the unit tests for each piece um but Thinking Beyond this you know these moving Parts they

integrate together right like we've talked about these being being tested in isolation and that's typically uh what's focused on because the complexity starts to grow here as we'll see so in the case of a more complex step you know again like a Unis swop or something like that really anything beyond your Basics you might have like an SDK or even just like a series 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 surfaces that are hybrids right they have offchain and onchain components right account abstraction Bridges oracles you know these are all things very commonly used especially if we're talking about defi um most modern deps are multi-chain at this point so you're definitely dealing with bridging uh and again these are not going to run uh necessarily in your you know local or even most Cloud environment 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 it's almost like growing exponentially in a way the complexity inherent and 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 um and so you know really at build there we've noticed you know this being a big hole and it's even caused security issues that we'll talk about later uh and one of our missions is to definitely make this process much easier so put another way web three testing is incomplete so just to put a

put a bow on this make it very clear you know there's an isolation of these offchain 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 uh and then the lack of just integration test overall is definitely the the broad message here so you know a lot of these components even you know the smart contracts back end front end 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 at web to this is this is all very integration testing in general like the concept is nothing new um and so we can

definitely take you know some lessons from web to here right so even in this first example just a simple C to-do app right and here even this even has an integration test right um you know granted it's very carpie it's using a factory all these things um but it's still spinning up all the components and testing them together the rest API endpoints the database which in this case is SQL light even the GitHub Olaf flow and the front end Pages themselves so everything here it's all bootstrapped and tested together and then similarly a more even more complex example you know in web 2 that is not dissuading anyone you still need to do integration tests something like Jango 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 Jango uh you can still perform integration tests right including services like your token based off again your database um even things like serializing validation all of that and so back to web 3 again there's mocks usually are the solution uh to this issue so even something as complex and well respected as a 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 um and there's a few issues here right um first we'll

kind of start neutral and we'll get into why they're a problem so a Mach 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 um and then similarly functionality wise right liquidations always trigger as expected and so this can be a problem because you know in reality right like these oracles they have update delays they have failure scenarios they canall right like functionality within the application itself or within op 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 actually hides these risks uh 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 that's totally fine um 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 uh 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 integration uh so in this case we've we've redacted any names of the actual daps but if you're you're curious maybe you can ping one of us we can give you the sources for these um but in this case uh this was actually a type uh a type error data type error here so uh using web 3js this front end it was actually passing a uint value or sorry excuse me passing a string instead of a uint value uh and so the evm was actually reverting and the smart contracts were interacting with the front end and of course because of that right the dab was just unusable uh for end users actually going through the front end and of course this again just happened because of a simple lack of

integration tests right the front end wasn't tested with the smart contracts and so this you know fairly basic bug was never found andm it to production and so secondly here this one this is a bridge uh Bridge based issue and involves a backend server and so similarly like in this scenario because of the lack of integration testing the attacker could deploy a fake bridge contract um 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 um but so in this case thankfully this was caught in an audit so wasn't actually any fund

loss but uh either way yeah the backend failed to validate the smart contract and this could have been a hugely catastrophic here right who knows um how many millions funds could have been lost there so again just to like really put uh sorry my cat this cat tail is on there um really you know put again just put a fine point on it you testing is is currently mature in web 3 right it's just taken for granted that of course you're going to be doing integration tests your front end your back end your database each piece gets unit tested they all get integration tested together and external Services even support robot bus testing environments right like I'll just focus on stripe here stripe you may

know you actually has like a full testing dashboard right you can send transactions to stripe in a test mode you're able to view them uh and again you can do an entire integration test including that stripe as that external service and so now here this is where build bear actually matures web 3 testing with a similar setup that we'll show you today so of course your front and back end smart contracts are all unit tested but build bear makes the integration portion easy and in many cases just possible simply possible um because of its ability to connect to these hybrid services and some other features that will show you that make it uh easier to perform integration tests so here we've got examples of Pino for account exraction we've got chain link

for vrf and for Price oracles and gelato for their web three actions here and so just to continue to drive this home with some of the pieces listed there you know build really takes like an ecosystem approach um so you know we are a platform uh for smart contract testing for running sandboxes but we don't try to build everything like we really uh like to focus on the fact that like daap smart contracts don't exist in isolation there's all of these different services and so we're aiming to support uh the key ones here again yeah we mentioned chain link chilato and pinco uh from the realistic testing environment side but even for the tooling uh that you use

within build be right like I can tell you right now that we have our own internal Explorer but we also support using other explorers like black Scout as well so we're really aiming for flexibility and on the debugging note as well uh we'll check out centio today actually centio integration but we also integrate with other tools you know noting the security point right solidity scan uh for automated security scanning and testing there uh and then for the uh realistic environment for those tests that require time advancement build Bears gotri cover there as well and so yeah recently uh we have been very fortunate to uh have a really nice amount of growth uh we actually have surpassed over 110,000 sandboxes um

just in the last month here uh 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 build Bears ecosystems just continuing to grow so we've got some of the plugins that we mentioned here that happy to call you know companies like consensus our clients uh and just yeah a lot of exciting stuff happening uh in the ecosystem source ofing with a good plugin remix uh remix support for build bear is really great you can install the build bear plugin uh run our sandboxes through there and then claim them for your own user account really nice experience uh stay tuned there we're doing some great stuff with uh with remix specifically all right cool without

further Ado let's dive into the demo um uh 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 uh just to recap and I I guess we'll see in the demo um Bill bear is basically a platform for developers to be able to tap into to um like sandbox a environment essentially and test their smart contracts before um during during development and after development too I imagine yes I mean we would like to say

it's a platform for testing the application the entire three application because in smart contracts people are doing phenomenal job when it comes to unit testing using buzzing or uh other tools uh it's the entire application which needs to be tested thoroughly because there we have a lot of gaps which people completely Miss and that has eventually some of the other impact gotcha gotcha gotcha excellent and perfect the way into the demo there you go yes definitely uh cool cool and real quick if I full screen this okay cool I see the yellow border it should still be sharing it all right let's walk through using

the pimo paym with a build there sandbox to show a real world use case we're going to execute a Unis swap V3 token swamp uh 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 uh the smart account will send a user operation through the pimo pay Master the smart account will pay in die for the gas the pimo pay Master 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 build bear here and we will get one uh I'll note the script we're using today is written for polygon main net but of course we could use any other network that Unis swap supports uh we can use a random chain ID all right so now that we have the sandbox set up uh let's go to the dashboard and we'll go to the plugins uh we want to install pimo Alto of course just one click because we wna look at account abstraction uh and then for later analysis we'll also install centio 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 uh using it you can then create the private key

which is it's totally optional if you have a private key you can use it in the environment file or you can also generate it using VM then we create the public client using the build their sandbox Network uh now we can create the pinco client using the sandbox URL and we'll also Define the entry point we'll be using version 0.7 for this tutorial uh then using the private key we'll create the signer and 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 uh the chain the bundler transport and for the pay Master

we provide the pay Master endpoint which will be our Pinal 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 die address similarly for the usdt address and then we format it into 18 decimals and six decimals respectively okay then continue the script we put a check uh if there's enough die 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 die stable coin get 100 tokens as you can see we've got the 100 tokens so let's go ahead and continue uh we print the before balance for the native tokens the die token usdt and we also Define the swap parameters continuing we're just doing some logging here so we know what's happening uh 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 die to the Unis swap

V3 router uh 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 is totally optional uh you can go ahead and skip it but that would give users an unlimited approval amount in the pend go pay Master Okay so let's go ahead now and send the user operation uh the calls for this are as follows we first need to approve the die to the pay Master 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 Unis swap 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 pay Master 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 is gone

through you can see we didn't have any native B bance you can see that some amount of D is deducted for gas and we get this amount of usdt in exchange for one die all right now that we've got it done let's uh go ahead and actually view the transaction in the build bear explore 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 centio too so uh over here in centio you can also view the trace uh 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 pay Master address Etc you can also use the debugger in here as well so now that we've seen this fill up with a script which could again represent a test or a backend here let's check out a front end integration example so here we're going to walk through one of our client daps brewi uh brewi lets you swap tokens and easily create sub accounts that can manage portions of your portfolio you can imagine a feature right where agents could control one of these sub accounts but I'll let you discover that for

yourself uh today I just want to demonstrate another great feature of our sandboxes for front end devs the sandboxes a great place to also test your de with end users so let's check that out here so here I am in the breu interface and we can see I've got access to a few different networks here all for sandboxes running on build there uh I'm going to remain on base here in this case so first things first let's get some tokens from the faucet uh we can use the faucet to fund our account like we did previously but notably I don't own this sandbox right this is Bru's sandbox so uh we're able to access that here uh it's a nice flow for your users right you can distribute your test URL and the faucet URL uh you

could of course also you know prefunds let's say maybe from a mailing list for your dap or something like that but either way you've got options so here I'll get a 100 die on base we go check out here in notably we'll actually be getting usdc I had a die on the brain from the previous demo through it yes I've got my 100 die so now let's spread the love and send these to someone so here I've I'm going to click here I'm going to click I think we lost the sound transfer

and I've already got in my address book so I'll send him 30 die and look at that we 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 Pino offchain services but also a front end a back end and all 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 so build bear makes all of this much easier than piecing together these Services yourself and we are really excited exed for you to try it yeah

Prett for oh no I was just gonna say I've got a few more slides to wrap it up don't let me uh interrupt you while I'm switching here yeah one of the critical things that is that for example if today someone is building any account instruction like this the client one that we showed they actually reached out to us a couple of months back and they were like what we building they're building a little bit more complicated this is is the first version they're going to do multiple versions now it's going to be doing some you know related trades and a for management all thing and they had this issue that the only place that they can test is main 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 testet 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 Pimco thing and we uh build that you work Pon building that thing so what essentially happens in your sandbox it's the actual pimo C Bas which is running so which runs on the minut which is exactly running so thus we are just the engine provider a platform for providing the sandbox and then these plugins can attach anyone can build and attach these plugins and it that's it's extremely simple that okay I'm going to use the things that is there on the main net for my testing that's the kind of the bridge

that we want soci amazing and um you mentioned it but uh anybody can can build these plugins um so uh can you briefly touch on how um how that would work from a developer perspective if they want to correct yeah yeah so so what's happening today is that we we getting these requests now currently we swarmed with a couple of request and a bridge sign so what we're doing is uh we haven't opened up for anyone to essentially go ahead like our documentation or the open source like okay this how you got to build it and then just submit but that's on the road map today we taking the request and then we reach out to the team for example in this case we build with themo 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 uh just dilute it by any random plugin come over there and kind of difficult to control the quality so that will be going break by break and then one point of time hopefully we'll just let people build and attach it uh and attach to their own sandboxes or give it out publicly so that anyone can use it obviously it'll be open source people will have to verify those kind of things so that's still part of the road map which hopefully we'll be able to achieve in 2025 awesome yeah love to hear it and uh sorry Josh you said you had a couple more slides uh to bring you over the

line go for it yes yes no no that was that was good discussion I 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 uh yeah in this example um we you know in the first one already with pimo we saved quite a bit of time and added a lot of realism as to PES just mentioned um and I will note that it you know it looked like a lot of steps because we were just walking through like line by line setting up a script or 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 to check out the film let go documentation there were many many steps we did not have to

do in setting up uh any of that infrastructure uh that was completely abstracted Away by us just clicking the install button so yeah definitely a lot of time save there uh and then similarly when we looked uh through centio um 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 cot bucker there so just to kind of wrap it all up uh put a nice bow on it so when it comes to build be sandboxes um a lot of great benefits you know support for Foundry

and hard hat we support 45 of foundry's most popular cheat Cod um you can share them with the team just by sharing the URL or as we showed with that bruid example uh you can share your front end running on the build bear sandbox and the faucets we've got the realistic testing with the offchain services uh coming soon we're at working actually on our first bridging plugin with a crossbridge uh so that even like complex multi-chain scenarios can be tested as well uh and again that complete workflow but something uh that we are really looking forward to uh we're working on now and I'm sure we'll talk about here in one second Beyond this slide uh is actually automation so all this is great um but we're still you

know just talking about the sandbox environment um 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 or you're going to want to be checking um regularly you know whether your integration tests are running or not and so to that end uh we are working on a cicd pipeline um it'll be very easy to use it familiar uses familiar tools to you already GitHub actions namely um everything that we've mentioned uh 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 cicd type of thing and then again with that across Bridge plugin

even something as complex as like a cross-chain scenario uh can be tested automatically and regularly there as well so um I also encourage you to read this article that depes put out on yeah why automated security testing is essential for web 3 um it was a a great rebuttal to an article um there but it brings up a lot of great points about autom security testing um yeah some of which we didn't even have time to discuss today so and if you want to try build bear sandboxes uh you've already kind of heard the pitch throughout this presentation so you can uh just go right to app. bear. no need to go to our homepage right like that uh you can Dive Right In and try it

out so yeah that's all for the slides awesome and um when people do want to start using it um do they have to sign up um is there any um pricing attached to it or can it just like get up and running right away no it's uh just sign up and start using there is no payall there is no entor credit card there's nothing they can just directly start using it actually uh the core has said since the last three around years the core has actually been to automate all of this stuff it's just that we 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 that 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 V are also manually testing uh but the idea is that that should not be the case the high through put test 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's the world test it with me and figure out there's a bug let's go back that that is not what we for see web3 right it has to be smooth and simple yeah I I I toally agree I don't know why um like all those so-called rules a lot of developers hold in web to uh get broken in web 3 um maybe like

like we're discussing maybe they just didn't exist up to this point but yeah it's really awesome to see um a platform like B bear out there correct we find it funny the 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 Main net they actually just hold their hand and say y keep testing on main net because there is no other place that can test it like you do you expect how do you expect to go with the billion dollar app on on a on you know production say we test on production and then we let everyone come and test it and then we kind of scratch your heads come on that's not going to happen for long we have to fix that thing yeah yeah yeah

that certainly eye opening maybe maybe those people have really deep pockets and don't care but even still even still uh not not recommended uh and uh finally um unfortunately we're we're coming to close um what's the best way for people to um follow the latest and greatest with Bill bear or or reach out if they have questions for either of you or the team well uh I think as soon as they sign up like on the platform they'll get the uh they'll get a welcome email which is saying this thing and there they'll have the link to the social otherwise that's on our website but on Twitter it's _ atore billbe that's good enough I think that's the

only place where you collate a lot of stuff but we write a lot of technical block post and all that thing actually that's the main uh thing that we kind of do we 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 uh yeah with that uh just want to thank you uh thees and Josh uh so much for for giving us a very thorough um walk through and presentation um I think today more than ever um having security and testing Forefront in in in your mind is is very Paramount to ensuring um you don't see uh uh massive exploits or at least

reduce them um going forward here and oh uh we have a question come through um if we want to quickly bring that up um how does excuse me how does Bill bear handle State persistence in his private test net s boxes yeah uh thank you Alex but if if the question is that how does the state like State thankfully PB sandboxes are perpetually Perpetual in that sense which means you leave them you create a Sandbox today and you come back 5 years later it'll still be exactly at the same place unless obviously 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 uh sort of a high throughput scalable cicd solution that was one of the core things uh 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 uh these states on the sandboxy side great question great answer um yeah thank you for that Alex uh and yeah I guess with that um for folks who have watched us live um I just dropped a link uh for you to be able to claim your

attendance badge through bit badges um so if you're into Collectibles um definitely check them out uh and with that I just want to wish everybody a very happy Friday happy weekend and that will catch you back here for another great episode of De he righto have a good one cheers