← All NIPs

NIP-03

OpenTimestamps Attestations for Events

UnrecommendedEvents

Kind 1040 carries an OpenTimestamps proof that an event existed by a certain Bitcoin block. Marked unrecommended upstream: vulnerable to one specific attack and awaiting an update.

Status
Still documented, but new software should not build on it.
Kinds
Tags
  • e
  • k
Last changed
May 31, 2026

Not recommended: vulnerable to one specific attack, needs update

Try it

Edit the form or the JSON: both stay in sync, the badge says whether the result is valid, and tapping any field explains it.

Examples
Valid 1 note

Not signed yet · Demo keys only. These personas' secret keys are public on purpose.

Form
Jan 1, 2025, 12:00 AM UTC

Content

Base64 of a complete .ots file with ideally one Bitcoin attestation and no pending ones.

Tags

  1. e Required

    The event being timestamped.

  2. k Recommended

    Kind of the stamped event.

Add tag

How this NIP works

Step 1 of 4

Unrecommended

The NIP is flagged as vulnerable to one specific attack and needs an update. There is no replacement NIP yet; treat these proofs as informational.

In the course

No course chapter covers this NIP yet. The editor above is the quickest way in.

Builds on

Specification

Specification text is quoted in English from the nostr-protocol/nips repository. Our explanations and the interface are translated. Source on GitHub at commit 0046368

Read the spec171 words, quoted from the repository at commit 0046368.

This NIP defines an event with kind:1040 that can contain an OpenTimestamps proof for any other event:

{
  "kind": 1040
  "tags": [
    ["e", <target-event-id>, <relay-url>],
    ["k", "<target-event-kind>"]
  ],
  "content": <base64-encoded OTS file data>
}
  • The OpenTimestamps proof MUST prove the referenced e event id as its digest.
  • The content MUST be the full content of an .ots file containing at least one Bitcoin attestation. This file SHOULD contain a single Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to "pending" attestations since they are useless in this context.

Example OpenTimestamps proof verification flow

Using nak, jq and ots:

~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify
> using an esplora server at https://blockstream.info/api
- sequence ending on block 810391 is valid
timestamp validated at block [810391]