Zero-Cost Hops changes that math. It’s a feature that lets messages traverse your well-placed infrastructure routers without spending a hop between them. In practical terms, a chain of favorited backbone routers can behave like a single hop, leaving your precious hop budget for the first and last mile where it actually matters.

Why this matters for backbone builders

If you’re one of the people putting nodes on rooftops and hilltops to form the spine of your local mesh, this feature is aimed squarely at you.

• Faster presets trade range for speed, which means in a dense city you can burn through all 7 hops quickly. Zero-Cost Hops gives each hop more mileage.
• A mesh of well-placed infrastructure routers can effectively collapse into a single hop, freeing up the rest of your budget.
• For well-managed networks, this opens the door to communication between cities, or even across regions, while staying inside the 7-hop limit.
• It helps prevent your CLIENT_BASE (rooftop) node from becoming the final hop that “swallows” a packet, so messages don’t die on the roof before reaching your indoor nodes.

As a real-world benchmark: the Bay Area mesh has over 700 nodes stretching between Tahoe and San Luis Obispo. With careful router placement, Zero-Cost Hops makes it possible for messages to span over 300 miles — a reach that simply isn’t achievable on LoRa across that terrain and distance without this feature.

Step one: Update to the latest firmware

This is the non-negotiable foundation. Zero-Cost Hops requires firmware 2.7.11 or later — but with an important nuance:

• Clients don’t need to do anything. No firmware change is required on regular CLIENT nodes to benefit.
• Only your infrastructure nodes need updating. Specifically, ROUTER, ROUTER_LATE, and CLIENT_BASE nodes must be on at least 2.7.11 to support the feature.

So if you’re running the backbone, updating your rooftop and hilltop nodes is the single most important thing you can do to unlock this capability for the whole community.

Step two: Understand exactly when a hop is “free”

This is where a lot of confusion happens, so let’s be precise. A hop is preserved (the counter does not decrement) only when all of the following are true:

1. The node’s role is ROUTER, ROUTER_LATE, or CLIENT_BASE.
2. It is not the very first hop of the packet.
3. The previous relay is in your favorites list and is itself a ROUTER or ROUTER_LATE.

Miss any one of those conditions, and the hop meter ticks down as normal.

Notice the key insight here: it’s not enough to simply be a router. The relaying relationship has to be mutually recognized through the favorites list. That’s the deliberate design choice that keeps this feature from being abused and turning into a flood.

Step three: Favorite your routers to each other

Here’s the practical setup for backbone contributors:

Router-to-router favoriting. Pick your strategic infrastructure nodes — the ones in high places with good line-of-sight to each other — and favorite them to each other mutually. Once you do, packets relayed between those favorited routers won’t consume a hop. A chain of R1 → R2 → R3 across town becomes, from the hop counter’s perspective, nearly free.

Router-to-CLIENT_BASE favoriting. Do the same for your rooftop CLIENT_BASE node. For incoming favorited traffic coming from routers, CLIENT_BASE counts as infrastructure. This is what stops messages from “dying on the roof” — the last leg from your rooftop base down to your indoor node is protected, so you’ll receive more messages than before.

A worked example

Consider a simple downtown scenario where routers R1 and R2 use the ROUTER role and are favorited to each other. A CLIENT wants to reach a friend in the next town over. The path is:

CLIENT → R1 → R2 → CLIENT

Starting with a hop limit of 4:

Hop	Action	Counter	Hops Remaining
CLIENT → R1	normal (first hop)	−1	3
R1 → R2	zero-cost	0	3
R2 → CLIENT	normal	−1	2

The backbone leg between R1 and R2 cost nothing. That saved hop is now available for extending reach somewhere else in the network. Scale this across a dozen well-placed backbone routers and you can see how a message travels remarkably far on a modest hop budget.

What Zero-Cost Hops does not change

It’s worth setting expectations clearly for your readers:

• The maximum hop limit is still 7. You don’t get more hops — you get more value from each one.
• CLIENT_BASE rebroadcast rules are unchanged. CLIENT_BASE decides what to rebroadcast based on the from/to fields, while Zero-Cost Hops operates on the relay_node field. Favoriting a router does not suddenly cause your CLIENT_BASE to rebroadcast everything.
• Traceroute is unaffected, other than traceroute itself still being limited to 7 hops.

A note on how it works under the hood

To keep the protocol lightweight, the node matches the incoming relay_node value against your favorites list and confirms the node is infrastructure. Because relay_node only has 8 bits to work with, there’s a small theoretical chance of a collision (two nodes sharing the same 8-bit identifier). In practice this is rare and harmless: a colliding node still has to be within range of the router to matter, and deduplication prevents loops. Even in a 1,000-node network with several favorite routers in range, collision probability stays low (around 2%).

The usual safety nets also remain in force — early/default/late transmission timing, packet deduplication, and the natural tendency for this feature to be most impactful (and least abusable) when nodes are in high, well-chosen locations.

Ready to help build the backbone?

If you want to contribute to your local mesh’s infrastructure, the recipe is straightforward:

1. Update your ROUTER, ROUTER_LATE, and CLIENT_BASE nodes to firmware 2.7.11 or later.
2. Pick two or three strategically placed infrastructure nodes.
3. Favorite them to each other mutually, and watch hops stop being consumed between them.
4. Do the same for your rooftop CLIENT_BASE node so messages make it all the way down to your indoor radios.

The payoff is a backbone that reaches dramatically farther on the same hop budget — potentially spanning cities while every participant still runs a sensible, low hop count. That’s better range, less congestion, and a healthier mesh for everyone.

Happy meshing — and may your friends always be within range.