Before anyone plugs their gaming PC into a GPU rental network, there's one question underneath all the others: what is a stranger's code actually allowed to do on my machine? On Dispersed, and other, similar decentralized compute networks, you should treat a running job as if it has the same reach as your own computer. Understanding what that means, and the implications from a security perspective, can help you decide whether to rent out the idle capacity of your hardware to a network.
The timing isn't incidental. GPU demand for AI workloads has outpaced supply in a very specific way: the GPU compute market is projected to grow toward $353B by 2030. With the rapid pace of hardware technology development comes a downside that we believe is an opportunity: lots of perfectly good GPUs are being bypassed by demand for the latest and greatest models. That means a lot of GPU capacity sits idle. In that gap between idle consumer hardware on one side and surging demand for compute on the other, is where networks like Dispersed offer opportunity. A gaming GPU that spends much of its life doing nothing is exactly the kind of underused capacity that AI builders are looking to tap.
For you, as a GPU operator, that means a few things:
The hardware you already own has value sitting idle. You don't need to buy anything new. A GPU you bought for gaming or other personal use can earn while it's not doing that.
Rewards are structured, not arbitrary. On Dispersed, you earn through three components each week: an Availability Reward for simply staying online, a Job Execution Reward for completed work (scaled by your hardware's performance tier), and a smaller Preparation Reward.
An example: an RTX 4090 online 100% of the week, working jobs half the time, earns roughly 11 RENDER for that week. Better hardware earns proportionally more per hour of actual work. A multiplier system scores GPUs on core count, VRAM, network speed, clock speed, and memory bandwidth, with newer high-end cards earning meaningfully more than older ones for the same hours worked.
Getting started is genuinely low-friction. Setup is an afternoon's work: create an account, install Docker and the node client, register your machine. It is not a specialized technical project. (We've written a full step-by-step walkthrough if you want the exact setup process.)
You're not locked into one network, and you're not the only one building this way. The idea of monetizing idle consumer GPUs isn't unique to any single platform. It's a growing category, which means the model itself is proven out beyond just one network's claims about it.
None of that changes the fact that you're running third-party workloads on your own hardware, which is a real trade-off worth understanding clearly. Here's exactly what that trade-off is.
Within Dispersed's own documentation, you’ll find explicit callouts and recommendations for how to think about your GPU. The node client, `disNet`, is explicitly labeled a zero-trust client, and the warning attached to it is direct:
"Jobs can access anything your computer can access over the network or disk."
The recommendation is to run your node behind an isolated network or DMZ. For most networks, that is the main takeaway. Avoid that "containers keep things separate."
Jobs do run inside Docker containers in Dispersed’s case. The structure is simple and straightforward, though it is not a "sandboxed from your machine" set-up. Docker packages a job's application and dependencies into a consistent, portable unit, and provides a layer of process-level organization. That is, a job's processes aren't just running loose and intermingled with every other process on your system. That's a useful property for running varied, third-party workloads reliably and consistently across different machines.
.png)
It does not, however, replace network-level isolation. The documentation states this directly: Docker provides process isolation, but "it does not offer the network-level buffering that a true DMZ provides to protect your internal local area network (LAN)." Combined with the zero-trust warning above, the practical reading is: don't treat the container boundary as a security wall between a job and the rest of what your machine can reach. It isn't positioned as one, and operating as though it is one is a false sense of security that should be avoided.
A DMZ (demilitarized zone) is a network segment that sits between your public-facing services and your private internal network. That’s standard network architecture, not a Dispersed-specific feature. Setting one up means your node machine can receive jobs from the internet without having an open path back into your personal devices, your NAS, your other computers, or anything else on your home network.
Given the zero-trust warning above, this matters. Without it, a job that can reach anything your computer can access over the network is, by extension, potentially able to reach whatever else is sitting on that same network.
Watch out for DMZ labels that aren't truly DMZs: most consumer routers have a setting literally labeled "DMZ Host," and it is not a true DMZ. It simply forwards all unsolicited internet traffic to one device on your main network, which is closer to the opposite of isolation than a solution to it. Real segmentation requires either a VLAN or a router/firewall with a dedicated DMZ port.
This isn't something Dispersed configures for you, and there isn't one universal setup guide, since it depends on your router or firewall. Cisco, Fortinet, and Palo Alto all publish configuration guides for DMZ zones on their hardware. If you're running custom firmware, pfSense/OPNsense and OpenWrt both document VLAN-based isolation for this exact use case. If you're on a standard ISP router, check whether it supports VLANs before assuming its built-in "DMZ Host" toggle is doing the job. On its own, it almost certainly isn't.
Outside of network isolation, account-level protections on Dispersed are as follows:
As a reminder, neither of these addresses the zero-trust warning above. They protect your account credentials and your disk allocation. But they don't change what a running job can reach on your network. That's what the DMZ/VLAN setup is for, specifically because nothing else in the system is designed to cover it.
If you're evaluating whether to put your hardware on any decentralized compute network, these are worth asking before you register anything:
None of these are about distrust for its own sake. This is the same category of question worth asking about any third-party software with access to your hardware.
Renting out your GPU means running jobs that someone else is willing to pay for. If your GPU is otherwise sitting idle, that can be a great way to monetize idle capacity. The security setup is important to understand prior to signing up for any network. If you assume jobs assigned to your GPU are capable of reaching anything your machine can reach over the network or disk, then you’ve taken the first important step. By following the recommended mitigation (an isolated network or DMZ), you should be able to minimize risks associated with jobs assigned to your GPU.
If you already run anything else internet-facing on your home network, such as a home server, a self-hosted service, or a game server, you've likely already dealt with exactly this tradeoff. The same segmentation applies. If you haven't, set up a DMZ or VLAN before registering your first node, not after.
