[ PROOFECONOMY ]™GlossaryOriginSpecsDead Canary Protocol (ProofSwarm)
ProofSwarm, the Dead Canary Protocol (DCP), produces Proof of Efficacy for a security control by releasing a blind-mixed flock of good and bad canaries, committed in advance to a public time anchor, and having an independent out-of-band Proof Witness record which canaries lived and which died.
What it means
Coal miners carried canaries. If the air turned bad, the canary died first, and nobody could fake a dead bird.
The Dead Canary Protocol sends a flock of canaries into the environment a security control protects:
- Bad canaries carry real adversary techniques (MITRE ATT&CK or ATLAS). If the control works, they die.
- Good canaries do legitimate work. If the control works, they live.
The flock is mixed blind, so neither the control nor the witness can tell good from bad. A Proof Witness waits where each canary’s effect would land and records who lived and who died. DCP measures outcome, not detection. A control that alerts on an attack that still succeeds has failed.
The four outcomes
| Canary | Lived | Died |
|---|---|---|
| Bad | Missed. The attack worked. | Stopped. The control did its job. |
| Good | Passed. Business as usual. | False block. The control broke legitimate work. |
A control that blocks everything stops every bad canary and kills every good one. DCP always reports both sides.
How DCP uses exclusion and indistinguishability
DCP rests on two properties:
- Indistinguishability. Canaries are built to be statistically indistinguishable from real traffic. A good canary looks like legitimate work and a bad canary looks like a real attack, so the control cannot tell a test from reality and cannot treat the test differently.
- Exclusion. The entire flock is committed before release. The witness classifies each observed effect by its effect token against that commitment. An effect in the committed set is a test canary and is scored. An effect excluded from the committed set is a wild canary: a real attack or a real fault, surfaced by the same harness.
The witness never needs a signature from the control, and the control never gets to report on itself. Classification is a lookup against a record sealed before anything happened.
DCP can also measure how tight an agent’s boundary is, by planting out-of-policy actions as bad canaries and checking that they are excluded.
Why it is not self-attestation
No role in the chain belongs to the vendor, the opposite of a Self-Attestation Oxymoron:
- The vendor is out of the loop. It does not build canaries, hold the answer key, or run the witness. The Issuer must never be the Vendor.
- The answer key is sealed first. Every canary, its label and expected effect are hashed and anchored to a public time and randomness source, such as the NIST Randomness Beacon, before release. After the run the commitments are revealed. If anything changed, the run is void.
- The beacon chooses the order after commitment, so nobody can arrange the flock to look good.
- The witness is out of band. The control cannot see, delay or edit its records.
- Every run is published, including the bad ones.
Why it is not stupid cryptography
DCP’s commitments do not stand in for the test. They seal an answer key that existed before the attack, and the observation is made by a witness the control does not touch. The cryptography proves nothing changed. The canaries, the witness and the published method are what show the control worked. See stupid cryptography.
Solution, device and control
Proof is attributed at three levels: the Solution Under Test (SUT), each Device Under Test (DUT) inside it, and each Control Under Test (CUT) inside a device. A device log naming the rule that fired does not count. A single control earns credit only when matched runs show the attack lands with that control off and dies with it on. DUT and SUT come from the competitive test methodology in Technical Marketing (2008).
New attacks, drift and outages
- Mutations and holdouts: every run uses fresh variants of each technique, plus a private pool that is never published.
- Embargoed canaries: a real 0day can be committed now and revealed after coordinated disclosure, proving the control was tested before the world knew.
- Fingerprints: every result is tied to a hash of the exact deployed control. Change the control and the old proof goes stale.
- Black holes: canaries lost to outages unrelated to the control are voided, never scored, and the loss rate is published.
Output
Each bad canary in a valid run produces one Unit of Proof: a signed, anchored, independently witnessed outcome. Results are published to an append-only public registry.
Where the term comes from
ProofSwarm: The Dead Canary Protocol is Proof Protocol specification PP-SPEC-077. It was earlier titled Prooflock. It is authored by Craig Thomas Ellrod and published under the Proof Protocol License 1.0, with specification text under Apache License 2.0. Patent rights in the methods are reserved. Acknowledgment: Josh Waldrep, for his receipt-based verification work.