Every other kind of decentralised physical infrastructure begins with a purchase. Compute networks want an accelerator, storage networks want disks, wireless networks want a radio on a rooftop. The pitch is the same each time: you own an asset, the network finds it a tenant, and the difference between the rent and your running costs is yours.
Bandwidth networks removed the purchase. The asset is the connection already in the building and the part of it nobody is using, which for a household connection is most of it for most of the day. That single difference cascades through everything else in this guide — who joins, what the returns look like, and which problems the network has to solve to be worth anything.
Why would anyone pay for someone else's bandwidth?
Because the open web answers a datacentre differently from a household. A request arriving from a known cloud address range is treated as automated traffic and is frequently rate-limited, served a reduced version of the page, or refused outright. A request arriving from an ordinary residential connection is treated as a person.
That distinction has always mattered to price aggregators and market researchers. What made it a growth market is the training and evaluation of language models, which requires current material from the public web on a continuous basis rather than a one-off crawl. The organisations doing that work need reach, and reach means many ordinary connections in many places.
Assembling that footprint directly is slow and expensive: it means commercial relationships in every market you want to appear in. Assembling it from volunteers who are paid for capacity they were not using takes months instead of years, and this is the entire economic argument for the category. It is a real one, which is worth saying plainly, because most of what is written about DePIN describes a token rather than a trade.
How does it differ from the rest of DePIN?
The three mature categories look similar from a distance — idle capacity, a marketplace, settlement on chain — and behave nothing alike once you look at what constrains each one.
| Compute | Storage | Bandwidth | |
|---|---|---|---|
| Capital to join | An accelerator, and somewhere to run it | Disks, and the power to spin them | None |
| What is sold | Work done over time | Bytes held over time | Reachability |
| What limits supply | Grid connections, not silicon | Cost per terabyte | Willing participants |
| Hardest technical problem | Proving the job ran as specified | Proving the data is still held | Proving the request actually went out |
| Marginal cost to the participant | Electricity, continuously | Electricity, continuously | Effectively nothing |
| Downside if demand does not arrive | You own depreciating hardware | You own depreciating hardware | You uninstall an application |
The last row is the one to read twice. In compute and storage the participant carries inventory risk: the hardware was bought against expected demand, it loses value whether or not that demand appears, and the electricity bill arrives either way. Our reporting on compute networks has repeatedly landed on the same finding — that the binding constraint is power rather than accelerator supply, and that headline hourly rates converged while availability at those rates did not.
In bandwidth there is no inventory. The participant risks time and trust, not capital. That makes the category structurally different from the thing it is usually grouped with, and it is why the honest comparison is not which one pays more.
What is actually being measured?
Three quantities, and they are not equally within your control.
- Availability — how much of the time the device is connected and reachable. Entirely within your control, and in practice the dominant term.
- Throughput used — bandwidth the network actually routes through you. Not within your control at all: it depends on whether demand happens to be directed your way.
- Location — where you are. Reach is not worth the same everywhere, so neither are the rewards, and no amount of uptime changes which country you are in.
The split matters when reading anybody's reported earnings, including ours. A number driven mainly by availability says something about how long a machine was left on. A number driven by throughput says something about demand in that geography during that period, which may not repeat.
How do the rewards work?
Grass credits two separate lines and settles them in Grass Tokens and USDC, calculated from points, bandwidth and location.
| Line | Credited for | Under your control |
|---|---|---|
| Uptime Points | Device availability, and referrals | Yes — keep the device on |
| Network Points | Bandwidth the network routed through you | No — demand-driven |
We ran a single node for 74 days, 3 hours and 30 minutes without touching it after setup. At the end of epoch three it held 262,813.7 Uptime Points and 935.6309 Network Points. Those are the figures on the dashboard, unedited, and the ratio between them is the point of quoting both: availability produced almost all of it.
We are not converting those points into a currency figure. The rate is fixed at distribution and is not knowable in advance, so a dollar amount here would be a number we made up. This applies to every page you will read on the subject, including the ones that sound certain.
Is it worth doing?
The usual way to answer that question does not work here. Return on capital is undefined when the capital is zero, and framing it as yield invites a comparison with instruments that carry principal, which this does not.
The honest framing is a different one. You are not investing money, you are extending a small amount of trust and some electricity to a background process, in exchange for a claim on a distribution whose size you will learn later. Judged that way the question becomes tractable: how much do you trust the operator, and what is the worst thing that happens if you are wrong.
On the first, Grass states that no one, including Grass itself, can access a participant's private information, and that what is shared is spare capacity rather than browsing. That is the operator's claim and it is the claim to examine. On the second, the worst case is an application you uninstall and points that never became worth much — a bad evening, not a bad year.
One practical detail worth knowing before you choose a device: Grass states that Android devices earn three times more than others. A phone that sits on wi-fi overnight is therefore the highest-yield hardware most people already own for this purpose.
Where does it break?
Points are not money until they are
Everything in this category is denominated in a unit the operator defines and can redefine. That is not inherently dishonest — early-stage networks genuinely do not know what a point will be worth — but it means the participant carries the conversion risk, and no dashboard figure is a promise.
Demand does not arrive evenly
Reach into a market nobody is trying to reach is worth nothing. Participants in well-supplied geographies compete with each other for the same routed demand, and the network has no obligation to spread it fairly. Two people running identical setups in different countries should expect different results and neither is doing anything wrong.
You are installing something that runs continuously
This is the real cost, and it is not financial. A background process with network access on a machine you use for other things deserves the same scrutiny as any other continuously running software: what it can see, what it sends, who audits the claim. The correct time to ask is before installing, and the answer should be published rather than assumed.
Verification cuts both ways
Our compute reporting keeps returning to a finding that applies here too: proving that work was done as specified remains the unsolved problem at acceptable cost. A bandwidth network faces the same difficulty from the other side — it has to establish that a participant genuinely relayed what they claim to have relayed, against participants who would rather be paid for doing nothing. Reward models are shaped by that problem more than by any theory of fairness.
How to judge a bandwidth network before joining
Five questions, in the order that eliminates the most candidates fastest.
- Who are the buyers, and is that answer specific? A network that cannot describe its demand side in any terms beyond the token is not selling bandwidth.
- What exactly is shared, stated by the operator in writing? The distinction between spare capacity and your traffic is the whole safety question, and it should not require inference.
- Is the reward model published, or only the rewards? A network that shows earnings screenshots but not how they are calculated has told you nothing you can act on.
- What happens between points and payout? Who fixes the rate, on what schedule, and has a distribution actually happened before.
- Which jurisdictions are excluded? Token eligibility usually excludes sanctioned jurisdictions, and this is worth confirming before you invest time rather than after.
The first and third eliminate almost everything. A network with real buyers can describe them, and a network with a real reward model publishes it — both are cheap to do when true and impossible to fake convincingly at length.
Where this is heading
Two forces point the same direction. Models need current material from the open web rather than a frozen snapshot, and the open web is getting more determined about distinguishing automated traffic from people. Both raise the value of reach through ordinary connections, and neither is close to resolved.
The interesting question is not whether the category survives but who ends up captured by it. A network of volunteers assembled by paying for idle capacity is cheap while participation is voluntary and enthusiasm is high. What it costs when both of those change is not yet known by anyone, and pages claiming otherwise are guessing.
Questions
- What is bandwidth DePIN?
- A decentralised physical infrastructure network whose shared resource is internet connectivity rather than compute or storage. Participants contribute the unused capacity of ordinary connections, and buyers pay for distributed access to the public web. Grass is the network that established the category.
- How is bandwidth DePIN different from compute DePIN?
- Capital and risk. Compute and storage networks require hardware bought in advance, which depreciates and consumes electricity whether or not demand arrives. Bandwidth requires nothing but a connection that already exists, so the participant carries no inventory risk — the downside of being wrong is uninstalling an application.
- How much can you earn from sharing bandwidth?
- Nobody can answer that in currency honestly. Rewards accrue as points and settle later in tokens and stablecoins at a rate fixed at distribution, and they vary by availability, by demand routed to you and by country. Reported point totals — including ours — measure accrual, not income.
- Is sharing your bandwidth safe?
- The safety question is what exactly is shared, and it should be answered by the operator in writing rather than inferred. Grass states that spare capacity is shared rather than browsing, and that no one including Grass itself can access a participant's private information. That is a claim to examine before installing software that runs continuously, not after.
- Does it slow down your internet connection?
- These networks are built to use capacity that is otherwise idle, running in the background. The whole model depends on participants not noticing, because a participant who notices uninstalls and the network loses a node.
- What hardware do you need for bandwidth DePIN?
- None. This is the only DePIN category with no purchase requirement — no accelerator, no drive array, no radio, no grid connection. Any device that is already online qualifies, and Grass states that Android devices earn three times more than others.
- Can anyone join?
- Most people, with one documented exception: token eligibility typically excludes sanctioned jurisdictions. Rewards also vary by country because demand for reach is not spread evenly, so participation being allowed and participation being worthwhile are two separate questions.