Bandwidth sharing node IP blocks: how to restore rewards

In many cases, the problem is not the amount of bandwidth available. It is the network identity attached to that bandwidth: the public IP, its reputation, its classification, and whether other devices appear to be using it.

That is the pattern behind the bandwidth sharing node restricted ip error. DePIN bandwidth networks such as Grass, Honeygain, Salad and similar services do not evaluate throughput in isolation. They also assess where the traffic originates, whether the address resembles a residential connection, whether the IP is already associated with other nodes, and whether the connection fits the network’s fraud-prevention rules.

When the IP is restricted, the node may not crash. It may simply stop qualifying for some or all reward activity. That makes the fault easy to misread: operators restart the application, reinstall the client or change wallet settings while the actual problem remains outside the device.

Why DePIN Networks Flag Datacenter and VPN IP Addresses

Bandwidth-sharing protocols are built around a marketplace in which buyers want access to particular kinds of traffic. Residential connections are useful for tasks such as price comparison, advertising verification, localization checks and other forms of web measurement. A request coming from a normal household ISP can behave differently from the same request coming from a hosting provider or commercial proxy network.

That distinction is also why datacenter addresses attract scrutiny. Hosting ranges are inexpensive, easy to provision at scale and frequently used for automated workloads. Those characteristics are useful for legitimate infrastructure, but they also make such ranges attractive for fraud farms, scripted account creation and Sybil activity. A network that pays for supposedly residential bandwidth therefore has a strong reason to separate household connections from server infrastructure before it sends traffic to buyers.

Platforms may use several signals at once:

• the address category returned by an IP intelligence provider;
• the organization and network associated with the address;
• historical abuse or proxy activity linked to the IP;
• whether many accounts or devices appear to share the same public address;
• the geographic location and demand profile of the connection;
• the consistency of the node’s behavior over time.

Honeygain, for example, has publicly described restrictions around Datacenter, VPN and commercial proxy categories. A lookup service such as IP2Location can contribute to that classification, but no single database is necessarily the entire decision-making system. Different services may label the same address differently, and a network can combine external data with its own internal history.

The check normally happens early in the connection process, often around node registration or handshake. In practical terms, the protocol is asking whether the source of the traffic is eligible before treating that traffic as valuable supply. The analogy is closer to an identity checkpoint than to a bandwidth speed test: a fast connection can still fail the eligibility check.

For a broader look at how layered identity checks work in another setting, the gatekeeping mechanics described in passport control at the Calais crossing illustrate the same basic logic in a different jurisdiction. The comparison is limited, but the operational principle is familiar: access is determined by several credentials, not by one visible characteristic.

Grass has also used a points-based distribution model in which a daily pool of Network Points is allocated across eligible supply. Publicly discussed figures have put that pool at roughly 1,000,000 Network Points per day and the award rate at around 0.0049 USDC per point, although the practical result for an individual node depends on the current rules, demand and eligibility filters. The important point is not the headline rate. Points still have to be attributed to traffic the network accepts as valid.

A restricted IP can therefore produce two different outcomes depending on the protocol and the precise rule being applied. The node may be excluded from a reward calculation altogether, or its earning potential may be reduced because some traffic is not counted. Treating every case as a guaranteed zero is too strong; treating the restriction as a minor deduction is also unsafe. The dashboard and the network’s published documentation are the only reliable way to distinguish the two.

A flagged IP is not just a slower connection. It can change whether the network considers the connection eligible to earn at all.

Identifying the Root Cause: IP Classification and Overuse Conflicts

Before changing settings, separate an IP-classification problem from a device-count problem. The messages can look similar from the operator’s perspective, but the remedies are different.

Restricted IP or datacenter detected

This usually means the address has been classified as non-residential, associated with a VPN or proxy service, or otherwise given a reputation that the network does not accept. The node may connect successfully because the application itself is reachable. That does not mean the traffic will qualify for rewards.

A restart cannot change the category of a fixed VPS address. Nor can reinstalling the node client remove a classification held by an external IP database or by the protocol’s own risk system. The useful diagnostic question is whether the public IP changes when the node moves to another connection. If it does, and the rewards return, the original connection was the stronger suspect.

Do not assume that every address owned by a particular large network is treated identically. Classification systems can operate at different levels of detail. They may evaluate the individual IP, a smaller range, the organization, routing information, reverse DNS and observed behavior. An address inside a hosting-related range may be treated as high risk, but it is not technically correct to say that every address in an ASN is necessarily identical in status.

Network overused

This error generally points to more than one device, account or node appearing behind a single public IP. Some services enforce a one-device-per-network or one-device-per-IP rule. Others may allow multiple devices under specific conditions but reduce or deny rewards when the shared address creates an overlap.

The complication is Carrier-Grade NAT, or CGNAT. Under CGNAT, an ISP shares one public IPv4 address among several subscribers. From the node operator’s home network, there may be only one machine running the software. From the protocol’s external perspective, multiple unrelated customers can appear to use the same address.

That makes an overuse message possible even when the operator has not deliberately installed multiple nodes. It is a routing and address-allocation issue, not necessarily a local device-count issue.

Connection failed or IPv6 mismatch

A dual-stack connection can use both IPv4 and IPv6. If the node or the protocol handles one path better than the other, the result can be a connection that looks healthy at the application level but fails to contribute in the expected way. This is not proof that IPv6 is universally unsupported. It means that the actual path used by the node should be tested rather than assumed.

A mismatch can also come from the router, operating system, mobile carrier or APN configuration. One device may prefer IPv6 while another uses IPv4, even when they are connected to the same household network. That is why changing the setting on the node’s device can produce a different result from changing it on the router.

Silent no-earn state

The most frustrating state is the one with no visible error. The node appears online, the process consumes some bandwidth and the uptime counter continues to run, but the points balance remains unchanged.

Several explanations are possible:

• the IP has entered a restricted or low-trust category;
• the connection is behind an overused public address;
• there is little buyer demand for the node’s location at that moment;
• the traffic is not reaching eligible buyers;
• the client is online but not maintaining the quality or availability required for scoring;
• the network has changed its reward rules or is delaying attribution.

Raw throughput is not the same as rewarded throughput. A speed test measures what the connection can deliver to a test server. A DePIN network may reward only traffic that is actually requested by verified buyers and accepted by its validation layer.

Strategies for Refreshing Your Network Identity and Dynamic IPs

The cleanest response to a restricted residential IP is to obtain another address from the same legitimate residential service. That is different from disguising a VPS as a home connection. A new datacenter address may still be classified as datacenter, and a commercial proxy remains a commercial proxy even when it presents a different endpoint.

If the ISP supplies dynamic IPv4 addresses, a normal reconnection may result in a different public IP. The exact process varies by provider and router. A practical first attempt is to power down the router, leave it offline for several minutes, and reconnect it. Some providers release or reassign addresses relatively quickly; others retain the same assignment for much longer. There is no universal DHCP lease window that can be used to predict the result.

Check the public IP before and after the restart. Without that comparison, the power cycle is only a guess. If the address has not changed, the node has not yet been tested against a new network identity.

Several things can prevent a change:

• the ISP may use a sticky assignment linked to the router or account;
• the connection may use a static address;
• the modem and router may need to be disconnected separately;
• the ISP may renew the same lease after reconnection;
• the address may be shared through CGNAT, meaning the visible public IP is not controlled by the household router.

If repeated reconnections produce the same address, contact the ISP and ask whether the connection has a public IPv4 address and whether a new dynamic assignment is possible. Some providers offer a public address only on a different plan or as an optional service. Others can remove CGNAT without changing the underlying line.

Changing the WAN MAC address is sometimes suggested as a way to trigger a new assignment. It can work on networks that associate DHCP leases with the customer router, but it is not universal and may violate an ISP’s terms or disrupt a managed connection. It should be treated as a router-level troubleshooting option, not as a guaranteed fix. Record the original configuration before changing it, and do not alter the modem’s identity if the ISP requires it for service authentication.

Residential connection versus VPS economics

A cheap VPS is attractive because it is easy to deploy, stays online and has predictable monthly pricing. It is also usually the wrong environment for a residential-bandwidth node when the protocol explicitly filters hosting ranges.

The relevant comparison is not the monthly infrastructure bill alone. It is the cost of an eligible connection against the income from traffic that the network will actually count. A low-cost server with no eligible supply can have a lower operating expense and still be economically useless. A residential line may cost more while providing the type of IP the marketplace is designed to buy.

That does not make every residential connection profitable. Demand, location, uptime, hardware and device type still affect the result. It only means that the operator is comparing like with like: eligible residential capacity rather than raw server bandwidth.

Rotating an IP is useful only when the new identity belongs to the type of connection the network is willing to reward.

Troubleshooting IPv6 Mismatches and Device Limit Constraints

CGNAT and IPv6 are often discussed together because both can make the visible network identity differ from the operator’s assumptions. They are separate problems, however, and should be tested separately.

Checking for CGNAT

Start by comparing the WAN address shown in the router’s administration panel with the public address displayed by a standard IP-checking service. If the router receives a private address such as one in the 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 ranges, the router is not holding the public IPv4 address directly. The connection may be behind CGNAT or another upstream NAT layer.

The test is not conclusive in every network design, particularly where the provider uses unusual addressing or multiple routers, but a mismatch is a strong reason to ask the ISP for clarification.

There is no application setting that can turn a shared public IPv4 address into a dedicated one. The possible solutions are provider-side:

1. request a public IPv4 address;

2. ask whether CGNAT can be removed from the line;

3. move the node to a connection with a dedicated or directly assigned public address;

4. use a different ISP if the current service cannot provide a compatible setup.

Adding port forwarding does not solve CGNAT. Port forwarding can direct traffic within the customer’s own router, but it cannot create a unique public identity upstream.

Testing IPv4 and IPv6 independently

If the router and operating system both support dual-stack networking, identify which protocol the node is actually using. A public IP checker can show whether the device has IPv6, while the node’s logs or connection details may reveal the address family used for its sessions.

For a controlled test, temporarily disable IPv6 on the adapter of the device running the node and observe the result over a reasonable period. On Windows, the setting is available in the network adapter properties under Internet Protocol Version 6 (TCP/IPv6). On Linux, the equivalent change depends on the distribution and network manager. On a mobile connection, the APN may expose an IPv4, IPv6 or dual-stack protocol choice.

Do not treat disabling IPv6 as a permanent universal recommendation. It can affect unrelated applications, local services and the performance of other traffic. The purpose is to isolate the fault. If rewards return over IPv4, the operator has evidence about the path that needs attention. If nothing changes, IPv6 was probably not the main cause.

Respecting device limits

Count every instance that may be visible to the protocol, not only the machines in the same room. A laptop, desktop, phone, browser extension and virtual machine can all create confusing overlap if they are connected through the same public address. Family members or tenants on the same ISP connection can also matter when the protocol enforces an IP-based rule.

A sensible inventory includes:

• the devices running the node software;
• browser extensions connected to the same service;
• virtual machines and containers with separate client instances;
• routers or access points that may be forwarding traffic;
• other households sharing the same public IPv4 through the ISP.

If the service permits only one active device per IP, removing duplicate local instances may clear the conflict. If the address is shared by CGNAT, local cleanup will not be enough. The provider must supply a different network arrangement.

Maintaining Node Health to Avoid Automated Reward Restrictions

Restoring rewards is only half the job. A clean residential IP can lose eligibility again if the node behaves like an automated or duplicated source. DePIN protocols use automated systems because they process large numbers of connections, and those systems often react to patterns rather than to an operator’s explanation after the fact.

The safest operating posture is conservative.

Keep the source connection genuinely residential

Do not route the node through a commercial VPN or a datacenter proxy to bypass an IP restriction. That changes the address category without correcting the underlying eligibility problem. It can also create a second reason for the network to distrust the node.

Residential proxies are not automatically equivalent to a normal household connection either. The network may distinguish between a direct ISP address, a proxy endpoint and an address used by many unrelated customers. The relevant question is not whether the endpoint is advertised as residential, but whether the protocol accepts its classification and behavior.

Keep one clear node identity

Avoid repeatedly creating accounts, reinstalling clients to generate new identifiers or moving the same wallet rapidly between unrelated IPs. A legitimate IP change caused by a router reconnection is different from a pattern that looks like identity rotation.

If the network supports a formal migration process, use it. If it does not, record the old and new IP, the time of the change and the node status. That information is useful when an appeal or support request is necessary.

Watch the location and demand profile

Reward rates can depend on where buyers need traffic. A clean residential connection in a low-demand region may earn less than a similar connection in a location with stronger demand. That is not necessarily an IP fault.

The distinction matters because operators often mistake low demand for a ban. If the node remains eligible but receives little buyer traffic, changing the router or repeatedly reinstalling the client will not create demand. Compare the timing of the slowdown with the node’s location, current network status and any published changes to reward rules.

Track uptime and actual contribution

A node that is technically online can still be a poor contributor if it drops connections, loses power, changes networks frequently or cannot sustain the required quality. Track more than the process status:

• public IP and whether it changes unexpectedly;
• connection type and ISP;
• IPv4 or IPv6 path;
• uptime interruptions;
• bandwidth actually used by the node;
• reward timestamps;
• client and router errors;
• changes to the household network.

This log does not need to become a full monitoring system. A simple record is enough to show whether the reward stoppage began after an IP change, a router update, a move to dual-stack networking or the addition of another device.

Treat the device multiplier separately from the IP problem

Some networks distinguish between a desktop node, a browser extension and other client types. A lighter client may earn less because it offers a different supply profile, not because the IP is restricted. Conversely, a dedicated desktop node may contribute more consistently but also has a larger footprint if it is misconfigured.

Do not use device type to explain an IP classification error. First establish that the address and device count are acceptable. Only then compare the earning behavior of different clients on the same eligible connection.

A Practical Recovery Sequence

When rewards stop, change one variable at a time. Otherwise, the operator can produce a new result without knowing which action fixed the original problem.

1. Record the current state. Save the error message, public IP, router WAN address, client version, node identifier and the last time rewards were credited.

2. Check for duplicate clients. Look for desktop apps, browser extensions, virtual machines and other devices that may share the same public address.

3. Test the address category. Use an established IP intelligence service as an indication, not as absolute proof. Different databases can disagree.

4. Compare WAN and public addresses. A mismatch may indicate CGNAT or another upstream NAT layer.

5. Test IPv4 separately. Temporarily disable IPv6 on the node device or select IPv4 in the relevant APN configuration, then monitor the result.

6. Reconnect the residential line. If the ISP uses dynamic addressing, a several-minute power cycle may produce a different IP. Confirm the change rather than assuming it.

7. Move the node to a different legitimate residential connection if necessary. This is a diagnostic as well as a possible fix.

8. Wait for the network’s accounting cycle. A connection change may not appear in the reward balance immediately, and a short period without points is not by itself proof of another block.

9. Contact support with evidence. Include the error, timestamps, IP changes and device count instead of sending a general claim that the node is broken.

The sequence is deliberately unglamorous. Most recovery attempts fail because operators jump directly to a new VPS, a VPN or repeated account creation. Those actions obscure the original cause and can make the node look more suspicious.

Closing Position

The IP layer is the gatekeeper for DePIN bandwidth yields. Operators who treat it as a minor configuration detail can end up with a node that is online but commercially invisible. The remedy is usually not exotic: use a connection the protocol recognizes as residential, keep the device count within the network’s limits, identify CGNAT before blaming the client, and test IPv4 and IPv6 as separate paths.

A dynamic IP refresh can help when a legitimate residential address has developed a poor reputation. It cannot turn a VPS into a household connection, and it cannot guarantee that a new address will be accepted. Address classification is probabilistic and network-specific; one service may allow a connection that another rejects.

The economics should be framed in terms of eligible traffic, not infrastructure price. A cheap server with a restricted address may provide excellent uptime and no meaningful reward. A more expensive residential line may earn only when there is buyer demand, but at least it is operating inside the market the protocol is built to serve.

The practical objective is therefore simple: make the node easy for the network to classify, difficult to confuse with a duplicate, and stable enough to remain eligible. Once those conditions are in place, troubleshooting becomes a matter of evidence rather than guesswork.