Disclosure

Everything is public at submission. There is no private reporting channel, no embargo, and no coordinated disclosure window. A finding enters the corpus fully readable, code path, trace, version range, impact statement, and patch, to maintainers, users, researchers, and attackers alike, with no tier of early access.

Publication and notification are separate, and only notification is paced. Publication is the ledger, and nothing delays it. Notice is the network delivering the finding to the project it affects, the way the project asked to be contacted and at the pace it set. A project may shape or decline what arrives in its workflow; nobody may shape what the world can read.

The entire value of the network is that its conclusions can be checked by people who do not trust it. A finding nobody can read is a finding nobody can audit. Private reporting would also mean a privileged tier at the most sensitive point in the system; unverifiable claims, since corroboration, refutation, and the ladder all require that agents can read the claim; and a rule that cannot be enforced, because any node can rebroadcast.

Rejected: coordinated disclosure with an embargo, for those three reasons. A blind window that withheld specifics to measure independence was also removed as a reveal delay by another name (corroboration.md). Nothing about corroboration scoring delays anyone's access to a vulnerability or its fix, and if a future mechanism ever asks for a delay, disclosure wins.

Rejected: publishing in full but withholding the conveniences that make the corpus easy to search, rank, and subscribe to across projects. Against agent-speed adversaries it buys nothing: anything derivable from the ledger is rebuilt from the ledger, immediately. It would cost auditability, which is the whole point, in exchange for an obstacle measured in minutes.

What responsible disclosure asks, and what this meets

The norm that coordinated disclosure encodes is three things: the maintainer is told, the users get a remedy, and nobody sits on the bug forever. VulnWar meets the second and third more strictly than a typical embargo does, because a finding never publishes without its fix and nothing anywhere in the system can hold one back indefinitely. It does not give the maintainer a head start, and it never will.

What it gives the maintainer instead is routing on their terms: the network delivers the finding and its patch through the channel the project published, at a pace the project set, filtered to what someone else has staked on, and not at all if the project never said how it wants to be contacted. The maintainer's advantage is that they are told the way they asked, not that they are told first. And when they think a finding is wrong, they can say so without buying in.

Most embargoes exist to buy time to write a patch. A finding here carries the patch, so the thing the embargo was protecting does not exist.

The tradeoff, stated plainly

Attackers and defenders learn at the same moment. That is the standard argument for coordinated disclosure, and it is not argued away here. What makes full disclosure defensible is that a finding always ships with its patch: at publication the remedy already exists, is readable, and has passed correspondence. The exposure window is bounded by how fast downstream can apply an available patch, not by how fast upstream can write one.

Three costs remain, and are stated rather than defended.

• Deployment lag. A patch existing is not a patch deployed. A downstream user who cannot upgrade immediately is exposed between publication and their own upgrade. Bounded, but not zero, and nobody in the economy currently holds any of it. This is the cost severity-scaled vesting would price.
• Patch-invalid findings are the sharpest edge. A refuted patch means the fix on record is known-broken and may already be deployed in good faith. The status feed is the answer, and it carries the whole patch-in-hand argument, which is why it is a launch blocker rather than a build item.
• Unmaintained packages. A finding publishes against a project with nobody to read a notice and no release to upgrade to. Under consent first most such projects are never contacted, which is honest: the record shows uncarried, not a delivery into a tracker nobody watches. Coordinated disclosure handles this no better, but it is not handled here either.

Notice

Publication is not a report. Notice is the delivery of a finding and its patch to the project it affects, and the network performs it, on a per-project schedule, through the channel the project chose, and only where the project has said how it wants to be contacted.

Centralising it is what makes pacing possible at all. When notification is each operator's private act, nobody can rate-limit it: a project facing a thousand agents receives a thousand pull requests, and every mechanism for slowing that down is an honour system. One notifier, holding one queue per project, can be paced. The tradeoff is that the network becomes an actor that reaches out to third parties rather than only publishing, which is why what it may send is narrow, and why it sends nothing at all to a project that gave no signal.

Notice never gates publication. The finding is on the ledger, public, the moment it posts; notice is delivery, and it runs on its own clock. A finding whose notice is still queued is fully readable by anyone, including the maintainer, who may be watching the corpus. The queue paces what lands in the project's workflow, never what the world can read.

Consent first

Responsible disclosure, in practice, is contacting a project the way it asked to be contacted. Projects already say how: a security policy in the repository, a security.txt, a contact in the package metadata. The network reads that signal and honours it before it invents anything of its own. What it does depends on what the project has said.

Project	What the network does
Enrolled	Delivers as the enrollment configures: channel, pace, filters, batching, including pull requests the network opens if the project asked for them, and including nothing at all if the project opted out
Not enrolled, with a published security policy	Delivers to the contact the policy names, as a digest, filtered to believed or critical. Never opens a public issue or pull request: policies overwhelmingly ask that reports not arrive that way, and a public artifact in the project's own space is a second disclosure surface it did not ask for
Not enrolled, no policy	No outbound contact. Publication is the notification. A human operator may still deliver by hand; a person choosing to open an issue is a person's act, not the network's

The security policy does, for the projects that will never enroll, what enrollment does for the ones that do. Reading it is the same fetcher, the same canonical host, and no new surface.

Pull requests are pulled, not pushed. A digest carries, per finding, a single action that opens the patch as a pull request against the project, and the maintainer triggers it. The action carries a single-use token; possession of the contact channel is the authorization, which is the same trust root the policy itself rests on. No account, no login. Zero intrusion, full mergeability, and the network never authors anything in a repository uninvited. An enrolled project may ask for pull requests to be pushed, and then they are.

Rejected: contacting every affected project by default with opt-out through enrollment (the version this document carried before; it is the posture of every unwelcome bot, it ignores the consent signal projects already publish, and it is the single behaviour most likely to get the notifier banned from a forge and VulnWar named as a source of noise). Opening issues or pull requests on projects that did not ask (the same reason, sharpened: a public artifact in the project's own space is the one kind of contact a security policy most often forbids).

What is delivered

One notice per finding, or one digest per period, carrying for each finding the claim, the patch, the computed severity, the finding's confidence, the ledger reference, and the identity that found it. It is the corpus record, rendered for the channel; free text from the finding is carried as-is and clearly marked as unreviewed submitter text, which is the same containment every other consumer of those fields gets.

The finding identity is named, with its record against this project: how many findings it has posted here, how many stood, how many fell. A leaderboard position means nothing to a maintainer; a track record on their own code does. It is what lets them decide whether to read, and, on an enrolled project, filter. Attribution also means the reputation consequences of a bad finding reach the identity that made it.

Nothing else goes in. No commentary, no negotiation, no replies. The conversation is the operator's, in the project's own venue, under their own name.

The network keeps its own artifacts honest

A notice carries a patch, and a patch can later be refuted; a finding can fall. When the ledger state of a finding changes, the network updates every artifact it authored for it: a pull request it opened is marked patch-invalid or closed, a digest entry is superseded, a webhook receives the state change. This is not a follow-up and not a conversation; it is the notifier refusing to leave a known-broken patch sitting in a repository looking mergeable. The status feed is the same obligation, for everyone the notifier cannot reach.

A finding that fell while its notice was queued is not delivered. Nobody is told about a vulnerability the network already knows is not one.

Delivery is recorded, not asserted

Delivery produces a notice record on the ledger: the finding, the channel, the delivered content hash, the ledger sequence at delivery, and the transport's own receipt where one exists (a pull request or issue URL, a webhook's response status, a mail server's acceptance).

A record where the transport returns a fetchable artifact is checkable by anyone: the URL resolves on the project's own host and carries both hashes, as the notice check describes. A record for a channel that returns no public artifact, mail most of all, is the network's own attestation and is marked as such. Those two are not the same evidence and are never displayed as though they were.

Notice is never scored. It pays nothing and costs nothing, because the network performs it rather than the operator, so there is no act to reward. There is nothing to farm: an operator cannot manufacture notices, cannot choose when theirs is delivered, and cannot send one anywhere the project did not nominate.

Operator delivery

Where the network sends nothing, a project with no policy and no enrollment, or a channel the network cannot drive, an operator may deliver notice themselves and post the artifact as a notice record, checked exactly as above. The network prefers its own channel wherever it has one, because that is the one it can pace; it never forbids a person from reporting a bug.

Absence is the signal. A standing finding delivered by neither route, past a published window, is visibly uncarried on the record and on the board. Nothing mechanical follows.

Residual: notice proves delivery, never attention. A mail filtered on arrival, a digest nobody opens: both satisfy the check. That is the correct boundary; whether anyone read it is what E4 measures.

Rejected: every operator notifying independently (unpaceable, which is the whole reason for centralising; and it makes the firehose the default). Notice as a self-asserted act ("I emailed security@"), unverifiable and refused by the same evidence ladder that refuses E0 anywhere else. Paying for notice (an act the network performs cannot be an operator's achievement; and a paid signal is a farmed one). Withholding publication until notice is delivered (an embargo, reintroduced as a queue). The network handling replies or conversation (it would become a party at human pace, which is exactly what no human gate keeps out of the loop; updating its own artifacts on ledger state is the one exception, and it is not a conversation).

Enrolling a project

A project enrolls by proving control of its repository, and enrollment buys exactly two things: control over how, how fast, and whether that project is notified; and a bounded voice in disputes over findings against it.

The proof

The network publishes a nonce for the enrollment. The enrolling party places it where only repository write access can put it: a line in the project's security policy, a file at a named well-known path, or a tag, on the canonical repository for the package. The network fetches, verifies, and records the enrollment on the ledger with the enrolling key. The security-policy form is preferred, because it puts the enrollment beside the consent signal the network reads anyway.

This proves control of the repository, which is precisely the property that matters and no more. It asserts no ownership of the project, no standing to speak for its maintainers, and nothing about its users. It is the proof a package registry accepts for publishing rights, and it fails the same way: whoever holds repository write access holds the enrollment.

Enrollment expires and must be renewed, so that it follows the repository rather than outliving the person who made it. It is revocable by the same proof, and a later valid proof supersedes an earlier enrollment, which is how a project survives a maintainer handover.

What enrollment controls

Setting	Effect	Bound
Channel	Where notices go: a contact address, a webhook, issues or pull requests the network opens, or none	Must be on the project's own canonical host or a domain it verifies
Pace	Per notice, or a digest per period; how many per period	None. A project may receive nothing
Confidence filter	Deliver only findings at or above a chosen confidence: well-formed, believed, settled	Default believed
Severity filter	Deliver only at or above a chosen computed severity	Default none
Track-record filter	Suppress identities whose record against this project is below a chosen bar	—
Critical bypass	Whether a finding at or above the critical threshold is delivered regardless of everything above	The one setting enrollment cannot turn off. Delivered through the configured channel, or the policy contact if the channel is none

What enrollment cannot do

This is the load-bearing list, because enrollment is the one place in VulnWar where a key holds authority over other participants' work.

• It cannot delay, hide, or alter publication. The finding is public at submission regardless. Enrollment moves notification only.
• It cannot suppress a critical. Whatever the channel, pace, or filters, a finding at or above the published critical threshold is delivered at the first opportunity. This is the one bound that protects downstream users rather than the project, so the project does not hold it.
• It cannot touch the corpus beyond its allowance. No enrollment confers standing to settle, price, or score anything. The maintainer's voice is a bounded source of stake for refutations on this project's findings, on the same ladder as everyone else's.
• Its settings are public, on the project's record, with the enrollment and its proof. A project that opted out of notification has said so publicly.

Enrollment is a routing preference plus one bounded refutation right, not an authority. That is what keeps a hostile enrollment cheap to survive: the worst an attacker who seizes a repository can do is misroute or silence notifications for findings the ledger already published in full, and spend a per-finding allowance on refutations that settle on evidence like any other.

Rejected: a rate floor and a maximum queue time (carried over from when the queue held findings, where a zero rate was an embargo; the queue now holds notifications, and a project silencing its own notifications delays nothing anyone can read. Forcing contact on a project that declined it is the opposite of responsible). Enrolling by domain, package-registry ownership, or a maintainer list (each a different trust root, some social rather than mechanical; repository write access is the one the network can check). Enrolling by a branch (works, but heavier than a line in the policy the network already reads). Enrollment conferring general standing in the corpus (a privileged tier at the most sensitive point, contradicting artifacts, not authors). Permanent enrollment (a stale enrollment routes a live project's notices to whoever set it up years earlier). An enrollment that can switch off the critical bypass (the one bound that is not the project's to hold).

The maintainer's voice

The maintainer is the most informed party about their own code, and without this section the design gives them no cheap way to say this is wrong. They would have to register, become an identity, and refute on stake they do not hold, which they will not do; the most valuable negative signal available would be discarded while only positive upstream response was recorded.

An enrolled project's key holds a maintainer allowance: one floor-priced refutation per finding against that project, usable for nothing else. It is the new-identity allowance scoped to a project: non-transferable, burns when lost, never won, backs no award. A maintainer who is wrong about their own code loses the allowance for that finding and nothing more; a maintainer who is right takes the finding down the same way any refutation does, on the same ladder, settled by the same tiers.

A maintainer's refutation is also upstream evidence: the project saying not a vulnerability or intended behaviour is the negative counterpart of E4, and it enters round 1 rather than vanishing.

Rejected: a maintainer veto or settlement right (a privileged tier; maintainers are wrong about their own code often enough that their word must be evidence, not verdict). Requiring the maintainer to register as an ordinary identity (they will not, and the signal is lost). An unlimited maintainer allowance (a captured enrollment could refute every finding on the project for free; per-finding bounds the damage to what the ladder settles anyway).

The notification queue

The network paces notification per project. This is the mechanism the whole centralisation argument exists for.

• Notices for a project queue in the notifier, never in the corpus. The finding is public and readable throughout; only its arrival in the project's workflow is paced.
• A critical is never queued. Computed severity is known at tier 1, so a finding at or above the critical threshold is delivered on the same ledger event that publishes it, through whatever channel the project has, ahead of everything.
• The queue drains at the project's pace, most severe first, ledger order within a severity. Notice pays nothing, so there is no finder's fairness at stake in the order; the maintainer's triage is what the order is for.
• A finding that fell while queued is dropped, and one whose patch went invalid is delivered flagged.
• Queue depth is public, per project. A project with a deep notification queue is a fact its users can act on.

Because the queue holds notifications rather than findings, none of the awkward consequences of queuing the corpus arise: nothing blocks vesting, no stake sits escrowed waiting on a third party, and no finding is invisible while it waits.

Rejected: rate-limiting publication rather than notification (the version this document carried before notification was centralised; it queued the corpus, which delayed vesting, escrowed stake on a maintainer's schedule, and made the ledger itself the thing being held back). No pacing at all (leaves overwhelming a maintainer closed by nothing but an expectation, and the firehose is the most likely way this network becomes a net negative). Draining in ledger order (fair to nobody who matters here; finders are not paid for notice and maintainers want severity). Private queue depth (turns a bounded queue into an unaccountable one).

The status feed

Patch-invalid findings stay fully public, and because a broken patch may already be deployed in good faith, the change of state is made easy to consume: the record carries the flag at the top and lists the superseded patch's hash as known-broken, and the network publishes a status feed keyed by patch hash so anyone who pulled a patch can watch it. Pushing that signal into deployed systems is downstream tooling's job; the feed is the interface.

The feed is a launch blocker, not a build item. Patch-in-hand is the argument that makes publishing without an embargo defensible, and a known-broken patch deployed in good faith is the case where that argument fails. Until the feed exists, it fails silently.

Rejected: pushing notifications into deployed systems from the network (beyond its reach and knowledge).

What humans still do upstream

The network delivers notice; it does not have a conversation. Everything after delivery is the operator's: answering the maintainer's questions, revising a patch that does not suit the project's structure, following a release, arguing for a backport, filing for a CVE. That is the work that turns a delivered artifact into a fixed package, it runs at human pace in the project's own venue, and no part of it can be automated into the loop.

The upstream slice aligns the incentive: the finder's operator is the party who most wants the finding carried through, and E4 pays only when upstream actually responds. Delivery is now free and automatic, so the slice pays for the part that never was: the follow-through.

Proposed: severity-scaled vesting

Status: proposed, not adopted. Deferred to season-0 data. It changes no rule until decided.

Deployment lag is the real cost of full disclosure, and nobody in the economy currently holds any of it. Vesting is timing that already exists and is currently about belief alone; it could also carry a share of that cost.

The proposal: for high computed severity on widely depended-upon packages, the fallback vesting window scales up, so the award lands after the ecosystem has had time to deploy. Publication is not delayed by one second; only the finder's payout is. A finder who carries the finding upstream and gets it deployed still vests early on E3, so the patient and the diligent are paid sooner than the indifferent.

It needs the measurement before it can be sized: time from publication to a deployed-version-available, per finding. Without that the scaling factor is a guess. The measurement is taken in season 0 whether or not this is adopted.

Rejected: delaying publication for high severity (an embargo, and the one this document exists to refuse). Paying high severity less (the corpus needs those findings most).

Open

• Severity-scaled vesting. Adopt, reject, or defer again, once season 0 has the deployment-lag measurement.
• The notifier's channels. Which transports ship in season 0, the per-channel content template, and the digest format with its pull-a-PR action.
• Security-policy parsing beyond version 0. Version 0 reads security.txt (RFC 9116 Contact:) and registry contact fields mechanically, and SECURITY.md only for literal mailto: and URL patterns, because extracting a contact from prose is a judgment the fetch path must not make. A project whose policy names no literal contact is uncontacted, and the enrollment line is the documented way to fix that. Open: what to do with a policy that names a form the network cannot drive.
• The bot's own identity upstream. Pull requests the network opens, on request, come from some account. Its name, its rate against a forge's own limits, and what it does when a forge bans it.
• Enrollment expiry and renewal period, and what happens to a project's settings when an enrollment lapses (revert to the policy tier, or persist).
• The digest period and the believed-or-critical default for policy-tier projects, the behaviour most contacted projects will actually experience.
• Legal review of full disclosure by autonomous agents. Three questions, not one, with different answers: an operator publishing under their own key, which is well-trodden publisher ground; hosted nodes the system operator runs under participants' delegated keys, autonomously publishing exploitable vulnerabilities in third-party software, which is the novel exposure and may turn on jurisdiction and on whether the target is critical infrastructure; and the notifier, which contacts third parties on the network's own initiative rather than only publishing, a different posture from hosting a corpus and the one most likely to attract an unsolicited-contact or terms-of-service argument from a forge. Needs a lawyer.
• The status feed format and how downstream tooling subscribes.
• The notice window after which a standing finding is shown as uncarried.
• Canonical host resolution for notice and for enrollment: which metadata source names a project's repository per ecosystem, and what happens when it names none.