Warrant canaries, anchored to Bitcoin

A warrant canary you can't fake, freeze, or back-date.

OpenAuspex publishes warrant canaries on Nostr and anchors every attestation to the Bitcoin blockchain. A seized key can't keep the bird chirping with pre-signed statements; no one can quietly back-date or erase the record. The freshness is provable, and the silence is the message.

$npm i -g @openauspex/cli
auspex check~ canary primary · ALIVE · anchored block 953,270
IWhy OpenAuspex

A canary is only as good as its freshness.

Nostr already gives you signed authorship, a replicated archive, and trivial monitoring. The missing piece is proving each statement is recent and live, produced under the operator's own control, right now. OpenAuspex adds that with Bitcoin.

The silence is the signal.

A warrant canary is an affirmative statement (“we have not been served a secret order”) whose absence carries the message. Drop one clause and watchers learn which kind of demand arrived, without you ever saying you received it.

Freshness you can prove.

Every attestation embeds a recent Bitcoin block hash, which can't be known until the block is mined. That proves the statement was signed after that block existed, so a seized key can't keep the bird chirping with statements signed in advance.

No back-dating, no erasure.

OpenTimestamps commits each attestation into a later Bitcoin block, fixing the upper time bound. Multi-relay publication and the chain itself make the record impossible for any one party to quietly delete or rewrite.

No single point of trust.

Every event is signed, so no relay can forge a chirp. Block hashes are cross-checked across independent explorers (or your own node), so no single source can lie about the state of the chain.

IIQuick Start

From keypair to canary, in one terminal.

The auspex CLI runs the whole lifecycle: keygen, define, attest, and check. Each attestation is anchored to Bitcoin and timestamped, and anyone can verify the result.

terminal
01$ auspex keygen   # a fresh Nostr keypair02$ auspex init     # scaffold canary.config.json03$ auspex define   # publish the canary definition0405$ auspex attest   # sign · anchor to Bitcoin · stamp06published attestation 4db5bfe1… · block 9532680708$ auspex check    # anyone can verify it09canary "primary": ALIVE10  next deadline: 2026-07-1811  fresh signers: 1/1
IIICapabilities

Everything a canary needs. Nothing it doesn't.

An open toolkit for publishing and monitoring warrant canaries.

01

Built on Nostr

Every event is signed, so authorship needs no host, and attestations replicate across independent relays as a permanent, censorship-resistant archive. The identity and transport layer, with no central server to seize or subpoena.

02

Bitcoin Freshness Anchor

Each attestation carries a recent block height and hash. The hash can't be known before the block is mined, so next period's canary can't be pre-signed today. Cross-checked across multiple explorers.

03

OpenTimestamps Proofs

A NIP-03 proof commits every attestation id into a later Bitcoin block, a not-later-than bound that makes back-dating a missed period impossible. It verifies against the chain alone.

04

Per-Clause & Multi-Signer

Affirm each clause independently and require a threshold of signers. Drop a clause and monitors raise CLAUSE-DROP, naming it; the canary stays alive only while m of n signers stay fresh. Hiding one demand, or coercing one key, isn't enough.

05

Liveness Monitoring

Watchers validate the whole chain and raise DEAD, CLAUSE-DROP, and DEFINITION-DRIFT alarms, and can re-broadcast them as Nostr events so a mesh of watchers all see it.

06

CLI & Library

A typed @openauspex/core library and an auspex command: keygen, define, attest, upgrade, check, watch, inspect, verify. Build it in, or run it from a terminal.

IVUnder the Hood

How it works

Three open networks, each doing one job. Nostr signs every statement and replicates it across relays; Bitcoin anchors it to a recent block so it can't be pre-signed; OpenTimestamps commits it into a later block so it can't be back-dated. No central server, no trusted clock.

I
Define
the contract
II
Affirm
each clause
III
Anchor
a recent block
IV
Publish
to N relays
V
Timestamp
OpenTimestamps
VI
Verify
bracket the time

Nostr · identity and archive

Each statement is signed by the operator's key and published to many relays: a kind-32772 definition and the kind-1772 attestations that renew it. Authorship no host can forge, on a record no host can erase.

kind 32772 · canary definition kind 1772 · canary attestation

Block Anchor · not-earlier-than

Each attestation embeds a recent Bitcoin block. Because a block hash is unpredictable until it is mined, embedding it proves the statement was signed after that block existed, which is what defeats pre-signing.

["freshness", "bitcoin", "953268", "0000…132bcd"]

OpenTimestamps · not-later-than

A NIP-03 kind-1040 proof commits the attestation's id into a later Bitcoin block. The two time bounds together pin the signing to a span of a few blocks, verifiable against the chain alone, forever.

kind 1040 → block 953270 signing bracketed · ~30 min