NIP-03: OpenTimestamps Attestations for Events
A timestamp proof is not the same thing as trust
NIP-03 tries to answer a narrow but interesting question: can a Nostr event carry an OpenTimestamps proof for another Nostr event? The answer is yes, technically. The standard defines a kind 1040 attestation event whose content is a base64-encoded .ots file proving the referenced event ID as a digest.
The reason this matters is that Nostr events are signed, but a signature does not prove when something existed. OpenTimestamps is a Bitcoin-based timestamping system. It can prove that some digest existed before a block confirmation. In a publishing or evidence context, that can be valuable.
But NIP-03 is also a good example of why an all-encompassing Nostr wiki has to show warnings clearly. The official README currently marks it unrecommended because it is vulnerable to a specific attack and needs an update. That means the lesson is not simply 'timestamp your events.' The lesson is how a clever bridge to Bitcoin can still be too fragile for broad recommendation.
Kind 1040 and the OpenTimestamps payload
The event shape is compact: kind 1040, an e tag that references the target event, a k tag that records the target event kind, and content containing the full base64-encoded OpenTimestamps file. The proof has to prove the referenced event ID as its digest.
The spec prefers a single Bitcoin attestation and no pending attestations. That is an important product detail. A timestamp proof that still depends on pending calendar data is less useful inside a portable event. The goal is a compact, independently useful proof that a client or tool can verify.
The example flow uses nak, jq and ots: fetch the attestation event, pull the content, and verify it with an OpenTimestamps verifier. That tells you what kind of user this NIP was written for. It is closer to a developer/operator tool than to a normal social-client feature.
A niche standard with a visible warning label
NIP-03 arrived with the early NIP set and has been rewritten more than once. In October 2023, PR #804 reworked it so it was actually usable, according to the commit message. Soon after, fiatjaf clarified why a single attestation is recommended. In 2026, the standards body added explicit unrecommended tags and warnings across affected NIPs, making the current caution visible at the top of the file and in the README.
That sequence tells a useful story. The idea was plausible enough to specify and implement experimentally. Then it needed repair. Then it needed a warning. For people, that is not embarrassing; it is exactly the kind of history a standards wiki needs to preserve. Failed or discouraged standards often teach more than polished ones.
The contributor trail includes fiatjaf, Mike Dilger and others, but the page is best read less as a personality story and more as a standards-quality story: a bridge between Nostr and OpenTimestamps exists, but current adoption advice is cautious.
Where NIP-03 appears in real code
The implementation trail is real, but small. RCasatta's nostr-ots and the nostr_ots Rust crate describe themselves as proof-of-concept implementations for NIP-03 OpenTimestamps attestations. Perl's Net::Nostr::Timestamp also documents NIP-03 support. That is valuable evidence that the NIP was not just a theoretical note.
The limited implementation map also says something important. NIP-03 is not like NIP-01 or NIP-05, where every mainstream client has to care. It is closer to an evidence and archival tool. A user may never see it; a developer building timestamped publishing or proof workflows might care a lot.
A mature product around NIP-03 would need more than a valid .ots file. It would need an explanation of what the proof does and does not prove, a way to verify it without command-line friction, and a clear warning that timestamp existence is not content truth, identity trust or publication legitimacy.
The warning is part of the standard now
The official warning cannot be treated as a footnote. If a NIP is marked unrecommended because it is vulnerable to a specific attack and needs an update, the article has to say so plainly. The right posture is preservation, not promotion.
The other risk is overclaiming. A timestamp can prove that a digest existed before a certain time. It does not prove who first wrote the content, whether the content is true, whether the event was widely published, or whether a user understood what they were signing. That distinction is the difference between a useful evidence primitive and a misleading trust badge.
Read NIP-03 in the wild
NIP-03 is a useful fossil: it tried to bind Nostr events to OpenTimestamps so an event could carry stronger evidence about when it existed. The idea fits Nostr's proof culture, but the current source marks it unrecommended because the design needs repair.
That history is still worth reading. It shows how standards can preserve an ambition without pretending the first version is safe to build on forever. Use it as timestamping context, then verify current guidance before putting it anywhere near legal proof, publication history or dispute resolution.
What changes when you actually use it
For you, NIP-03: OpenTimestamps Attestations for Events is felt when identity stops being a username and becomes authority. A client, signer, name, proof or auth event may look like account plumbing, but it decides who can publish, approve, connect, recover or be recognized. Read NIP-01 and the adjacent source links beside it so you can tell the difference between a convenient identity surface and the key material that actually controls the account.
What changes for builders and operators
For builders, NIP-03: OpenTimestamps Attestations for Events means making authority visible before action. A signer prompt, name proof, delegation, encrypted key, external identity or HTTP auth event needs plain language around scope, expiry, destination and recovery. If a person has to guess what they are authorizing, the protocol has already lost the trust battle.
What the official file makes concrete
The official file is organized around Example OpenTimestamps proof verification flow. Inspect kind 1040, unrecommended, draft, kind:1040, e, content because these are the pieces most likely to surface as product behavior.
NIP-03: OpenTimestamps Attestations for Events is an authority path, not decoration. A name, key, signer, delegation or auth event decides who can act as you.
Where it breaks
The failure mode in NIP-03: OpenTimestamps Attestations for Events is authority drift. A name resolves to an old key, a signer approves too broadly, an auth event gets replayed, a delegation lasts too long or a private key backup gives false comfort. The product has to keep control boundaries visible after onboarding, not only during setup.
Where this appears outside the markdown
In the ecosystem, NIP-03: OpenTimestamps Attestations for Events usually appears at the doorway: account setup, profile recognition, signer approval, cross-platform proof, remote signing, HTTP auth or recovery. That doorway needs unusually clear language because identity mistakes are sticky. Once a key, signer or proof is trusted in the wrong place, every later feature inherits the confusion.
The nearby-standard trap
The nearby-standard trap in NIP-03: OpenTimestamps Attestations for Events is confusing recognition with control. A name, signer, URI, encrypted key, delegation or auth signature may all sit near identity, but they answer different questions. Read NIP-01 and the adjacent source links and ask one thing each time: who can act, who can verify, and what can be revoked?
Language that keeps the feature honest
Good product copy for NIP-03: OpenTimestamps Attestations for Events names the authority. It says whether you are sharing a public key, approving a signature, trusting a domain, exporting an encrypted secret, delegating power or authenticating to a service. Small labels matter because identity mistakes do not feel small after they happen.
What this page does not promise
NIP-03: OpenTimestamps Attestations for Events does not make identity effortless or risk-free. It can help keys, names, signers, delegation or authentication become portable, but it cannot decide who you trust, how you back up secrets or whether a domain, app or signer deserves authority. Read NIP-01 and the adjacent source links as a control map before handing any interface the power to sign, verify or speak for you.
Read it as a field test
Start NIP-03: OpenTimestamps Attestations for Events with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms kind 1040, unrecommended, draft, kind:1040, e, content are useful because they turn vague identity language into concrete control points. Without that, a friendly login screen can hide the most important security decision.
Where the standard earns trust
The source links give you places to test the interpretation in public: PR #804, OpenTimestamps, RCasatta/nostr-ots, nostr_ots crate. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-03 source is the anchor for exact wording, and NIP-03 commit history shows how that wording moved over time. The strongest secondary clues here are PR #804, OpenTimestamps, RCasatta/nostr-ots. 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-03: OpenTimestamps Attestations for Events: first the human promise, then kind 1040, unrecommended, draft, kind:1040, e, content, then the implementation record, then the real-world failure case. That order keeps NIP-03 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who gains authority when this NIP is used: your key, a signer, a domain, a delegated key, a wallet or a web service?
- Can you revoke, rotate, back up or inspect that authority before something goes wrong?
- Does the interface separate public recognition from private signing power in language you can act on?
What to verify before you rely on it
- Find
kind 1040,unrecommended,draft,kind:1040,ein the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-03 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-03: OpenTimestamps Attestations for Events in that order: Official NIP-03 source for the current wording; NIP-03 commit history for the change record; PR #804, OpenTimestamps, RCasatta/nostr-ots 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.
