Almost every proxy you will ever buy is an IPv4 proxy. The industry runs on IPv4 addresses so thoroughly that most providers don't bother labelling them as such — it's the default, and the exceptions are rare enough to be sold separately.

Understanding why that's true, and what it means for pricing, availability, and how blocking actually works, turns out to be unexpectedly useful. IPv4 scarcity is the reason proxies cost what they do. IPv4 address structure is the reason a pool of five thousand addresses can be blocked by a single decision. And the IPv4-versus-IPv6 question, which looks like a technical footnote, has a clear and consequential answer for anyone doing this work.

This guide covers how IPv4 addressing works in the ways that matter operationally, why the address exhaustion story drives proxy economics, how subnet-level blocking works and how to defend against it, when IPv6 is worth considering, and what to actually check when buying.

What an IPv4 Proxy Actually Is

An IPv4 proxy is a proxy using an Internet Protocol version 4 address — the familiar four-number dotted format like 203.0.113.42.

That's the whole definition. IPv4 isn't a proxy type in the way that residential or datacenter are. It's the addressing scheme underneath, and since it's the near-universal default, "IPv4 proxy" is usually a redundant phrase that exists mainly to distinguish from the much rarer IPv6 alternative.

What matters is that IPv4 addresses are a finite, exhausted, and therefore valuable resource, and that they're allocated in structured blocks rather than individually. Both facts have direct operational consequences.

The Exhaustion Story and Why It Sets Your Prices

IPv4 uses 32-bit addresses, which yields about 4.3 billion possible values. That seemed generous in the early eighties and is obviously inadequate for a world with more connected devices than people.

The regional internet registries that allocate address space have been out of freely available IPv4 for years. There is no queue to join. The only way to obtain IPv4 space now is to buy or lease it from someone who already holds it, on a secondary market where prices have risen substantially and consistently.

The consequences that reach you as a buyer:

Addresses have real, non-trivial acquisition cost. A proxy provider offering you an IPv4 address is amortising a genuine capital or lease expense, which is why per-address pricing exists at all.
Pool sizes are constrained by capital, not by will. A provider can't simply spin up another hundred thousand addresses. They have to acquire them.
Address quality varies. Recycled address space carries history. A block that previously served a spam operation arrives with reputation baggage attached.
Prices trend upward. Unlike most technology inputs, IPv4 gets more expensive over time rather than less.
This is why residential and mobile exist as premium products. Those addresses can't be bought in blocks at all — they're allocated to subscribers — which is what makes them scarce in a different and more absolute way.

Understanding this makes proxy pricing legible. You're not paying for bandwidth or servers, both of which are cheap. You're paying for scarce address space and for the reputation attached to it.

IPv4 Fundamentals Worth Knowing

A little more depth on the addressing itself, since it explains several things that otherwise look arbitrary.

The dotted-quad format. An IPv4 address is 32 bits, conventionally written as four 8-bit octets separated by dots. Each octet ranges from 0 to 255, which is why 203.0.113.256 is not a valid address and why proxy lists occasionally contain typos that fail in confusing ways.

Reserved ranges you'll never see in a proxy list. Certain blocks are set aside and never routable on the public internet:

10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are private address space, used inside networks
127.0.0.0/8 is loopback
169.254.0.0/16 is link-local
100.64.0.0/10 is shared address space, used for carrier-grade NAT

That last one is worth noting: it exists specifically because IPv4 exhaustion forced carriers to place subscribers behind shared public addresses, which is the mechanism underlying mobile proxies.

Classful addressing is obsolete. You'll still see references to "Class A," "Class B," and "Class C" addresses, and occasionally to "class C diversity" in proxy marketing. The classful system was replaced by CIDR in the early nineties. When someone says "class C diversity" they almost always mean /24 diversity, and the terminology is a fossil rather than a technical distinction.

Address blocks are announced via BGP. An organisation holding address space announces routes for it, and that announcement is what ties the block to an ASN. This is also why address space can change hands and change classification — the registration and the announcement can both be updated.

Reverse DNS often reveals origin. Many hosting providers set PTR records on their address space that name the company. A reverse lookup on an address is a quick, free way to see whether it's obviously datacenter-registered:

Not definitive, since not all space has PTR records, but a fast first check when you're evaluating whether an address is what it claims to be.

Why Address History Matters

Recycled address space is one of the least-discussed quality variables in proxy purchasing, and it explains a specific and frustrating experience: buying fresh addresses that arrive already blocked.

IPv4 blocks change hands. A range that a proxy provider acquires this year may have spent the previous three years serving a spam operation, a botnet command channel, or simply a very aggressive scraping business. Reputation systems have long memories, and much of that history follows the addresses rather than the owner.

What this means practically:

A brand-new allocation is not a clean allocation. New to you is not new to the internet.
Blocklist entries persist. Some public reputation feeds keep entries for extended periods, and delisting requires an active request from whoever now holds the space.
Commercial IP intelligence databases update on their own schedules. A block might be correctly reclassified in one database and stale in another for months.
Some targets maintain their own long-lived internal blocklists, which no external delisting process touches.

How to protect yourself:

Check a sample of any new allocation against public blocklists before building on it
Send a single request to your actual target from each address and record the response. Anything returning an immediate challenge or refusal was flagged before you got it
Ask the provider whether addresses are issued fresh or recycled, and what their delisting process is
Use the replacement policy early. Providers generally accommodate day-one swaps for pre-flagged addresses, and it's far cheaper than discovering the problem after you've attached workflows to them

Address Structure and Why Blocking Works the Way It Does

This is the operationally critical part, and the reason a large pool can fail all at once.

IPv4 addresses are allocated in contiguous blocks described in CIDR notation. The number after the slash indicates how many bits are fixed:

A /24 block fixes the first 24 bits, leaving 8 bits free — 256 addresses, e.g. 203.0.113.0 through 203.0.113.255
A /22 block — 1,024 addresses
A /20 block — 4,096 addresses
A /16 block — 65,536 addresses

The essential fact: websites block at block level, not address level.

When a site's abuse team decides that traffic from a range is unwanted, they don't block one address. They block the /24, or the /22, or the whole allocation. It's one rule instead of hundreds, it catches the addresses the operator hasn't used yet, and it's how every serious abuse-prevention system works.

The consequence for you is direct and frequently misunderstood: a pool of five thousand addresses drawn from twelve /24 blocks is not five thousand independent chances. It's twelve. One blocking decision by a target can take out several hundred of your addresses simultaneously.

This explains a failure mode that otherwise looks inexplicable — a pool that was working fine suddenly failing wholesale on one site, with everything still working elsewhere. That's not the provider breaking. That's one rule being added to one blocklist.

Checking the diversity of a pool

Straightforward, and worth doing before every purchase:

cut -d: -f1 proxies.txt | cut -d. -f1-3 | sort -u | wc -l

Distribution — how concentrated is the pool?

The first number tells you how many meaningfully independent chances you have. The second shows whether the pool is evenly spread or dominated by a handful of blocks.

A thousand addresses across three hundred /24s is a genuinely different product from a thousand addresses across eight, and no marketing page will tell you which you're getting.

> Tip: When a pool fails wholesale on a single target, check whether the failures cluster by /24 before contacting support. Range-level blocking looks identical to catastrophic pool failure and has an entirely different remedy — which is diversity, not a refund.

ASNs: The Layer Above Blocks

Above individual blocks sits the Autonomous System — a collection of IP ranges under one organisation's routing control, identified by an AS number.

This matters because IP intelligence works at ASN level:

Classification. Whether an address is categorised as hosting, residential, mobile, or business is determined by which organisation the ASN belongs to. This is the mechanism behind datacenter detection, and it's completely reliable.
Reputation. Some ASNs carry poor reputation from historical abuse, and that reputation attaches to every address they announce.
Wholesale blocking. Sites sometimes block an entire ASN — every address a given hosting provider announces — which is a far larger blast radius than a /24.

For pool evaluation, ASN diversity matters even more than subnet diversity. A pool spread across many /24s that all belong to one hosting company is one ASN-level decision away from complete failure.

Checking an address's ASN:

Run this across a sample of any pool you're evaluating and count distinct organisations. It's the single most informative check available and almost nobody performs it.

IPv4 Versus IPv6 for Proxy Work

IPv6 uses 128-bit addresses, providing a number of addresses so large that exhaustion is not a practical concern. Blocks are handed out in sizes that would contain the entire IPv4 internet many times over.

That abundance sounds like it should be an advantage. In practice, for proxy work, it's mostly a liability, and the reasons are worth understanding.

Arguments for IPv6 proxies:

Dramatically cheaper. Address space costs almost nothing, so IPv6 proxies are often priced at a small fraction of IPv4.
Effectively unlimited pool sizes. A provider can offer millions of addresses without capital constraint.
Enormous per-customer allocations. You might be given a block containing more addresses than the entire IPv4 internet.

Arguments against, which usually win:

Many websites don't support IPv6 at all. If a target has no AAAA record, you simply cannot reach it over IPv6. Coverage has improved but remains far from universal, and it's worse among exactly the smaller and older sites that are otherwise easy targets.
IPv6 traffic is treated with more suspicion, precisely because addresses are cheap. An abuser can obtain effectively unlimited IPv6 addresses for nothing, so sites weight IPv6 origin as a higher risk signal. The abundance that makes it cheap is what makes it distrusted.
Blocking is even more aggressive at block level. Since allocations are enormous, sites routinely block entire /64s or larger without hesitation. Your "millions of addresses" may be one block behaving as a single unit.
Geolocation is less accurate. IPv6 geolocation databases are thinner and less well maintained.
Tool support is inconsistent. Plenty of scraping tools, SEO software, and libraries handle IPv6 proxies poorly or not at all.
No residential or mobile equivalent at scale. The premium classifications that make proxies valuable are overwhelmingly IPv4.

The practical guidance: buy IPv4 unless you have a specific, tested reason not to. IPv6 proxies are worth considering only when your targets are confirmed IPv6-capable, your tooling is confirmed IPv6-compatible, the targets are permissive, and the cost saving is large enough to matter. That's a narrow set of conditions, and it's why IPv6 proxies remain a niche product despite being far cheaper.

The Practical Consequences of Scarcity

A few second-order effects of IPv4 exhaustion that shape the market in ways worth recognising.

Providers can't scale pools on demand. When a provider's pool is heavily used, they can't simply add capacity the way a cloud service adds compute. Acquiring more address space takes time and capital. This is why pool sizes are relatively stable across the industry and why a provider suddenly advertising a much larger pool is worth a second look.

Leasing has become common. Rather than buying blocks outright, many providers lease address space from holders. Leased space can be reclaimed, which is one reason addresses occasionally disappear from pools without explanation.

Reputation is an asset with monetary value. Clean address space commands a premium on the secondary market, precisely because dirty space is cheap and unusable. A provider selling unusually cheap datacenter addresses may be passing on space that was cheap for a reason.

CGNAT proliferates. Carriers and increasingly some ISPs place subscribers behind shared addresses. For proxy work this is what makes mobile addresses trustworthy, and it also means residential IP counts are not straightforwardly comparable to household counts.

Geographic allocation is uneven. Address space was distributed generously to early adopters and sparingly to later ones, which is why some regions have abundant, cheap IPv4 availability and others don't. This directly shapes which countries proxy providers can offer, and at what price.

IPv6 adoption is driven by necessity, not preference. Networks that move to IPv6 generally do so because they cannot obtain IPv4, not because IPv6 is better for their use case. For proxy work specifically, that adoption pressure hasn't reached a point where IPv6 becomes a sensible default.

None of this changes what you should buy. It does explain why the market looks the way it does, and it makes anomalously cheap offers easier to interpret.

Where IPv4 Fits Across Proxy Types

Every proxy category is essentially IPv4, but the address economics differ.

Datacenter. Blocks acquired or leased on the secondary market. Diversity depends entirely on how many separate blocks and ASNs the provider has assembled, which is a capital question. This is where checking subnet spread matters most, because contiguous allocation is the norm.

Dedicated. Same address space, allocated exclusively. The exclusivity is about reputation rather than addressing, and the underlying block structure is unchanged.

ISP (static residential). Addresses registered to consumer ISPs but announced from datacenter infrastructure, obtained through partnerships or transfers. The scarcity is more acute here — the supply of address space carrying residential classification is genuinely limited, which is why ISP pools are small and prices are higher.

Residential. Addresses assigned by ISPs to actual subscribers, accessed through consent-based networks. You're not renting address space at all; you're routing through connections that already have addresses. This is why pool sizes are enormous while pricing is per-gigabyte rather than per-address.

Mobile. Carrier-allocated addresses behind carrier-grade NAT, where thousands of subscribers share one public IPv4 address. CGNAT exists precisely because IPv4 exhaustion forced carriers to share, and it's the accidental source of mobile proxies' high trust — blocking one address means blocking a small town's worth of real customers.

There's a satisfying symmetry there: IPv4 scarcity created CGNAT, and CGNAT created the most trusted proxy type in the market.

Geolocation and What IPv4 Addresses Actually Reveal

Address-based geolocation is a large part of why proxies are useful, and it's worth understanding what it is and isn't.

There is no location encoded in an IPv4 address. The address is a routing identifier, not a coordinate. Everything you see in a geolocation lookup is inference from external data.

How the databases are built. Commercial geolocation providers combine registry records showing which organisation holds a block, self-reported location data submitted by network operators, latency triangulation, and behavioural inference from observed user activity. The result is a probabilistic mapping, not a fact.

Accuracy varies enormously by classification.

Datacenter addresses geolocate reliably to the facility, which is accurate and also coarse — you get the city the servers are in, and datacenter presence is concentrated in a small number of places.
Residential addresses geolocate reasonably well to a city or region, because ISP allocation tends to follow geography.
Mobile addresses geolocate poorly. Carriers assign from regional pools and the registered location can be hundreds of kilometres from the device.
ISP addresses inherit residential-style accuracy, though the announcement point may differ from the registration.

Different databases disagree. An address can show as one city in one provider's data and a different city in another's. Your target is using some specific database, and it may not be the one you checked with.

Databases go stale. Address blocks change hands and get reassigned. A block that legitimately served one country three years ago may still be recorded that way.

The practical implications for proxy work:

Verify geo-targeting against multiple sources if location accuracy matters to your data
Test against your actual target's behaviour, not against a lookup service. What matters is what the target believes, not what a database says
Expect coarser accuracy than the marketing implies. City-level targeting means the address is recorded as being in that city, which is a weaker claim than it sounds
Don't confuse geolocation with routing. An address registered in one country may be announced from infrastructure elsewhere, which affects latency without affecting the lookup

Buying Considerations

What to actually check when evaluating IPv4 proxy inventory.

Subnet diversity. Count distinct /24 blocks against total address count. Low diversity means a small number of blocking decisions can eliminate most of your pool.

ASN diversity. Count distinct announcing organisations. Even more consequential than subnet spread, and even less frequently disclosed.

Address history. Recycled space carries reputation. Ask whether addresses are issued fresh, and check a sample against public blocklists before building anything on them.

Geographic distribution. Where the blocks are registered and announced, which determines both geolocation results and latency.

Classification verification. Confirm the addresses classify as what you were sold. Check org and asn against a reputable IP information service, and against a commercial classification database if you have access, since that's what your targets are likely using.

Whether they're genuinely IPv4. Rarely an issue, but if a price looks anomalously low it's worth confirming you're not being sold IPv6.

Replacement policy. When a block gets range-blocked on a target you care about, can you swap out? How quickly, how often, at what cost? This matters more than unit price for anyone doing sustained work.

Refresh cadence. Whether the provider actively cycles burned space out of the pool, which costs them money and is a reasonable proxy for overall quality.

Working With Addresses in Code

A few practical patterns for handling IPv4 structure programmatically, since subnet-aware logic is what turns the theory in this guide into an operational advantage.

Extracting the /24 from an address:

return ".".join(ip.split(".")[:3])

Grouping a pool by subnet:

def groupbysubnet(proxies):

groups = defaultdict(list)

for p in proxies:

ip = p.split(":")[0]

groups[subnet_24(ip)].append(p)

return groups

Subnet-aware selection, preferring blocks that haven't recently failed on this target:

failed_subnets = {} # (subnet, domain) -> timestamp

QUARANTINE = 3600

def pick_proxy(groups, domain):

now = time.time()

healthy = [

s for s in groups

if now - failed_subnets.get((s, domain), 0) > QUARANTINE

]

if not healthy:

healthy = list(groups)

subnet = random.choice(healthy)

return random.choice(groups[subnet])

def record_failure(proxy, domain):

failedsubnets[(subnet24(proxy.split(":")[0]), domain)] = time.time()

The quarantine window is the important detail. Blocking decisions aren't always permanent, and permanently retiring a subnet on one failure discards inventory unnecessarily. An hour is a reasonable starting point; tune from your own failure data.

For anything more involved, use the standard library. Python's ipaddress module handles CIDR arithmetic, membership tests, and network comparisons properly, and is worth reaching for rather than doing string manipulation once your logic gets beyond the basics.

net = ipaddress.ip_network("203.0.113.0/24")

ipaddress.ip_address("203.0.113.42") in net # True

Testing and Verification

A checklist worth running against any pool before committing.

Analyse the list before sending any requests. Subnet count, ASN count, geographic spread, concentration distribution. This tells you the pool's structural quality independently of any target.

Check a sample against blocklists. Public spam and abuse reputation feeds. Pre-flagged addresses are worth knowing about on day one.

Verify classification. Sample the pool and confirm org and asn match the product description.

Test against your real target, per address. Record which addresses succeed and which fail, and keep the mapping.

Analyse failure clustering. Do failures group by /24? By ASN? Randomly? Those three patterns mean range blocking, ASN blocking, and individual reputation respectively, and they have different remedies.

Re-test after a week. Tells you whether the provider is cycling addresses or letting the pool decay.

The failure-clustering analysis is the one that produces genuine insight and the one almost nobody runs. It's a few lines of code and it turns "the proxies stopped working" into a specific, actionable diagnosis.

A Worked Pool Evaluation

What a proper evaluation looks like end to end, using a hypothetical list of two thousand datacenter addresses.

Step one — structural analysis, before any requests.

cut -d: -f1 pool.txt | cut -d. -f1-3 | sort -u | wc -l

Result: 47

Two thousand addresses across forty-seven /24 blocks. That's an average of about forty-three addresses per block, and it means your effective independence against range-level blocking is roughly forty-seven, not two thousand. Not disastrous, not excellent.

Step two — concentration check.

Result: 256, 256, 256, 198, 145 ...

Three blocks are fully populated at 256 addresses each. That's 768 addresses — over a third of the pool — sitting in three blocking decisions. Worth knowing.

Step three — ASN diversity.

Sample fifty addresses, look up the announcing organisation, count distinct results. If forty-seven subnets resolve to three ASNs, your real independence is three. This is the check that most often changes an assessment.

Step four — reputation sample.

Check a sample against public blocklists. A small percentage flagged is normal; a large percentage suggests recycled space with history.

Step five — target testing, per address.

Run every address against your primary target once, record success or failure with the status code. This produces the number that actually matters: what fraction of the pool is usable for your work.

Step six — failure clustering.

Group the failures by /24 and by ASN. Three patterns and three meanings:

Clustered by subnet — range-level blocking. Your effective pool is much smaller than it appears.
Clustered by ASN — wholesale organisational blocking. Worse, and not fixable within that provider.
Scattered randomly — individual reputation contamination. Most tolerable, most recoverable, and the pattern you want to see.

Step seven — repeat after a week.

Tells you whether the provider actively cycles burned space or lets the pool decay. This is a genuine quality differentiator and it's invisible from a single measurement.

The whole exercise takes an afternoon and produces a defensible purchasing decision. Compare that against buying on headline address count, which is how most of these decisions actually get made.

Defending Against Range-Level Blocking

Given that blocking happens at block level, some practical defences.

Prioritise diversity over count when buying. Five hundred addresses across two hundred subnets beats five thousand across twelve, for most purposes and against most targets.

Track health per (address, target) pair, and per (subnet, target) pair. When a subnet starts failing on a site, stop drawing from it for that site rather than working through every address in it individually.

Make proxy selection subnet-aware. If a /24 has recently failed on this target, prefer an address from a different block. Every request through a range-blocked subnet is wasted.

Spread traffic evenly across blocks. Concentrating on a few subnets accelerates the blocking decision you're trying to avoid.

Use multiple providers for critical work. Different providers hold different address space. Concentration risk exists at the vendor level as well as the subnet level.

Escalate classification rather than adding addresses. If a target is blocking your hosting ranges wholesale, more hosting addresses from more subnets won't help. The remedy is a different classification, not more of the same.

Keep circuit breakers per target. When a domain's failure rate spikes, stop and investigate rather than burning addresses across every block you own trying to push through.

Common Mistakes

Judging a pool by address count. The number that predicts performance is distinct subnets and distinct ASNs, not total addresses. A pool can advertise fifty thousand addresses and offer twenty meaningful chances.

Assuming a fresh allocation is a clean allocation. Recycled IPv4 space carries history. New to you is not new to the internet, and pre-flagged addresses are common enough to check for as a matter of routine.

Buying IPv6 to save money without testing target support. If the target has no AAAA record you cannot reach it, and if it does, IPv6 origin is frequently weighted as higher risk. The savings evaporate against a success rate of zero.

Interpreting range-level blocking as provider failure. A pool failing wholesale on one site while working everywhere else is one blocking decision, not a broken service. The remedy is diversity, not a support ticket.

Adding more addresses from the same ASN to fix a classification block. If a target refuses hosting ranges, more hosting addresses don't help regardless of how many subnets they span. The remedy is a different classification.

Ignoring reverse DNS and ASN lookups. Two free commands that tell you what a target's automated systems will see, and almost nobody runs them before buying.

Treating "class C diversity" as a technical specification. It's marketing language for /24 diversity, using terminology that's been obsolete for three decades. Ask for the actual subnet and ASN distribution.

Concentrating traffic on a subset of blocks. Even a diverse pool loses its advantage if your selection logic keeps drawing from the same few subnets. Make selection subnet-aware and spread evenly.

Not re-testing over time. Pools change. A structural analysis from three months ago describes a pool that may no longer exist.

Frequently Asked Questions

Are all proxies IPv4?

Almost all. IPv6 proxies exist and are much cheaper, but limited target support and higher suspicion make them a niche choice.

Why are IPv4 proxies more expensive than IPv6?

IPv4 addresses are exhausted and traded on a secondary market at real cost. IPv6 addresses are effectively free. The price difference reflects genuine scarcity.

Should I buy IPv6 proxies to save money?

Only if you've confirmed your targets support IPv6, your tooling handles it, and the targets are permissive. Otherwise the savings are illusory because the proxies won't reach or won't be accepted.

What does /24 mean?

A block of 256 consecutive IPv4 addresses sharing the first three octets. It's the most common unit of range-level blocking, which is why subnet diversity matters so much.

Why did my whole pool stop working on one site?

Almost certainly range-level or ASN-level blocking. Check whether failures cluster by subnet or by announcing organisation. That's one decision by the target, not a provider fault.

How much subnet diversity do I need?

More than most pools offer. As a rough posture, treat your effective pool size as the number of distinct /24 blocks rather than the number of addresses, and buy accordingly.

What's an ASN and why should I care?

The organisation announcing an address block. It determines classification — hosting versus residential — and it's the largest unit sites block at. ASN diversity matters more than subnet diversity.

Do IPv4 addresses have history?

Yes, and recycled space frequently arrives with reputation baggage. Check a sample against blocklists before building on a new allocation.

Can I check subnet diversity before buying?

Sometimes. Providers offering a trial or a sample list let you analyse it directly. Where no list is available in advance, ask for the ASN count and the number of distinct /24 blocks — a provider confident in their diversity will answer, and reluctance is itself informative.

Does subnet diversity matter for residential proxies?

Much less. Rotating residential draws from millions of consumer addresses spread across thousands of ISPs, so concentration isn't the risk it is with datacenter allocations. The check matters most for datacenter, dedicated, and ISP pools.

Is IPv4 going away?

Not in any timeframe relevant to a proxy purchase. Adoption of IPv6 has been slow for decades and IPv4 remains the practical default for essentially all commercial proxy work.

Where to Get IPv4 Proxies

If you need IPv4 addresses with the subnet and ASN diversity that makes a pool resilient to range-level blocking, ProxyScrape's IPv4 proxies cover the standard addressing that essentially every target and every tool expects, available across their datacenter and residential product lines with both HTTP(S) and SOCKS5 support. Since the addressing scheme is rarely the interesting variable, the more consequential decision is which classification sits behind it — and whichever you choose, run the subnet and ASN diversity check on the list before you build anything on it.

→ Compare IPv4 proxy options and check the pool's subnet diversity

IPv4 is the least glamorous specification in any proxy purchase and one of the most quietly informative, because address structure explains most of the failures people find mysterious. Pools fail in blocks because blocking happens in blocks. Prices reflect a genuinely exhausted resource rather than vendor margin. And the single most useful thing you can do before buying is to count distinct subnets and ASNs rather than addresses — a five-line shell command that tells you more about how a pool will actually perform than any specification sheet will.