Sleeper Pool

In plain English

The most important code in open source is often the most boring: it just works, year after year, and quietly powers things. Everyone else's scheme — sponsors, bounties, royalties — rewards activity, so this code earns nothing. The Sleeper Pool rewards stability. If you wrote something five years ago that still works and is still imported, you get paid.

What it is

Every existing OSS reward scheme — sponsorships, bounties, royalty streams, contribution rewards — measures activity. Commits per week. PRs per quarter. Stars per month.

This is backwards for the code that matters most. The most load-bearing OSS in the world is often stable: left-pad, is-odd, OpenSSL, libcurl, zlib. The author wrote it right years ago and hasn't touched it because nothing is broken. Under every other scheme, they earn nothing.

The Sleeper Pool fixes this. It pays repos for being stable while still being imported.

How it works

Every linked repo contributes a tiny share of its incoming royalty stream into a shared Sleeper Pool. The pool is distributed every epoch to repos that meet all of:

1. Still imported. Has at least N active dependents in the epoch.
2. Dormant. No commits to default branch in the trailing 180 days.
3. No critical incident. No claims paid against it in the trailing 365 days.
4. License-clean. Permissive license (the pool doesn't reward repos that block use).

Payouts per qualifying repo:

sleeper_payout(repo) = pool_balance
                    × usage_share(repo)
                    × stability_bonus
                    × cap_per_repo

Where stability_bonus grows with consecutive dormant epochs (the longer a repo has been stable while still used, the bigger the payout per epoch).

Concrete example

Why this is a hard problem solved well

The sleeper pool is hard to ship because it has obvious failure modes:

1. Why would anyone fund it? Active repos seem to subsidize dormant ones.
2. Won't people game it by abandoning their repo? Goosing the dormancy clock.
3. What about dormant-and-buggy code? Stability ≠ goodness.

Our answers:

1. Funding the pool is in active repos' interest — they all depend on something dormant somewhere. The pool is insurance against your dependency tree quietly rotting.
2. Gaming is detected. Stability is conditioned on still-imported (you can't game your way to revenue by being abandoned), no-incident (a buggy dormant repo gets nothing), and the dormancy clock resets if you ship a hostile commit (a license flip, a malicious payload).
3. Bug-class dormancy is excluded. Any successful insurance claim against the repo voids its sleeper eligibility for a year.

Pool funding

The pool is funded by a small per-stream slice (default 0.5%) of every royalty stream that flows through the protocol. Governance can adjust this, with strict bounds.

Total pool inflow scales with total network MRR. As more streams flow, more is set aside for the dormant-but-critical code that nobody is thinking about.

Opt-in / opt-out

Repos can opt out of receiving sleeper payouts (and stop contributing the 0.5% slice on their outbound streams). Default is in.

[sleeper]
participate = true        # contribute + earn

Gotchas

Related

• Royalty streams — the source of pool funding.
• Insurance — incidents that void sleeper eligibility.
• Governance — pool rate parameters are voted.