NIP-13: Proof of Work
Make spam pay a visible cost
NIP-13 is Nostr's simplest anti-spam price signal. Instead of asking a relay to trust an account, a score or a central reputation service, it lets an event carry proof that someone spent computation before publishing it. The proof is cheap to verify and expensive to mass-produce at high difficulty.
The mechanism is deliberately familiar to Bitcoin people: find a hash with enough leading zero bits. In Nostr, the hash is the NIP-01 event ID. A client changes a nonce tag, recalculates the event ID and repeats until the ID reaches the target difficulty.
The value is not that proof-of-work solves spam on its own. It gives relays and clients one objective signal they can use beside rate limits, payments, authentication, Web of Trust, moderation and paid relay policy. A public relay under attack may require PoW on writes. A user may require PoW for replies to a thread. A gift-wrap sender may add PoW to make random-key spam more expensive.
Difficulty, nonce tags and committed targets
Difficulty is the number of leading zero bits in the event ID. Hex makes this slightly easy to misread: a nibble such as 7 still contributes one leading zero bit because it is below eight. The official NIP includes C and JavaScript examples for counting leading zero bits correctly.
Mining uses a nonce tag. The second element is the changing nonce value. The third element records the target difficulty. That third value is not decoration. It protects against a low-difficulty spammer getting lucky with a high-difficulty ID and pretending the event was mined for the stricter requirement.
Because the NIP-01 event ID does not commit to the signature, proof-of-work can be outsourced. A client can prepare unsigned event material, ask a service or worker to find a nonce, then sign and publish. That matters for phones and low-power devices, but it also introduces a market and trust design question around PoW services.
A compact NIP with real implementation pressure
William Casarin added the visible Proof of Work NIP in May 2022. The file history then shows practical cleanups: examples corrected in April 2023, JSON formatting work in 2023, a fix for an otherwise unverifiable event in May 2024 and a removal of old prefix-query text in August 2024.
Issue #340 is useful outside the spec itself. It proposed a proof-of-work service provider so clients could request remote PoW. That discussion makes the product tension clear: relays may want PoW, but mobile clients may not want to burn battery mining every publish.
The standard also reappears in NIP-59. Gift-wrapped events use random outer keys, which makes normal pubkey reputation weak. NIP-59 mentions attaching NIP-13 proof-of-work to wrapper events as one possible spam signal. That is a good example of a small NIP becoming a reusable building block.
Libraries can mine it; relays decide whether to care
NIP-13 is easy to validate and harder to use well. Rust Nostr exposes NIP-13 helpers for leading zero bits and prefixes. go-nostr includes a nip13 package with DoWork that searches for a nonce using available CPU. nostr-tools carries NIP-13 test coverage. Those libraries make the primitive available to clients and relays.
Relay support is policy. Some relays list NIP-13 or use local admission rules; others rely on payment, authentication or social filtering. A relay can require different difficulty levels for different event kinds or write contexts, but the NIP itself only defines how the proof is represented and checked.
The product question is where to surface the cost. A user can tolerate a short delay before posting to a busy public relay. A chat app cannot freeze every message for hard mining. A moderation tool may accept PoW as one input but still need abuse reporting, rate limits and relay-level judgment.
Proof of work filters abuse unevenly
Proof-of-work is not fairness. It prices computation. Attackers with better hardware, botnets or outsourced miners can absorb that price more easily than normal users on phones. Relays that require too much PoW can exclude exactly the lightweight clients Nostr wants to support.
The second risk is false comfort. PoW can make bulk spam more expensive, but it does not decide whether content is harassment, fraud, malware or nonsense. It is a mechanical signal, not moderation judgment.
Read NIP-13 in the wild
NIP-13 adds proof-of-work to events as an anti-spam signal. It does not make a post true or valuable. It makes the event more expensive to produce by requiring leading zero bits in the event id and a nonce tag that records the target difficulty.
The useful question is economic, not mystical. Does a relay, client or community actually use the work signal to slow abuse, or is it just a badge? Cost helps only when the product treats it as one input among many.
What changes when you actually use it
For you, NIP-13: Proof of Work is felt when an app either behaves predictably or suddenly loses context. The visible symptom may be a missing reply, a broken link, a strange reaction count, an empty result or a relay error that looks like the whole network failed. The official terms draft, relay, nonce, created_at are where that visible behavior begins, so the source is not background material; it is the place where the product promise gets its limits.
What changes for builders and operators
For builders, NIP-13: Proof of Work is compatibility discipline. Implement draft, relay, nonce, created_at against more than one relay and more than one library, then test malformed, missing and duplicated data. Core standards fail most painfully when the happy path looks fine and the second client exposes the shortcut.
What the official file makes concrete
Inspect draft, relay, nonce, created_at because these are the pieces most likely to surface as product behavior. Read it beside NIP-01 before treating it as isolated.
NIP-13: Proof of Work is a shared contract between independent software. The smallest field can become user-visible when two clients disagree about it.
Where it breaks
The failure mode in NIP-13: Proof of Work is often indirect. Nobody complains about draft, relay, nonce, created_at; they complain that the feed is wrong, the reply vanished or the relay behaved strangely. Use the official file to diagnose the hidden cause instead of patching only the visual symptom.
Where this appears outside the markdown
In the ecosystem, NIP-13: Proof of Work is not something most people choose directly. It is the invisible grammar behind clients, relays, crawlers, search tools and archives. When a product team treats draft, relay, nonce, created_at as implementation detail only, the mistake eventually reaches the surface as missing history, bad threading or state that cannot be reconstructed after a client switch.
The nearby-standard trap
The nearby-standard trap in NIP-13: Proof of Work is assuming the base layer solves the higher-level feature. This NIP may define the common grammar, but publishing, wallets, moderation, media or groups still need their own constraints. Read NIP-01 to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-13: Proof of Work does not say "the protocol handles it" and move on. It explains the visible consequence: what was sent, what was accepted, what was rejected, what is still loading and what another relay or client may show differently.
What this page does not promise
NIP-13: Proof of Work does not promise a finished social product. It gives software a shared grammar. Feed design, moderation, ranking, notifications, storage duration and recovery remain separate product decisions. That distinction matters because a client can be technically compatible and still give you a weak experience if it hides relay errors, drops context or treats optional fields as if every app understood them.
Read it as a field test
Start NIP-13: Proof of Work with the visible product symptom, then trace it back to draft, relay, nonce, created_at. That order keeps the article grounded: you see why the field exists, which relay or client behavior depends on it, and where adjacent standards change the story. A core NIP is strong only when it explains both the normal path and the awkward edge case.
Where the standard earns trust
The source links give you places to test the interpretation in public: Issue #340: PoW service provider, rust-nostr NIP-13 module, go-nostr nip13 package, nostr-tools NIP-13 tests. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-13 source is the anchor for exact wording, and NIP-13 commit history shows how that wording moved over time. The strongest secondary clues here are Issue #340: PoW service provider, rust-nostr NIP-13 module, go-nostr nip13 package. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-13: Proof of Work: first the human promise, then draft, relay, nonce, created_at, then the implementation record, then the real-world failure case. That order keeps NIP-13 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
draft,relay,nonce,created_atwithout a hidden compatibility rule? - Does the UI explain relay rejection, missing context or state replacement without blaming the whole network?
- Which adjacent standard, especially NIP-01, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
draft,relay,nonce,created_atin the official file and check where the UI exposes the same concept. - Read NIP-01 as context before treating NIP-13 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-13: Proof of Work in that order: Official NIP-13 source for the current wording; NIP-13 commit history for the change record; Issue #340: PoW service provider, rust-nostr NIP-13 module, go-nostr nip13 package for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
