NIP-XX: Event Timestamp Attestations

[cyril]

NIP-XX — Event Timestamp Attestations (kind: 1041)

Summary

An event kind for trusted-third-party event timestamping. Any party signs an event of kind: 1041 referencing another event via an e tag with marker attests; the attestation's created_at is the signer's claimed receipt timestamp for that event. The trust model is application-defined: applications layering on this primitive specify whose attestations are authoritative for their purposes.

Motivation

NIP-03 (OpenTimestamps Attestations for Events) provides event timestamping via Bitcoin anchoring. Its trustless model comes at the cost of confirmation latency — averaging around 10 minutes per Bitcoin block with significant variance — plus typical operational delays from OTS calendar batching, and infrastructure overhead (OTS calendars, Bitcoin nodes).

This trade-off is appropriate for long-term proof-of-existence, but less practical for use cases where second-level receipt timing matters more than trustlessness:

• Turn-based games with binding time controls (chess blitz, shogi, xiangqi, e-sports tournaments)
• Auctions and live bidding where bid ordering is decisive
• Live contests, polls, and votes where the moment of a contribution affects its validity
• Audit logs requiring timely third-party witness

This NIP proposes a complementary approach for these cases: a small event kind based on third-party trust rather than blockchain anchoring, allowing receipt timestamps at second-level resolution.

Design choices

The proposal is small in scope. Rationales for each choice are in the NIP itself:

• Stateless validation: relays and clients can validate kind 1041 events without fetching the referenced event. Cross-event sanity checks are explicitly consumer-side.
• kind: 1041 (tentative): adjacent to NIP-03's 1040, signaling a related concern (event-level timestamping) under a different trust model.
• Regular event semantics (not replaceable or addressable): an attestation is an audit artifact; mutability would defeat its function as a third-party witness.
• Marker attests following the NIP-10 convention.
• Namespacing recommendation for application-specific markers (e.g., chess:root) to prevent future collisions with general-purpose markers that may be standardized later.
• NIP-26 delegation: explicitly deferred to applications. The primitive does not take a position on whether delegated signatures count as authoritative.
• content field empty: an attestation carries no subjective payload; all semantics live in the signature, created_at, and the attests-marked e tag.

Relationship to NIP-03

The two NIPs are complementary, not competing. An event MAY have both an OpenTimestamps Attestation and one or more Event Timestamp Attestations.

	NIP-03	This NIP
Trust model	Trustless (Bitcoin anchored)	Trusted third party
Latency	~10 min average per block, often longer in practice	Order of seconds
Resolution	Bounded by Bitcoin block time	Bounded by created_at (1 second)
Infrastructure	OTS calendars + Bitcoin	None beyond standard Nostr
Best suited for	Long-term proof of existence	Second-level receipt timing

Implementation

Sashité is integrating this NIP into a decentralized protocol suite for chess-family games (chess, shogi, xiangqi). In that suite, a match designates a timestamper role; Event Timestamp Attestations from that signer, referencing the match's move events, provide receipt timing for time-control accounting.

Looking for additional implementers from the Nostr community, particularly anyone working on applications (games, auctions, live contests) that would benefit from this primitive. Happy to coordinate.

Open questions for review

• The kind number 1041 is tentative. If it's already claimed by another draft, please point me to it and I'll adjust.
• The marker namespacing recommendation (e.g., chess:root) is intended to be forward-compatible with any future standardized markers. Feedback on the convention is welcome.
• Whether to address NIP-26 delegation more explicitly in the spec — currently deferred to applications, but open to community input.