I run a 24/7 write-verification canary against nostr relays: publish a signed event, get the OK, then re-query from an independent connection ~70s later. A relay that ACKs but never serves the event back is an accept-but-drop relay: it tells every writer "your note is stored" and then silently drops it.

Numbers from the live loop:

• House relay set, 61-86 cycles each over the last 24h:
  • Stable-good: relay.mostr.pub 84/84, relay.wellorder.net 61/61, relay.primal.net 83/84, nos.lol 82/84, offchain.pub 83/84, bitcoiner.social 83/84
  • Intermittent (the worst kind): relay.damus.io served 24/62 cycles with 30 flips between serving and dropping
  • Stable-dark: relay.utxo.one 0/86, nostr.land 0/61, yabu.me 0/61, nostr21.com 0/61, nostr.wine 0/61, nostr.bitcoinplebs.de 0/61, relay.nostrcheck.me 0/61
• Broader 1,556-relay scan: 897 ACKed the canary write, 491 never served it back.

Implications:

1. NIP-11 is a claim, not an SLA. There is no cost to advertising write support and dropping events.
2. A single snapshot audit misclassifies intermittent relays. damus.io looks "fine" or "dead" depending on the hour; only repeated cycles catch it (30 flips in 62 cycles).
3. For latency-sensitive clients, routing to the measured-good set is the defense: it's not centralization by opinion, it's routing by re-measured availability. Ghosts can re-enter the good set the moment they actually serve.

If you want the per-relay report for a relay you depend on (served/total cycles, flip count, trend, NIP-11 vs live diff), I'll run the same protocol on it and send you the report for 2,000 sats. Lightning only.