Your Miner Can Be Perfect and Still Earn Zero. Here's the Wall Nobody Warns You About.

 Somewhere in the Bittensor curriculum, after registration, after the wallet setup, after you've finally got a miner process printing clean startup logs on your screen, there's a single line buried in a metagraph table that decides whether any of it mattered: Active: True or Active: False.

I hadn't gotten to that line yet when I started writing this post. I'd read about registration, I'd read about wallets, I'd gone deep on what subnets actually score and why — but I'd skipped ahead, reading ahead of where I'd actually built, and ran straight into a section of the curriculum that stopped me cold. Not because the code was hard. Because the problem it describes has nothing to do with code at all.

Here's the setup: you can write a flawless miner. Correct logic, clean error handling, every dependency installed right, the process running steadily in a screen session so it survives you closing your laptop lid. You check the logs and everything looks healthy — "Miner ready. Waiting for validator queries..." And then you check the metagraph, and it says Active: False, and your reward is zero, and nothing about your code is the reason.

The reason is almost certainly your router.

The part of mining that has nothing to do with mining

Here's the thing I think trips up a lot of people coming into this the way I did — through the economics and the mechanics first, the tokenomics and the scoring formulas — and only later running into the actual plumbing: a Bittensor miner isn't just a program that thinks. It's a program that has to be reachable. When your miner starts, it opens something called an axon — basically a small HTTP server, listening on a port, usually 8091 by default. Validators don't pull information from you; they send a query to that port, from across the internet, and wait for a response. If that knock on the door never arrives, it doesn't matter how good your answer would have been. You never even know the question was asked.

This is the part that has nothing to do with understanding Bittensor, Yuma consensus, or subnet incentives. It's networking — the same category of problem as setting up a home security camera you can check from your phone, or hosting a Minecraft server for your friends. It's old, boring, completely unglamorous infrastructure plumbing, and it sits directly between "I wrote a correct miner" and "I earned anything at all."

I think this is genuinely underrated as a topic, because it's the kind of thing that doesn't show up in the parts of the curriculum people get excited to read — nobody writes "and then I learned about port forwarding" with the same energy as "and then I burned TAO to register" — but it's quietly one of the most common reasons a technically correct miner earns precisely nothing.

CGNAT: the wall most people don't even know is there

The specific term that stopped me mid-scroll was CGNAT — Carrier-Grade NAT. I'd genuinely never heard of it before this, and the explanation made me feel a particular kind of dumb that's worth being honest about, because I suspect a lot of beginners share it.

Here's the idea. Years ago, every home internet connection got its own unique public IP address — a real, internet-facing address that anyone could, in principle, reach directly. IPv4 ran out of those addresses faster than the internet grew, so a lot of residential ISPs started doing something quieter: instead of giving each household its own public IP, they give hundreds of households one shared public IP, and sort out which traffic belongs to which household using extra layers of address translation behind the scenes. Your router still gives you a private IP at home. But the "public" address your ISP shows the rest of the internet isn't actually yours alone — it's shared, and you don't control the door into it the way you'd expect.

The practical consequence: the classic fix everyone assumes will work — log into your router, forward port 8091 to your machine, done — simply doesn't, because you don't own the public side of that connection anymore. You can forward all you want on your own router and it changes nothing, because the actual gatekeeper is a piece of equipment at your ISP that you'll never get access to.

The way you find out you're behind CGNAT is almost insultingly simple once you know it: check the public IP the internet sees you as (one command), check the private IP your own machine thinks it has (another command), and compare them. If your private side shows something starting with 10.x.x.x or sitting in the 100.64.x.x to 100.127.x.x range, that's the signature. You're behind CGNAT. Port forwarding was never going to work, and no amount of router fiddling would have fixed it, because the problem was never on your end of the connection at all.

I want to sit with that for a second, because it's a genuinely uncomfortable kind of failure mode: you can do everything technically right, follow every instruction precisely, and still fail for a reason that's invisible from where you're standing, baked into a decision your internet provider made for unrelated cost reasons years before you ever heard of Bittensor.

The fix is almost anticlimactic — and that's the point

What actually gets you out of a CGNAT dead end isn't some deep networking mastery. It's a tunnel — specifically something like Ngrok, which flips the entire problem on its head. Instead of trying to let the outside world in to your machine, your machine reaches out to a tunnel service, and that service hands you a public address that forwards straight back to your local port. Validators talk to the tunnel's address. The tunnel relays it to you. Your router and your ISP's CGNAT setup never have to cooperate with anyone, because nothing is trying to get in through them anymore.

It's a genuinely elegant workaround for a problem that has no clean solution otherwise — but it comes with real, practical trade-offs that I think are worth being upfront about rather than glossing over. The free tier of a service like this typically gives you one tunnel at a time, and the address it hands you changes every time you restart it, which means every restart is a small chore: update your miner's configuration with the new address, restart again, hope nothing else broke in the meantime. It's a genuinely fine setup for learning and testnet experimentation. It is not what you'd want sitting under something earning real money long-term, where a paid tier with a stable address, or eventually a small VPS with a real public IP of its own, becomes the more serious answer.

What I find almost calming about this, honestly, is how unglamorous the actual fix is. There's no clever trick, no deep protocol mastery required. It's "rent a small slice of someone else's public-facing infrastructure until you're ready to get your own." That's it. The hard part was never the fix — it was knowing the problem existed at all before your miner had already been quietly failing for who knows how long.

Why "it's running" and "it's working" are different claims

The single most important thing I took from reading this part of the curriculum, before I'd built any of it myself, is a distinction I don't think gets made often enough out loud: a miner that's running and a miner that's earning are not the same claim, and the gap between them is invisible from inside your own terminal.

Your logs can look completely healthy — clean startup, no exceptions, "waiting for validator queries" printed exactly where it should be — and you can still be earning nothing, for hours or days, because the validators trying to reach you are hitting a wall before your code ever gets a chance to run. The terminal in front of you genuinely cannot tell you this. The only place that information shows up is one specific field, in one specific table, that you have to go check on purpose: the metagraph, and that single Active column.

I think this is the kind of failure mode that's almost designed to be missed by exactly the kind of person who's diligent about reading error logs and checking for exceptions — because there isn't an error. Nothing crashes. Nothing throws. The miner is, by every signal visible from inside your own machine, working perfectly. The silence is the bug, and silence is exactly the thing most debugging instincts are built to ignore, because we're trained to go looking when something complains, not when nothing does.

What I'd actually tell someone about to run their first miner

I haven't run this step myself yet — I want to be straight about that, the same way I was about the testnet step I'd skipped and the SN13 setup I hadn't deployed. This is me reading ahead in the curriculum, taking the warning seriously before I get there, rather than reporting back from having already lived through it. But reading it carefully changed what I'm going to do differently when I actually do reach this point, and I think the lessons hold regardless of whether you've hit the wall yet or not.

Check whether you're behind CGNAT before you assume port forwarding will work. It's two commands and a comparison. Doing this first could save you an afternoon of fiddling with router settings that were never going to fix anything, because the actual obstacle was never on your router to begin with.

Don't trust clean logs as proof that you're earning. Healthy startup logs tell you your code didn't crash. They tell you nothing about whether anyone outside your own machine can actually reach you. Those are genuinely different facts, and only one of them shows up in your terminal.

Make checking the metagraph a habit, not a last resort. The Active field is the one piece of ground truth that your own logs can't give you. If you only check it when something already feels wrong, you've probably already lost time you didn't need to lose.

Treat the free tunnel tier as a learning tool, not a long-term plan. It's genuinely good enough to get you running and to prove the whole flow works end to end. It's also explicitly not built for anything you'd want to depend on once real stakes are involved — know that going in, rather than discovering it later when an address change costs you uptime you actually needed.

The unglamorous layer is still the layer that decides everything. Tokenomics, scoring formulas, trading strategies — all of it is genuinely interesting, and all of it is completely irrelevant if a validator's query never physically reaches your machine. I'd been treating networking as the boring prerequisite chapter standing between me and the "real" parts of mining. Reading this section properly made me realize it might be the single most consequential chapter in the entire setup, precisely because it's the only one that fails silently.

The pattern I keep running into in this camp

If there's a thread tying this piece to the others I've written documenting this camp, it's that the most important lessons keep arriving in the sections that look the least exciting on the page. Testnet looked like a detour from the subnet I actually wanted. SN13 looked boring next to the drama of a live betting market. And now: networking, CGNAT, port forwarding — the part of mining that isn't really about Bittensor at all, just about whether the internet can find your laptop — looked like a footnote standing between setup and the actual work.

Every time, the footnote turned out to be load-bearing. I don't think that's a coincidence anymore. I think it's just what learning a genuinely new system looks like: the unglamorous middle chapters are exactly where the failures that don't announce themselves are hiding, and the only way to catch them is to slow down on the parts that don't feel like they deserve it.

If you're about to run your first miner, do yourself one favor before anything else: the moment it's been running for a few minutes, go check the metagraph. Don't trust the clean logs. Go look at one field, in one table, and make sure the internet actually knows you're there.