● Seedforger · science annex

No free ratio.

We built the most careful ratio client we knew how to build — then proved, inside its own repository, that even a perfect client optimises the wrong variable. This is that story, in two short papers and five figures.

Read the papers → View the code

≈1.00detector AUC, healthy swarm

1.25×the most you can inflate real work

0credit for zero real upload

172tests guarding every number

How it started

A simple question with an uncomfortable answer

The question was blunt: what actually protects a private tracker? Not the folklore, not the fear of getting caught — the real machinery. It's a fair thing to want to know when you've spent a long time building a client that reports whatever upload figure you tell it to.

The honest answer turned out to be more interesting than a list of tricks. A mature tracker doesn't trust your number. It reconciles it — against physics, against the swarm's books, against what its own peers actually received. And once you write that reconciliation down as maths, something falls out that no amount of client polish can undo.

So instead of a cat-and-mouse manual, we did the opposite: we turned Seedforger's own project into an object of study, and shipped the proof that the client side is a game you can't win — right next to the client.

You can fake how fast you claim to be. You cannot fake that nobody received it.

Act I · Paper 1

Three ways a lie stops adding up

Everything the tracker needs, it already has. Three checks do most of the work — and none of them requires trusting your number.

01 — Physics

Plausibility

You can't upload faster than your uplink. A claim that implies impossible speed refutes itself.

02 — Books

Mass balance

Every byte someone downloaded, someone uploaded. Fabricated upload has no matching download — the swarm's books stop balancing.

03 — Witnesses

Corroboration

Trackers run their own peers. Whatever you really upload, some of them receive. Claim a lot they saw none of, and the gap is the tell.

The three invariants across a healthy swarm, naive cheaters and careful cheaters — In a healthy swarm all three residuals are flat. **Naive** cheaters trip everything, including physics. The interesting column is the last: **careful** cheaters beat the physics check completely — and it doesn't matter, because they can't put bytes in someone else's inbox.

Act II · the estimator

It's not a threshold. It's an estimator.

The naive build — "flag anyone above a cutoff" — dies on real, dirty data: NAT, buggy clients, asymmetric seedboxes. The right object is a robust estimate of what normal looks like, and its breakdown point — the fraction of colluding liars needed to corrupt it — is the number that matters.

Mean vs median vs Huber estimate as a colluding fraction grows — With 40% of the swarm colluding on a far-away value, the arithmetic **mean** is dragged from 1.0 to ~5.0, while the **Huber** M-estimator holds at ~1.38 and the median at ~1.12. Breakdown point 0 versus ~½.

Score every peer against that robust baseline, sweep the threshold, and you get a ROC curve. In a healthy deployment the separation is essentially complete.

ROC of the detector, healthy deployment vs thin-coverage tiny swarm — **AUC ≈ 1.00** against *careful* cheaters who seed for real and inflate only modestly. A peer that declares several times what any monitor received has nowhere to hide.

Act III · the honest part

Where it breaks — and we say so

A detector paper that only reports its wins is marketing. The corroboration measurement is a sample, so its noise grows when there's little to sample. Two things make that bite: almost no monitoring peers, and a brand-new torrent with barely any volume yet.

Detection AUC vs coverage, established vs fresh torrent — On an established torrent the detector shrugs off thin coverage (AUC ~0.99 even at 2%). On a **fresh** torrent with thin coverage it sags to **~0.82** — still well above a coin flip, but visibly degraded. That's a property of sampling, not a leak of anyone's secret rules.

Act IV · Paper 2 · the twist

The number you're chasing is one you can't see

Here's the uncomfortable structure of a well-run tracker: the score it credits you is computed partly from what its monitors witnessed — a signal you can neither read nor forge, because forging it would mean actually delivering the bytes. Which is just… seeding.

Do some genuine work w, then inflate. The tracker witnesses a fraction of your real work and flags you when the gap is too big. Work the arithmetic and a wall appears: the most you can declare without a flag is w ⁄ (1 − τ) — a fixed multiple of real work. Nothing on the client moves it.

Zero real upload earns zero credit that survives. Not “a little.” Zero.

Max credited upload capped at a multiple of real work; a blind client lands exactly on the ceiling — At tolerance τ = 0.2 the cap is **1.25×** your real work. The red dots are a client searching as hard as it can, *blind* to the corroboration signal — every one lands exactly on the ceiling the tracker set. A better client doesn't beat it; it reproduces it.

This is the shape of an incentive-compatible mechanism: telling the truth is optimal not by anyone's goodwill, but by the geometry of who can see what. The tracker didn't out-code the client. It arranged the information so the client is grading its own homework, blind.

The coda

So we optimised the right variable instead

The engineering conclusion isn't despair — it's redirection. The only lever that moves the ceiling is w: real upload, actually served. Which is why Seedforger's most valuable component is the one that isn't about faking anything at all — the real, hash-verified peer-wire engine that genuinely seeds.

Reproduce every number. The whole story is a runnable, deterministic model — no hand-waving. The figures on this page are regenerated from the code, and 172 tests pin the science with tolerances.

# from the repository root
dotnet run --project src/Seedforger.Integrity.Figures -c Release -- docs/papers/figures
dotnet test  tests/Seedforger.Tests

The two papers are defensive and theoretical. They describe how a tracker protects itself and prove a limit on the client side — nothing here is an evasion recipe. The point is exactly the opposite: the durable engineering lives on the honest-seeding side.