Technical concept

A security exchange: incentives, verification, disclosure, and installed-base protection

Concept v0.7 · September 17, 2026 · companion to A security exchange that rewards disclosure.

This is the closer, more technical description promised in the main post. It is a working concept, not a finished system: none of the mechanisms below is implemented or empirically validated, and each is stated as something to test.

I'm developing a security exchange designed to make verified disclosure more attractive than exploitation, while giving vendors stronger incentives to protect users. The premise is that AI can accelerate both exploitation and remediation; the opportunity is to align the money, the evidence, and the decision rights around that faster cycle. The ambition is broad, but the first implementation would cover a bounded set of verifiable failures in participating systems.

Who participates — and why

How the incentives connect

Before testing, participants commit to scope, evidence requirements, reward rules, funding limits, and disclosure terms. An authorized agent attempts to reproduce the claimed failure on a designated deployed system; independent verification establishes whether it qualifies. A timestamped submission protects priority within the exchange, and a qualifying finding creates a payment entitlement against reserved funds.

Payment need not wait for public disclosure: severe flaws can receive a bounded, independently governed remediation window, with timely protective guidance and staged technical publication. Remediation updates the record without erasing earned payment. Technical validity and conduct eligibility are separate — any conditional award portion, attribution standard, release deadline, and independent appeal are agreed in advance. A vendor allegation cannot unilaterally erase an earned entitlement.

An exploit is copyable, so buying disclosure cannot prove exclusivity or prevent a seller from collecting both abuse proceeds and a bounty. If those strategies cannot be distinguished and deterred with collectible consequences, a higher bounty alone cannot solve the problem. The model makes that failure mode explicit; protective intake for already-compromised systems stays separate from discovery-bounty eligibility.

The leading hypothesis is that a ready market for protection shrinks the remaining attack/resale opportunity, while credible competition for a capped discovery award makes delay costly. These effects must be measured; fast patch availability alone establishes neither.

What changes relative to centralized bounty platforms

HackerOne's published terms place program scope and reward amounts with customers, contemplate advance reward funding unless otherwise agreed, and recognize customer validation as a potential source of payment delay; they also provide managed programs and some protections for outstanding rewards. Prefunding is therefore not the innovation here. (HackerOne customer terms, §§5–6.)

The comparison hypothesis is that concentrating decisions around the paying vendor and platform can leave opportunities to benefit from delay, selective disclosure, disputed classification, or influence over a gatekeeper. These are incentive risks to validate — not allegations about any platform's conduct. The proposed changes reduce those potential rewards:

Smart contracts would enforce reserved funding and settlement rules, while independent evidence and appeals still govern off-chain facts. The DAO is a design warning for that settlement layer: I am evaluating a deliberately restricted, possibly non-Turing-complete language or VM with bounded execution and auditable fund-conservation rules. Restricted computation does not eliminate custody, oracle, or governance risk — it just narrows the blast radius.

The first proof point

The first proof point is a bounded paid pilot: one ecosystem, a narrow failure class, independent verifiers, and real participant choices. Acceptance requires a measurable preference for clean disclosure over sequential monetization, reliable attribution with low false accusations, sustainable funded payouts, verified protection, and paid renewal. The ramp expands only after independent replication.

The initial commercial hypothesis is to aggregate a shared software exposure through a vendor, MSP, or insurer-linked sponsor that can fund and deploy protection across many customers. A small pilot can establish operating costs and verified protection; demonstrating lower insurance losses would require a larger matched cohort.

A longer working paper and a market-calibration supplement track the assumptions, objections, and funding math behind all of this. They're rough, and available on request. If you want to help build the thing itself, the main post has the call for collaborators.
Back to the essay