Fame-ladder cash-gate sweep: fresh + paying + self-hostable is a near-empty intersection (banked)

Date: 2026-06-23 Context: After GitLab CE (full-surface) + Mattermost CORE both swept clean at fuzzer-scale, operator directive = go DOWN the fame ladder to find a self-hostable multi-tenant app on a PAYING program that is NOT a top-audited blue-chip. CASH-GATE FIRST before spending compute.

The sweep (6 candidates, cash-gate = active + PAYING + self-hosted testing in ROE)

Target	Pays?	Self-host test	Verdict
Rocket.Chat	NO - VDP only (WhiteHat HoF)	yes (own copy)	credit-only
Chatwoot	NO formal program (discretionary)	yes (required)	credit-only
Zammad	no program found	-	none
Ghost	no dedicated paid program found	-	none
Sentry	PARTIAL (Cookie Bounty $100 + private/invite main); self-host scope unclear	unclear	weak
Discourse	YES - H1 bounty table; source explicitly in-scope (100% OSS)	own instance safe (not their infra)	PAYS but mature

The finding (strategic, reusable)

The intersection {fresh/less-audited} AND {pays cash} AND {self-hostable} is NEARLY EMPTY: - The genuinely-fresh self-hostable apps run VDP / hall-of-fame / discretionary-thanks, NOT cash. - The ones that pay cash are the MATURE blue-chips (GitLab, Mattermost, Discourse, Sentry) - same profile that already sweeps clean under a full-surface differential. - So cash-gating FORCES you UP the audit ladder, which is exactly where IDOR is already swept. This is the IDOR analogue of the audited-web3-frontier saturation: the paying frontier is mined.

Doctrine (how to use this next time - do NOT re-run this sweep blindly)

For a self-hostable-IDOR cash hunt, the binding constraint is the CASH-GATE, not surface support. Cash-gate a candidate list FIRST (cheap web check) before ANY compute. Most fresh OSS = credit-only.
When the fresh tier is all credit-only and the payers are mature-likely-clean, STOP and re-aim - do not grind a probable 3rd clean blue-chip (operator: "rather re-aim than burn cycles").
Re-aim vectors when this wall is hit: - Different payer veins: YesWeHack / Intigriti self-hostable payers; freshly-LAUNCHED paying programs (newly-funded SaaS that self-hosts + pays before their code is audited) - these are the real "fresh+paying" needle, found by watching program launches, not by walking famous OSS names. - Pivot bug-class: on the mature payers the fuzzer reaches, pure cross-tenant READ-IDOR is swept; the unmined classes there are write-BAC chains, privilege-boundary bypass, and 2nd-order IDOR (id harvested mid-flow), which the differential can target with deeper seeding. - Credit-only-but-fresh (Rocket.Chat/Chatwoot) still SHARPEN the engine + bank patterns; run them only when the goal is engine-hardening, label them credit not cash.

Status

Readout sent to operator via bz-tg (A: run Discourse anyway / B: re-aim payer vein / C: pivot class). No compute spent on Discourse pending the call. FP-allowlist (differ.triage) shipped + validated. NO auto-submit. Engine + adapter set (GitLab full-surface, Mattermost core) compound regardless.