Exploring High Performance Cloud Infrastructure with D_D Cloud

GM, GM. Welcome to what's 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 what they built. And today I'm ecstatic to welcome back Crypdough.eth, who is the founder of Futex Labs and the D_D Cloud platform. So if you're not familiar, D_D Cloud is a high-performance cloud infrastructure built in Rust giving lightning-fast RPC access to your favorite chains. So if you stick around for today's episode, you'll get to meet Crypdough, learn all about D_D Cloud, how it's evolved since the first time he came on the show, and how you can get started using it today. All right, let's get into it.

GM, GM. Welcome back to the show, Crypdough. I'm ecstatic to have you on, man.

GM Narb, thank you so much for having me back on today.

My pleasure, my pleasure. Yeah. It's been a little bit since the last time you were on and gave us that intro of D_D Cloud. At that time, it wasn't officially launched if I recall. So now we're fully in business. So yeah, really ecstatic for folks who missed you the first time to catch up with all the things D_D Cloud this time. But before we get into all of that, would you just like to give a brief introduction of yourself?

Yeah, so I'm Crypdough. I've been in Developer DAO now for what is it? Four years? Three years? Yeah, we've been doing it for a little while now. It's crazy. But yeah, I've done some cool stuff in the space. I was formerly the CTO of GivePact before I went on to find my own company, Futex Labs. And you know, we directly oversee and do all of the development for D_D Cloud. And it's really been such a pleasure. But before that, you know, I've really made my stride in open source. I did the Ethereum Protocol Fellowship back in the third cohort and the Polkadot Blockchain Academy out in the Singapore wave.

Awesome, man. And if I recall from last time, you also compete or used to compete in sport as well, all those medals in the back. For people who missed it last time, do you want to give a brief shout on what those are all about?

Yeah, so when I was in high school, you know, I didn't love studying very much. I wasn't a very academically focused person, but I was athletic. And you know, that's kind of what I lived for 10, 15 years ago. So wrestling in high school and a little bit of college, a little bit in college, I ended up accumulating a lot of hardware over here. I mean, it's mostly stuff from when I was in high school, which is cool, but like, yeah, how the times have changed. Now I'm washed up.

Hey man, it's all good. That those medals take up half the wall. So it's nothing to shake your head at. That's amazing. And yeah, a lot of the time, sport helps people build a good foundation to carry over into other disciplines as well. And I think that's kind of carried on to your founder side as you're quite meticulous and a perfectionist wanting to be absolutely like on the button, especially when it comes to infra and D_D Cloud. I'm sure you'll get into all these details as well as we kind of go along. But kind of to help set the scene, as we know, we might kind of sort of be in a bear market in terms of Web3, but that hasn't stopped builders from continuing on building and pushing innovation forward as it should be. But I guess from your perspective, what might be some of the things in today's developer landscape that might still cause some issues or might not be as optimized in terms of developing dApps?

Yeah, so I mean, I think the big thing is tooling for developers, right? You want to make their experience as cozy as humanly possible, and you want to make sure that, you know, especially if you're running at the infrastructure layer, it's fast, it's effective, and the trade-offs are right for the given use case. So for us, like in particular, right, we're ultra-focused on latency for some use cases, not really for the public service, but you know, for clients that are doing HFT, you know, they have their own special setups that are a bit divorced from the normal public one. But for everyone else who can eat, you know, 150 milliseconds of latency on average, you know, they will basically get away with a very inexpensive service that's like nice to use. I think that's really awesome.

Yeah, for sure. And yeah, I agree. I guess I kind of want to unpack the origin story behind D_D Cloud, because I know you basically went and ran with it ever since the inception of it. Just curious, what was the motivating factor and kind of why did you start D_D Cloud?

So one of the biggest factors was one I had actually received funding for the first time in my developer career. I think that's pretty awesome. I got a generous $25,000 grant from the Pocket Network Foundation and they have been extremely supportive of me and extremely receptive of any sort of criticism or, you know, changes that I wanted to see in their software up or down the stack. So I mean, that's really phenomenal. But beyond that, right, I had started to grow quite a bit of a passion for infrastructure and kind of mission-critical software. Like I'm very perfectionist, I'm very pedantic about my software. So you know, may as well stick it where it matters. That's kind of how I see it. So, you know, other people don't need to stay up at night worrying whether their infrastructure is down or whether the service is reliable. They have someone like me who is, you know, basically their full-time job just to make sure everything's correct.

Amazing. And yeah, I guess with that, for people who might not be familiar, what's your pitch of D_D Cloud? What is it? What problems does it solve?

Yeah, so I mean the main pitch is we're dirt cheap. Yeah, I mean, amazing elevator pitch in two words, dirt cheap. Infrastructure is expensive, you don't want to bleed out your nose in a bear market, you know, this is a great product for you. You know, if you have special requirements like ultra-low latency, yes, we can work with that for more money. But you know, for I think a lot of projects who are just getting started, don't have really deep pockets, our public service is really, really good for that.

And it's not just a paid tier, right? People can sign up for free and start using it, correct?

Absolutely. Yeah, so we do have a free plan that allows you 1 million RPC calls per month. It's a fairly generous free tier. And yeah, all the normal RPC methods will be available. You know, the normal restrictions do apply, like, you know, if you try to like send us a massive eth_getLogs, good luck, have fun. You know, that's configured at the node level to reject it even, so...

Fair enough. Yeah, you always got to plan for the worst. So that's just the way software works.

Definitely. I mean, it's interesting running this sort of infrastructure because you see like how people kind of behave around it. Like sometimes they'll want these extremely data-intensive requests on a multi-tenant service and you know, you don't want to get into a scenario where, you know, one user can starve other users of resources on the same service. That's bad for multi-tenancy in general. You know, for VMs and virtualization, you know, the kind of tangential thing would be like a noisy neighbor, right? You have one VM taking up so much resources that it's affecting the performance of the other VMs with their own kernels.

Yeah, 100%. And yeah, I'm keen to learn what kinds of things you've put into D_D Cloud since the first time you were on the show. I know the platform has evolved since that time, but just want to hear from you, yeah, what's new in D_D Cloud?

Yeah, so we've done a few things. First, there were some stability fixes. You know, these weren't massive patches that were hundreds of lines long, but you know, sometimes there are subtle implementation issues. In particular, like, you know, people would connect to our server through WebSocket, but you know, we'd notice that, you know, every few seconds they'd end up reconnecting and I'd see some weird logs because, you know, I'd get these out of order log messages and like, wait, how is this even possible? I mean, of course, when you start getting into like multi-threaded contexts where, you know, you have a thread dedicated just to, or sorry, a task on the thread pool solely dedicated to reading from the socket from the user and maintaining another thread maintaining the connection to the node, you know, weird things happen between when you start communicating between threads and channels and you just want to make sure that everything is statically correct. In this case, you know, I simply missed a loop around a select macro for all the Rust ball-knowers out there. One of the threads would just get dropped. Yeah, so that's all public by the way. You guys can go to the GitHub repo, you can look at the pull requests, you can look at the individual commitments. But you know, I think that's kind of one of the other awesome aspects of the service that like, you know, for the main thing people can just look at the codebase, see exactly what's going on, that I'm not doing weird things with their data.

Yeah, I mean that's really important in terms of just code transparency, especially in today's world where we're seeing quite the rise in popularity from my perspective of like open-source software again. Most of that is attributed to AI and like how there's all these model providers that are putting their model weights out in the open for people to look at. But yeah, I think it's for the better. More open source the better. And as I understand it, you also offer a CLI tool for D_D Cloud. Did you want to get into that?

Yes. Yeah, definitely. Let me filibuster for about 20 seconds while I get my password for the platform. I don't want to show that on stream, you know. Yeah, no, no leaks on screen here. All right. Leak avoided. Was I sharing the whole time? No. I don't have your screen share on screen. Oh very good. I almost cooked myself. But it doesn't matter, I don't give myself god mode in my own platform so it's not like an attack vector. Someone's going to use up my free plan, bro. Okay, but yeah, still I don't want to leak anything. That would be very funny. Should I bring up your screen? Yeah, that would be awesome.

All right, welcome to my terminal. All right. So the name of the actual CLI tool is D_D Cloud, pretty simple dd-cloud command. And yeah, so let's create a new API key. Let's just go through like some of the stuff you can do here. It's an interactive tool, which I think is pretty awesome. I think that kind of like smoothes the experience a bit. It's not as like aggressive as like a full terminal interface. Actually, can you hide my thing again? Sorry, I need to grab my password back. No worries, no worries. Live demos, this always happens. Very true, very true. All right, we're so back, we're so back. Bring the screen back. Yeah, yeah. Okay, phenomenal. Okay, I don't know if that was too fast. Did you catch that? Yeah, we caught it. Phenomenal. Okay, yeah, this is actually how I generated the new API keys. Okay, here's some funny lore actually. So on earlier versions of D_D Cloud, the API keys were actually Ethereum private keys. Not that I actually used them as such, but like, I just wanted to see if anyone actually noticed. So yeah, that's just like a funny tidbit. Now it's just random bits that are like printable ASCII characters, but yeah. Back to screen. Okay, so I logged in one time, now, you know, this is the real DevX improvement here. See how I didn't have to log in again? User experience times 100. Yeah, exactly.

And when you hit get-api-key, you know, it'll flash the URL on the screen, it'll censor out like virtually all of it and just copy the real deal to your clipboard. So that's I think it's a little bit more palatable than say going all the way back to the website. You know, you just have everything here immediately accessible. So I think that's pretty convenient. You can also track your usage here. I don't know why I have not put that on the actual site, but as you can see, I've been hitting my own service 21,665 times, doing some pretty good numbers here personally. You can also check your balances because the way everything is kind of set up, it's kind of like a credit top-up system versus like a true subscription. Okay, so like there's like you have your monthly subscription cycle, but like you don't have like the notional equivalent of your credit card getting charged every month, you kind of have to remember to top up. And I'm going to segue into this like fairly soon, but you know, we do have our own implementation of a subscription smart contract that would be able to facilitate these pull-based subscription payments. And it's actually, you know, at least in my opinion, a fairly exciting. It'll be very good for the platform and I think it'll be a lot more convenient for our customers in general. What else? Oh yeah, we could delete API keys. Let's delete some keys, let's delete the new key. I am sure. All right, we'll worry about that later. Don't we love a good live demo? Indeed, indeed.

So it seems like the CLI tool is a alternative for folks to be able to kind of get started with the platform, at least on with generating keys and whatnot. But do they have to first sign up on the website to be able to use the CLI or can they just start by using the CLI?

You have to sign up on the website currently, but that will change. You will have a registration command very soon just directly within the D_D Cloud CLI, so you do not have to go far. You can do the entire flow directly from your terminal, or you will be able to do that, and never touch the Chrome browser again if that's the way you want to live your life. That's kind of the way I want to live my life, just to be honest. Can we do everything from the terminal? Yeah. We also have this one other really cool feature that lets you generate your new API key and instead of handling it in plain text, it will actually take your existing AWS login session and put it in your secret manager. So operationally I think that's kind of a clever thing I stashed in there. I will also support the Google Cloud secret manager solution as well when I get around to it. But um, yeah, this is kind of just simplifying the things you will probably have to do for your service at some point anyway. So I may as well kind of simplify it substantially and kind of help people have a better security posture in that way.

Yeah, no, that's definitely a key thing you mentioned. A lot of the time these types of things kind of either they store it for you on their own secret manager or they kind of leave the API key for you to handle, but having that support for bring your own secrets manager is pretty dope. So kudos to you for adding that.

Thank you, thank you. Yeah, it's, you know, I think having a good developer experience kind of comes down to like all the small details. And you know, sometimes I just look at what problems I have as a developer and I just try and kind of solve them for myself, hoping that, you know, other people have those similar experiences.

Yeah, that's typically how a lot of startups begin. You end up solving a problem that you have and then you find out like thousands of other people have the same problem. So yeah, as long as you make their lives easier in any sort of way, they'll probably pay you for it. But as I understand it, you also have some code samples ready for us, so I'd be keen to see just how easy it is to get started with D_D Cloud.

Yeah, totally, totally. So you know, I write everything in Rust including my demos because, you know, it's some sort of mental illness. So you guys are going to get the Rust version of this whole thing. It's not super complex, but I am using Georgios's Alloy. I think he did a fantastic job here. And you know, we even use it in the main service itself for payment processing, kind of things of that nature. So shout out there to Paradigm and yeah, let's get into this little bit here. So working with Alloy for the HTTP connection starts with the provider builder, gives us a little builder interface with connect_http. And if you were doing WebSockets, there's connect_ws as well for the other option. And then once you have the provider struct, you will have at least read-only access to the chain. You can also attach the wallet here, I believe. Right now I think you can attach a signer here. Yeah, you see wallet. This is where the signer would come in. But for this demo at least, we're just doing some read-only stuff. But you know, from the viewpoint of the proxy, it doesn't matter, everything is hitting the node the same exact way. I'm just shuffling some JSON through the pipes there. So our URL, https://api.cloud.developerdao.com/rpc/the name of the chain you want, in this case for this example we are using Base, and then at the end you just append your API key that you've gotten from the service. And you know, I'm of course not flashing my credentials, it's all in a .env file. Even that's not technically good, you should straight up just use a secret manager kind of kind of as I recommended earlier. It's just better security hygiene and you know, if you're doing all this agentic stuff, all this clanker stuff, well you know, you're even worse off having stuff in a .env file on your file system where inevitably they probably have access to it. I don't trust clankers with my credentials. I mean some people do and you know, I don't judge, but I think it's a horrible idea. So from the provider, you know, it gives us access to all of the read-only methods here. So eth_getBlock is one example and you can specify a block tag, whether it's the latest block, it's a safe block, it's a recent block. There's some in between safe and latest that I'm just not remembering, just know there's three flavors. So yeah, let's rip this request. We're also using the Tokio runtime as well. It's pretty standard in the Rust ecosystem. You can see it in my main declaration. But you know, I just wanted to touch on that because you can't really do asynchronous stuff without an asynchronous runtime. So yeah, let's rip a request here.

And in no time you see this massive wall of text having come up with all the cool details of the latest block on Base.

And you were mentioning before that one of the prominent features of D_D Cloud other than it being really fast was it being quite cheap and affordable. I guess in comparison to some other RPC providers out there, like how much can somebody expect to save on their bill if they go with D_D Cloud?

Yeah, so on our lowest tier you can expect roughly a 20% savings over a lot of the industry leaders in the space. That clocks in at a mere 40 United States dollars, well USDC, yeah we do USDC here, 40 USDC. Let me pull up the rest of my pricing. That's how it goes. But you also not only is it like cheaper than a lot of these like paid plans from other providers, but like also you simply get more as well. So when you have our basic plan, you go up to 5 million requests a month, up from the 1 million request per month up in the free tier. For the premier tier, that pushes you to 30 million. And you know, realistically a lot of services will be very happy with that sort of limit. If you are literally crushing requests, our ultra, it's 850 and you'll push 150 million requests a month. But outside of this though, like for our enterprise tiers and things that are not really listed here, I'm not going to give like a an absolute price, but you know, at some point everything just decouples from requests and you're just paying for compute like a real like cloud platform. So, you know, costs do not infinitely scale like with requests, it becomes stepwise at some point and thus it becomes substantially cheaper than any other available option.

Awesome. Yeah, yeah.

Yeah. Well, yeah, I'll show some of the some of the newer endpoints too. I delete stuff from earlier because that's what I do. Okay, so let's let me embarrass myself on stream. Live coding, oh yeah. Yeah, this is just the demo for it, but basically there are a number of scenarios where you want to fetch a number of balances either across like one account, you know, many tokens for one singular account or you might want to query, you know, a whole bunch of different tokens across a whole bunch of different accounts. And this is really just a very nice way of collapsing all of that just into a singular RPC call. And I am going to use my own service as a reference. Again, this you know, you guys could pull this up yourselves, it's on the Developer DAO GitHub. I just want my extension here. Yeah, we're going to do Base again as an example just because we haven't gotten tired of them I guess. I think you need lowercase b for Base if I'm not mistaken. No you're right, but there's actually a quirk with the API. Oh okay, okay. Sure. Yeah, yeah, that's actually a little bit of ball knowledge there.

There you go. I know why it's upset. There we go. I know this is kind of lazy, but you know, it's fine. It's fine for now because you guys can read it. It's just a demo. Yeah. Yeah, the funny thing is I did have everything prepared but now you guys get to see me do it, a little bit of live coding. You know it's the real deal when you see it clacking it out, yeah. Coding with Crypdough. Exactly. All right, I'm re-running it.

All right, so in this example, I requested my wallet on USDC on Base. And you can you can supply like quite a number of these structs like for any contract address and any user. But yeah, this is the structure that's expected. The Alloy address type or sorry, two Alloy address types, yes. And as you can see here, you know, this this is the amount. I'll rip the Python. Oh I don't remember how to use the hex library, never mind. Peak existence. That shouldn't be a very large amount regardless. All good. Yeah, I'm just saving you guys the the search there. All good.

And yeah, I guess as we're coming to time here, I just want to get your thought or perspective on where you see D_D Cloud kind of going in 2026 and if there's anything you can share in the roadmap coming up here.

Yeah, so we actually have a good bit of excitement coming up with D_D Cloud. The first thing I wanted to mention is subscriptions. So we are actually going to be implementing our own smart contract system to process subscription payments on a pull-based system. So basically what that means for our users is you don't need to actually remember to top up every month and, you know, also what I think is really cool is that, you know, you have an on-chain cancel button. Obviously I'm going to, you know, I don't want you to cancel your service if you're paying us but like, you know, we are very strong believers in things like consumer protections. So having it on-chain where it's reachable by all seems seems like a very fair practice to me. And there's some cool nuances that I'm going to talk more about very soon. But the one really cool thing is we have like version-based pricing that effectively prevents, you know, merchants from like draining your account, which is really awesome. And whenever, you know, the merchants want to like increase prices, for example, they actually have to seek direct user approval for that price increase first. So, you know, you don't magically have subscription prices doubling under your nose and, you know, suddenly have like a lot more money missing every month out of your wallet. So we have some really cool implementations there. And as we start inching closer and closer to July, we will also have our container runtime in early preview, which you know, I think is ultra exciting. You know, we're not just running trusted third-party code, which is basically what blockchain nodes are in our system today. But you know, we will be able to fully sandbox isolate and virtualize resources for third-party untrusted code. So, you know, our platform is going to become a lot more expressive, not solely kind of confined to just running blockchain nodes but also arbitrary user software from databases to functions as a service to Docker containers. We're expanding more heavily into what we consider internet infrastructure. You know, everything we have done up to this point even then is internet infrastructure.

That's amazing, man. Yeah, and I'm excited to kind of see all that kind of come out. I guess how can people kind of get involved, get started with D_D Cloud and perhaps be part of that early access preview?

Yeah, so to get started go to cloud.developerdao.com and go through a registration flow. I'm going to be doing quite a few announcements in addition on our Twitter, my personal Twitter as well about any people who want to try our early preview. We have one team that we're currently working with, very exciting, they're an HFT team and you know, they're kind of like our case study if that makes sense. They're going to be stress testing everything and you know, it's so early that you know, I will probably have to manually intervene because I know it's not like 150% stable. But it's you know, it's the kind of workload where I could at least sleep at night so that that is very good. But yeah, I will probably also have like a separate sign-up sheet as well for people who are interested in the very early versions. I wouldn't expect these to be ultra stable, especially like at first. But you know, what's really important is that we find issues, we are able to basically take it from MVP and make it very mature. I think that's that's the ultimate goal of any codebase. You can model it very tightly and prevent a lot of invariants from occurring at runtime.

100%, 100%. And yeah folks, you heard Crypdough. Yeah, definitely get involved, sign up for D_D Cloud. It's free. You got nothing to lose for free. And all those details will be in the description below so definitely do check that out. And Crypdough, just before we let you go, I just want to pick your brain just a little bit. As you are a founder yourself, for the audience member today who might be a founder just starting their founder journey or on the fence of starting the company themselves, is there any words of wisdom or advice you'd want to give them?

Yeah, um, you know, these these exact words have been given to me before but you know, I think they're especially applicable as a founder. It gets worse before it gets better. Now, um, you know, it's it's not easy being a founder. Um, you know, you definitely don't get rich right away by any stretch. And you know, VC money of course has to be used responsibly. We're not funded of course but like, you know, a big investment into your company doesn't make you rich directly unless you have a big exit. But you know, I think what's important is to stay extremely grounded, know why you started building a given product in the first place, and if you believe in it, stay motivated because no one's coming to save you. I think that's that's the big thing. Um, you know, you're taking risk, it's going to be scary, but you know, as long as you're aggressively trying to improve yourself, aggressively trying to improve the product, aggressively improving the company, you'll be able to stay competitive and I think that's what's what's really critical. Founders are here to compete.

Love it. Love it, man. Yeah, and well said. Love it. Yeah, so so there you go, folks. Crypdough, we've unfortunately come to time here, but just want to thank you so much for taking the time out of your day to come join us today. Really awesome seeing all the developments that you've put into D_D Cloud and yeah, can't can't wait to see what's next.

Thanks so much for having me on, Narb.

My pleasure, my pleasure. Happy to have you on anytime. Always enjoy our convos. But yeah, I guess with that, I just want to wish everybody a very happy Friday, happy weekend wherever you may be and we will catch you here next week for another great episode of DevNTell. Till then, have a good one folks. Cheers.