Cloud crypto mining: a pre-investment checklist

The cheapest hour you'll ever spend on any crypto yield project is the one you spend reading the contract before you click "Stake."

Distinguishing DePIN from traditional cloud mining

The phrase "cloud mining" was born in the early 2010s to describe a simple idea: instead of buying a $3,000 ASIC and dealing with its heat and hum, you rent a slice of one running in someone else's warehouse and pocket whatever it mines. The yield came from block rewards, the risk came from electricity price swings, and the model's fatal weakness was its dependence on a single company to keep the lights on. Most of those original outfits are gone. What replaced them in the marketing slot is a wave of DePIN projects, and this is where we want to spend our attention, because DePIN is what an honest "cloud mining" offer actually looks like in 2024.

So how do we tell the two apart at a glance? Traditional cloud mining is rented hash power. You buy a hashrate package denominated in TH/s or GH/s, the operator points it at a pool, and your share of block rewards minus fees lands in your account. Your "infrastructure" is essentially nothing — a credit card payment and a custodial balance on someone else's dashboard. The yield tracks the spot price of the coin being mined and the global network difficulty, both of which can wipe out your projected return overnight.

DePIN is something else. You aren't renting abstract hash power; you're providing a real, verifiable resource that the network actually needs to serve a paying customer. That resource might be storage space holding encrypted files on behalf of a client (think Filecoin or Storj), bandwidth sold as residential proxy capacity to enterprises that need to look like regular internet users (think Grass), wireless coverage broadcast from a hotspot on your roof (think Helium), or GPU compute rented to render farms and AI labs that don't want to own their own silicon (think Render or Akash). In every case, the network checks, provably, that you actually did the work before it pays you.

That last row matters more than anything else on this list. When a project promises a fixed percentage every month regardless of what the network does, that's not yield — that's an obligation the issuer must keep, and history is full of issuers who couldn't. When the dashboard says your earnings depend on uptime, latency, storage sealed, or work delivered, that's a yield tied to work, and it's the only kind worth our time.

If the marketing page tells you what you'll earn before it tells you what you'll do, the page is selling you a return, not a job.

Verifying hardware and infrastructure requirements

Once we know we're looking at a real DePIN offer, the next thing we check is what the network actually wants from us. This is the part where most "is this legit?" questions get answered, because legitimate projects are painfully specific about their requirements. Vague hardware specs are a tell that the team hasn't finished the product.

Let's look at each resource class and what a reasonable spec sheet looks like:

Storage nodes are the easiest to verify. Filecoin, for instance, publishes minimum sector sizes, sealing requirements, and proof-of-spacetime intervals that any prospective operator can read. Storj has a documented bandwidth minimum alongside its storage minimum because the network expects you to serve files to clients, not just archive them. If the project you're eyeing can't tell you what counts as a "valid storage proof" or how often you need to provide one, the rewards are coming out of a marketing budget, not a network budget.

Bandwidth-sharing nodes like Grass run on consumer laptops and modest VPS instances, but the quality of your connection determines your tier. Residential IPs generally pay more than data-center IPs, and the gap is widening as the network's enterprise customers figure out which sources they actually trust. Expect a 100 Mbps-plus uplink and a contract that wants to see the line up 90%+ of the time. If the operator page advertises "no minimum internet speed," assume the network has no paying customers.

Compute nodes for projects like Render and Akash demand specific GPU SKUs, usually NVIDIA cards with enough VRAM to handle the workloads the marketplace brokers. The order details matter: a 3060 with 8 GB will pick up some jobs, but a 4090 with 24 GB opens up render-farm-quality work that pays several times more. The honest pages list supported cards and benchmark numbers; the dishonest ones promise "any GPU works" and route everything through a single shared queue.

A few practical questions we should always answer before buying any hardware:

1. What is the minimum configuration, and what is the recommended configuration? If there's no recommended spec, there's no serious production case.

2. Does the hardware need to be online 24/7, or can it idle? Bandwidth and storage nodes usually need to be; some compute networks pay a premium for elastic availability.

3. Can a VPS satisfy the requirements, or do you need a physical machine in your home or office? VPS saves on electricity but usually rules you out of residential-IP tiers and adds a co-location cost that the dashboard rarely mentions upfront.

4. Is there a slashing or penalty mechanism if you go offline? A 1% slashing threshold tells you the network cares about reliability. No penalty at all is suspicious — it usually means the network has no real demand to lose.

One more thing worth flagging in this section: the difference between a node you operate and a token you stake against someone else's node. Many "cloud mining" dashboards will offer both, and the second option is just a yield-bearing deposit handed to an operator you don't know, with their risk bundled into your return. We can certainly use that product, but it belongs on a different checklist than the one we're writing here.

Analyzing tokenomics and sustainability models

Even a perfectly honest network with a beautifully documented hardware path can pay you in a token that goes to zero. So step three of our checklist is the token itself, and this is where we slow down. A rewards schedule that looks generous at current spot price can be meaningless at issuance-weighted price, and most project docs bury the issuance curve on page 47 of a Notion page we have to find ourselves.

The four pillars we check before committing capital are emission schedule, demand sink, team and investor unlocks, and treasury runway. Let's take them one at a time.

Emission schedule tells you how many tokens the network mints per day, per month, or per epoch, and how that rate changes over time. If rewards are front-loaded into the first 18 months and decay aggressively after that, your real window to break even is tight and the project is probably counting on price appreciation to fill the gap. If rewards decay smoothly and align with projected customer growth, the model has a fighting chance of being self-sustaining by year three. Most DePIN projects we look at will be somewhere in the middle, and that's fine, but we want to see the curve drawn out, not just the headline APR.

Demand sink is the often-missing piece. Tokens earn their value from being used, not from being emitted, so we need to know what the token does besides pay node operators. Storage networks often charge clients in stablecoins and convert a slice of that revenue into token buybacks or burns — that's a real sink. Compute and bandwidth networks sometimes pay operators in stablecoins directly, which neatly sidesteps the problem but also means the token is purely a coordination asset and may never appreciate. Neither model is wrong, but we should know which one we're holding before we hold it.

Team and investor unlocks are where the rug really happens. A polite whitepaper will list a 10% team allocation with a four-year vest and a one-year cliff; an honest cap table will give the cliff date and the monthly unlock thereafter. If those numbers aren't public, or if the team holds more than 20% with sub-12-month unlocks, the early days of the rewards schedule are going to feature a lot of supply meeting a lot of eager buyers, and that meeting usually happens at progressively lower prices.

Treasury runway is the team's ability to keep paying incentives when revenue is thin. A treasury of 24-plus months at current burn tells us the team can sustain rewards through a slow customer-acquisition phase. A treasury of six months or less, especially when paired with an aggressive emission curve, is a project that's racing the clock and wants us to fund the sprint by buying the token.

Real infrastructure rewards reflect real work; the cleaner the work, the steadier the yield. If the token is doing all the heavy lifting, the token is the product, and you are the marketing.

Assessing operational risks and uptime standards

Once the token model passes our sniff test, we shift to the operational reality of running the node day in and day out. This is the unglamorous side of DePIN, and it's where most people quietly give up between month two and month four.

Uptime is the first number we look at, and 99% is the bare professional floor. Storage nodes that drop below 99% lose their proofs and start accruing penalties; bandwidth nodes lose tier status and the multipliers that come with it; compute nodes get deprioritized in the matching queue. Every network publishes its own threshold, but they all cluster around the same idea: if you can't be reachable essentially all the time, your rewards decay toward zero. So before we plug anything in, we need to know what "all the time" actually means in our environment. A home connection with a flaky router, an ISP that does maintenance at 3 a.m. on Sundays, or a laptop that sleeps when the lid closes will all quietly destroy our numbers.

To mitigate that, we want to look for four operational safeguards in the protocol itself:

1. A clear penalty curve. Slashing should be proportional and predictable. A node that knows exactly what one hour of downtime costs can plan around it; a node facing "up to 100% loss" for any infraction is being governed by vibes.

2. Grace periods for new operators. Most legitimate networks give the first 14 to 30 days a softer penalty regime while we tune our setup. If we don't get that runway, the network either has no patience because it's not actually live, or it's optimizing for sybil resistance at the cost of honest onboarding — neither is great.

3. Geographic and IP quality scoring. Residential IPs earning more than data-center IPs is the industry norm and matches real-world buyer demand. What we want to confirm is that the scoring is published, that changes are announced, and that there's no quiet re-tiering that wipes out a node's earnings overnight.

4. A monitoring dashboard we don't have to build ourselves. Niche-quality projects ship an operator console with uptime graphs, earnings history, and proof-submission logs. If we're expected to grep a log file or wire up our own Grafana board to know whether we're being paid, the team is shipping before they've finished QA.

Beyond the protocol side, our own operational posture matters too. A node we run on a VPS we don't back up, in a region we don't monitor, on a hosting plan we'd cancel the moment money gets tight, is a node we've already decided to abandon. The honest projects survive this; the dishonest ones just add the unpaid rewards to their treasury.

Evaluating network utility and real-world resource contribution

Last on our checklist, and arguably the most important, is the question of whether the network actually has a customer for the thing we're producing. A node earning rewards in exchange for unused bandwidth only pays out if some enterprise somewhere is paying the network for that bandwidth. A storage node only earns if a client is uploading files. A compute node only pays if a render farm has a job to dispatch. We can run a perfect 99.99% uptime operation against a network with zero paying customers and earn precisely the token emissions the protocol hands out — which means we're earning our own dilution, and the day the treasury runs out, so do we.

So how do we check for real demand? Three signals are reliable.

The customer side of the marketplace. A storage network should have visible clients uploading data and active retrieval requests being served. A bandwidth network should show enterprise integrations and an API that real companies wire up. A compute network should have a queue depth that goes up and down in response to actual jobs, not just an emission faucet. If the project doesn't talk publicly about its customer pipeline, that's the answer — there isn't one yet.

Revenue, not just rewards. Rewards are what nodes get paid. Revenue is what customers pay in. Many top projects have started publishing on-chain or quarterly numbers for both. A network where revenue grows faster than rewards, even by a little, is slowly weaning itself off emissions. A network where rewards grow while revenue flatlines is paying us in promises.

Multiple revenue lines. The strongest DePIN projects run more than one product on the same infrastructure. A storage network might also serve a CDN. A bandwidth network might also sell geo-data. A compute network might also enable AI inference. Each additional line of business gives the token another reason to exist and another source of demand. Single-purpose projects are fine, but diversified infrastructure is what we want to see if we're committing for the long haul.

A quick ranking exercise we can run before any commitment: score the network from 0 to 5 on hardware specificity, tokenomics transparency, uptime infrastructure, operational tooling, and customer demand. Anything under 18 out of 25 is still in research mode for us. Anything over 22 is a candidate we build a position in slowly, starting with the smallest node the protocol allows and scaling only after we have three months of clean performance data.

A checklist isn't a finish line — it's the filter that decides which projects earn a second hour of your attention.

Bringing it together

The "cloud crypto mining" category is going to keep confusing people as long as marketing pages use the same language for two very different products. The path through that confusion is the same path it has always been: figure out what's actually being sold, what the network actually requires from us, what the token actually does, what the operation actually costs in time and bandwidth, and whether real customers are actually paying for the resource we're providing. If the answer to any of those questions is "they don't say," that's not a yellow flag — it's an instruction to walk away until they do.

Our steady-state process is short and repeatable. We keep a single spreadsheet of projects we're tracking, with one row per network and columns for each of the five sections above. Every quarter we re-score the rows; the ones that improve get more capital, the ones that stall get less, and the ones that miss two quarters in a row get their nodes powered down and their tokens harvested into the next round of research. That boring, methodical approach is the closest thing the space offers to a reliable edge, and it doesn't require us to predict prices, time launches, or chase narratives.

Done right, cloud mining in the DePIN sense becomes exactly what the phrase implied all along: a way to put digital assets and digital infrastructure to work in exchange for a steady, work-backed yield. The work part is the price of admission. If we're willing to do it — to read the docs, run the nodes, monitor the dashboards, and re-check the checklist every few months — we end up in the small group of operators who actually know what their "passive income" cost them, and who can keep collecting it long after the marketing pages have moved on to the next shiny thing.