# Proof of Resilience

Discussion: [Hacker News thread](https://news.ycombinator.com/item?id=47590966) (context: Axios NPM supply chain compromise)

## The Problem
Open-source software runs the world, but the people who built it are not compensated well enough for their work. Most funding models today rely on popularity signals like downloads, stars, dependency counts to figure out where the money should go.

Today, AI agents can generate thousands of packages, fake download traffic, build synthetic dependency graphs, and manufacture stars. Popularity is now trivially gameable. The best marketers are rewarded, not the most resilient software.

This is a security problem. If automated systems pick critical dependencies based on popularity, a well-executed fake-popularity campaign puts attacker-controlled code at the base of the supply chain.

## The idea
**What if you only measure things that can't be faked?**

Proof of Resilience proposes scoring open-source projects based on *verifiable security outcomes*. How resilient is the code to random input, how deterministic is the build process, how quickly are security patches appplied?

If you pick the right metrics, gaming them is the same thing as being good. An agent that optimizes for "don't crash under fuzzing" will write code that doesn't crash from unexpected input.

The protocol is not just resilient to AI-generated software — it is optimized for it. Continuous fuzzing, automated remediation, deterministic builds: these are things agents do naturally. A system that rewards verifiable outcomes over human reputation is native to the environment we're entering, not a patch on the old one.

This model targets infrastructure-layer OSS where correctness and reliability are measurable — security libraries, compilers, networking stacks, data stores. It is less suited for UX-heavy applications or niche scripts where "quality" is subjective.

## Four metrics, one formula

Each project's reward:

$$
R(p) = F(p) \cdot D(p) \cdot (1 - S(p)) \cdot V(p)
$$

These multiply together on purpose — failing any one of them can zero out the whole reward.

### F — Fuzzing resilience (0 to 1)

An OSS-Fuzz-style network throws adversarial inputs at your code around the clock. Your score is compute-hours survived without a crash, panic, or memory fault. The maintainer cannot influence the input distribution or the reporting process — the fuzzing infrastructure generates unpredictable inputs across an effectively infinite search space, runs on external compute, and produces cryptographically signed attestations of the results. Surviving fuzzing is not a claim; it is an externally generated, verifiable observation.

This is the strongest metric in the system: anchored in physics (compute actually spent) and cryptography (signed results). Its main limitation is coverage — fuzzing finds crash bugs and memory faults well, but doesn't catch all classes of logical errors. That's an honest boundary, not a fatal one.

### D — Build determinism (0 or 1)

Independent nodes build your release from source in hermetic environments. If they all get the same binary, D = 1. If not, D = 0 and you earn nothing. This is the SolarWinds / XZ Utils defense — it proves the binary actually matches the source.

### S — Downstream stability (0 to 1)

When you ship an update, tools like Dependabot and Renovate push it to downstream projects automatically. The protocol watches whether those CI pipelines pass or break. Your revert ratio, weighted by the reputation and stake of downstream consumers, becomes S. Bot accounts with no stake carry near-zero weight — you can't grief a competitor with a swarm of fake repos.

This is the most important metric conceptually — it directly penalizes negative externalities. Breaking downstream users costs you money. Most OSS incentive systems ignore this entirely.

It is also the weakest metric epistemically. F and D are anchored in physics and cryptography: compute was spent, binaries either match or they don't. S is anchored in economics and graph structure: stake-weighted reputation, CI pass rates, revert ratios. These are harder to game than raw popularity, but not as hard as surviving fuzzing. The system acknowledges this asymmetry by design — S modulates rewards, but F and D are the load-bearing walls.

### V — Vulnerability remediation speed (0 to 1)

When a security patch PR lands on your project, the clock starts. It stops when a patched release ships *and that release passes fuzzing and build verification*. Fast, verified fixes score high. Sitting on open CVEs decays your score toward zero. No open vulnerabilities? V defaults to 1 — stable software isn't penalized.

## Example: how a score moves

A widely-used TLS library ships a minor release. Downstream CI pipelines pick it up automatically. Two enterprise consumers report test failures; their stake-weighted revert ratio pushes $S(p)$ from 0.05 to 0.38 — the project's reward drops by a third overnight. The maintainer rolls back, patches, and re-releases. CI passes across the board, S falls back to 0.04, and the next epoch's reward recovers. The system didn't need a committee, a vote, or a CVE. It just measured what happened.

Contrast: a crypto-primitive library survives 12,000 compute-hours of fuzzing without a single fault, ships deterministic builds every release, and has never triggered a downstream revert. F ≈ 1, D = 1, S ≈ 0, V = 1. It captures disproportionate rewards — not because it's popular, but because it's provably reliable.

## Architecture (three layers)

1. **Signal layer** — Cryptographic artifacts from existing tooling (Sigstore, SLSA provenance, GitHub webhooks, PR timestamps). Nothing self-reported.
2. **Oracle layer** — Validators verify signatures, compute scores, and stake capital on their attestations. Lie and get slashed. Rewards sit in escrow for one epoch so honest validators can challenge.
3. **Allocation layer** — A smart contract runs the formula each epoch and distributes the pool. No committee, no votes, no per-project decisions.

## How it handles attacks

| Attack | What they try | Why it doesn't work |
|---|---|---|
| **Fake dependency griefing** | Botnet repos revert a competitor's updates to spike their revert ratio | Zero-stake bots carry near-zero weight in $S(p)$ |
| **Blind merge exploit** | Instantly merge security patches to game the $V(p)$ clock | Clock doesn't stop until the release passes fuzzing AND build verification |
| **Collusion rings** | Mutual dependencies among co-conspirators to inflate reputation | Graph analysis flags isolated clusters; F and D can't be faked either way |

## Case study: Axios NPM compromise (March 2026)

Malicious versions of the axios package were published to NPM containing a remote access trojan. Under Proof of Resilience:

• **D = 0 immediately** — the compromised publish wouldn't match a deterministic build from the source repo. Funding stops.
• **F degrades** — injected network calls and file system access would trigger anomalies under continuous fuzzing.
• **V measures response** — the clock starts on remediation. Fast patched release = score recovery.

Current mitigations (min-release-age, ignore-scripts) are downstream defenses — every consumer independently protecting themselves. PoR creates upstream incentives: maintainers who ship deterministic, fuzz-surviving builds are structurally harder to compromise.

## Where the money comes from

- **Enterprise sponsorships** — Companies pay into the pool and get back verifiable quality scores that replace their internal vetting. Enterprises are not paying for goodwill — they are outsourcing due diligence to a system that is cheaper, more objective, and continuously updated than internal security review.
- **Foundation grants** — Cybersecurity agencies and tech foundations provide baseline funding.
- **Optional bootstrap mechanism** — Token emissions on a declining schedule can fund validators and fuzzing compute early on, if needed. The core model doesn't depend on this.

Staking puts skin in the game at every level: maintainers can stake on their packages (bigger rewards, but slashed on failure), enterprises stake alongside packages they approve, validators stake on every attestation.

## The flywheel

High scores attract rewards. Rewards attract talent. Talent produces better code. Better code earns enterprise trust. Trust grows sponsorship. Sponsorship grows the pool.

Start small — a handful of high-visibility infrastructure packages where security matters most — and let the track record build the case for expanding.

## Open questions and next steps

- **Formal verification** — Can we go beyond "survived empirical attack" to "provably correct by construction"? As AI-assisted formal verification matures, these proofs could feed into the oracle alongside fuzzing results.
- **Cross-language fuzzing** — Right now fuzzing works best for C/C++, Rust, Go, Python. The protocol needs to cover the full language ecosystem.
- **Richer reputation** — The current model bootstraps reputation from economic stake. Over time, audit history, participation duration, and inter-validator agreement should factor in so reputation can't be bought outright.

The formula is the stable foundation. The oracle network is the surface that grows.