What Is IPFS Provide Sweep? How Kubo Announces Many CIDs

IPFS Provide Sweep is how Kubo announces large sets of CIDs to the DHT by grouping them into keyspace regions and looking up each region once, not every CID. It was opt-in in Kubo 0.38 and became the default in 0.39, so a self-hosted node on a current version already runs it.

TL;DR:

• Provide Sweep is a Kubo provider that batches CIDs by DHT keyspace region instead of running one lookup per CID
• It arrived as an experimental option in Kubo 0.38 (October 2025) and became the default in Kubo 0.39 (November 2025)
• The legacy provider needs a 10 to 20 second lookup per CID, so it tops out around 5,000 to 10,000 CIDs per 22-hour cycle
• For 100,000 CIDs, the Kubo config docs report about 97% fewer lookups
• You can check it with ipfs provide stat and turn it off with ipfs config --json Provide.DHT.SweepEnabled false

What Is IPFS Provide Sweep?

Providing is how a node tells the network "I have this CID". The Amino DHT stores that claim as a provider record on the 20 peers closest to the CID. Each record expires after 48 hours unless the node renews it, and Kubo renews every record every 22 hours by default, which is the Provide.DHT.Interval setting.

Provide Sweep changes how Kubo schedules that renewal work without changing what a provider record is or how long it lives. The provider records article explains the expiry and renewal cycle, and this post covers the part that decides whether a big node can finish its cycle.

Why Did the Old Provider Hit a Ceiling?

The legacy provider handled CIDs one at a time. Each needed its own DHT lookup to find the 20 closest peers, which the Kubo config docs put at 10 to 20 seconds per CID.

Shipyard, the team behind the feature, works out the limit at 15 seconds per lookup: 22 hours is 79,200 seconds, which allows 5,280 CIDs. The config docs say the legacy provider typically handles fewer than 10,000 CIDs over 22 hours.

Past that point the cycle cannot finish, so the next cycle is skipped. The records that were not renewed expire after 48 hours, which leaves peers unable to find your content through the DHT.

The older workaround was the Accelerated DHT client, which crawls the whole DHT every hour to keep a local map of peers. It removes the lookups, but Shipyard describes it as resource hungry and warns that the crawls can crash consumer routers or trigger ISP throttling.

How Does Provide Sweep Work?

CIDs that sit close together in the keyspace share the same closest peers, which is what Provide Sweep uses. Kubo splits the keyspace into regions by prefix, sizes each region to hold at least 20 peers, and schedules the regions evenly across the 22-hour interval.

When a region comes due, Kubo discovers its peers once and sends every provider record for CIDs in that region in one batch. The number of lookups then depends on the size of the network instead of the number of CIDs. The config docs give about 3,000 lookups when there are roughly 10,000 DHT servers, however many CIDs you provide.

Three details matter once you run a node with real traffic:

• Fresh CIDs go into a queue that is also grouped by region, so new content does not wait behind one lookup per CID
• The cycle state is saved, so a restart resumes where it stopped and queues any CIDs that missed their interval
• Kubo 0.39 also announces root CIDs right away after ipfs add, while the sweep handles the remaining blocks over time

Shipyard tested 100,000 CIDs on the live DHT with a 3-hour interval and minimal concurrency. From that test it estimates about 132,000 lookup requests over a standard 22-hour interval for sweep, against about 1.87 million for the Accelerated client. Those figures come from Shipyard's own experiment, not from my machine.

From Experimental to Default

If you upgraded from 0.38 with the setting left alone, you moved to the sweep provider automatically, and an explicit false keeps you on the legacy one.

Checking and Tuning It

The docs show these commands, but this machine has no IPFS binary, so I did not run them and the output below comes from Shipyard's post.

# Quick summary of the provide system
ipfs provide stat

# Live view with every section
watch ipfs provide stat --all --compact

# Go back to the legacy provider, then restart the node
ipfs config --json Provide.DHT.SweepEnabled false

Shipyard's example output from a node with 67 million CIDs includes lines such as these:

CIDs scheduled: 67M (67,704,411)
Regions scheduled: 260
Provide queue: 0 CIDs, 0 regions
Reprovide interval: 22h0m0s

A few settings decide how it behaves on your node, so check them before you scale up:

• Provide.Strategy picks which CIDs get announced, and the default is all
• Provide.DHT.MaxWorkers caps concurrent provide operations, and the docs advise raising it if you provide millions of CIDs
• Provide.DHT.Interval is the cycle length, 22 hours by default

Shipyard recommends turning the Accelerated client off once sweep is on, and not using it on home networks. The Kubo 0.39 changelog also warns that sweep may not reach its full efficiency while the Accelerated client is enabled.

Where a Pinning Service Fits

Provider records are the job of whoever runs the IPFS nodes, so if you pin through a service, that upkeep is the service's work. The AIOZ Pin API and gateway docs do not describe which node software or provider settings it uses.

So Provide Sweep matters most if you run Kubo yourself, for example next to a pinning service or as a source for pin by CID. The Optimistic Provide article covers the other 0.39 speedup, which makes a single announcement faster, and if a file you published will not load, start with the gateway diagnostic order.

Frequently Asked Questions

What is Provide Sweep in Kubo and what problem does it solve?

It is the Kubo provider that announces your CIDs to the Amino DHT by sweeping through keyspace regions and sending records in batches, not one lookup per CID.

Is Provide Sweep turned on by default in current Kubo versions?

Yes, since Kubo 0.39, and the setting is Provide.DHT.SweepEnabled with a default of true.

How many CIDs could the legacy Kubo provider handle in one cycle?

The config docs say fewer than 10,000 per 22-hour cycle, and Shipyard's 15-second estimate gives 5,280.

Does Provide Sweep replace the Accelerated DHT client in Kubo?

It covers the same need with steadier resource use, and the two can run together, but Shipyard recommends that you disable the Accelerated client.

Is Provide Sweep the same thing as Optimistic Provide?

No. Sweep schedules and batches announcements, and the 0.39 changelog describes the fast root announcement as complementary to it.

Does announcing a CID make the file load on a gateway?

A provider record only lets other peers find you, and your node still has to be reachable and hold the blocks.

Related Reading

• Why IPFS Provider Records Expire and Get Renewed - the 48-hour expiry and 22-hour renewal behind sweep
• Optimistic Provide: How IPFS Made Publishing 10x Faster - the other provide speedup in Kubo 0.39
• How IPFS Finds and Retrieves Files: DHT and Bitswap - how a lookup uses those provider records
• Delegated Routing: How Light Clients Skip Running a DHT - finding providers without a DHT

References

• Kubo changelog v0.38
• Kubo changelog v0.39
• Kubo changelog v0.40
• Kubo changelog v0.41
• Kubo changelog v0.42
• Kubo configuration reference: Provide
• Kubo docs: Provide stats
• Shipyard: Provide Sweep, Solving the DHT Bottleneck for Self-Hosting IPFS at Scale