1. Sashité for Developers
2. Nostr
3. NIPs
4. Adjudication Request

NIP-XX

Adjudication Request

retired optional

Retired (2026-09-04). This kind is no longer part of the suite, which designates no arbiter. Its role — fixing the cutoff at which a session’s natural state is evaluated, and the invoker’s identity — is carried by the Conclusion (kind 3425) itself, signed by a player, whose own canonical timing is the cutoff and whose verdict is verified under the session’s rule system rather than believed. The text below is kept as published for the record; it is not normative, and no conforming implementation emits or consumes kind 3424.

This NIP defines a Nostr event kind for invoking the designated arbiters of a chess-family session to issue a ruling. The Adjudication Request is signed by one of the two players of the session and triggers any of the arbiters to examine the natural state of relevant events and produce an Adjudication (defined separately).

Abstract

Defines kind: 3424, a regular event by which one of the two players in a session formally asks the designated arbiters to render a verdict on the session. The event references the Game Session (kind 3422) and addresses every arbiter of the session’s designated set. Any one of them examines the natural state of events and responds with an Adjudication.

The Adjudication Request carries no claims or accusations. An arbiter rules on what is signed and published, not on what the invoker asserts.

Motivation

A session in the chess family terminates when a designated arbiter renders a binding ruling. Players cannot self-judge: a “checkmate” is a position recognized by the rule system, not a claim made by a player; a “timeout” is the elapsed time according to the time-control accounting, not an accusation.

The Adjudication Request is the mechanism by which a player asks the arbiters to look at the session and produce an Adjudication. The request is intentionally minimal: it carries the session identity and the arbiters’ pubkeys. An arbiter, having received the request, examines the natural state of the session (Game Session plus the chain of Ply events) and renders a verdict.

Representative use cases

The Adjudication Request mechanism addresses several distinct lifecycle situations in arbitered sessions:

• Natural termination ratification: a player believes the rule system has terminated the session (checkmate, stalemate, repetition, etc.) and asks an arbiter to formalize the verdict.
• Timeout recognition: a player believes the opponent has exceeded their time-control budget and asks an arbiter to rule a timeout.
• Resignation formalization: a player wishes to resign and invokes the arbiters; the ruling reflects the resignation per the rule system’s termination conventions.
• Abandonment recovery: when one player stops responding (whether by accident, network failure, deliberate refusal, or any other reason), the other player can invoke the arbiters to rule on the session. The ruling — typically a timeout, or such other status as the rule system yields per the rule system — terminates the session and unblocks the active player. This is the principal protocol-level mechanism for resolving abandonment.
• Disputed move recognition: an arbiter’s ruling resolves a disputed position (e.g., a contested claim of threefold repetition).

In all cases, the request is informational from an arbiter’s perspective: it rules on the natural state of the events, not on the invoker’s claims about that state.

Preconditions

An Adjudication Request references the session’s Game Session (kind 3422) directly. This structurally enforces the precondition that the session is initialized: a request that cannot reference a valid Game Session is non-conforming per constraint 2 (§Semantic constraints) and MUST be ignored. See kind 3422 §Handling a silent arbiter set for the recommended client behavior when no Game Session has been published.

Specification

Event kind

kind: 3424

Adjudication Request events are regular events per NIP-01: immutable once signed and broadcast.

Operating mode

Every session has a designated arbiter set (per the session’s founding context — kind 3422 §Signing party), mirrored in the Game Session’s arbiter-marked p tags (kind 3422 §Arbiter set). This NIP defines the mechanism by which a player invokes those arbiters to issue a ruling. The Adjudication Request references the session’s Game Session (kind 3422) and addresses every member of the set — not only the founding arbiter that signed the Game Session: the members are interchangeable, and any of them may rule (kind 3425 §Signing party).

Attestation by the designated timestamper (attested mode)

This section applies in attested mode. In self-timed mode the Adjudication Request’s canonical timing is its own created_at, established by acceptance at one of the session’s designated timing relays (Canonical Timing §Canonical timing of an event).

The designated timestamper publishes an Event Timestamp Attestation (kind 3410) referencing this Adjudication Request via the required attests-marked e tag. Its created_at is then the Request’s canonical timing for any consumer reasoning about invocation order (e.g., distinguishing which of two competing Requests came first).

The structure of the Adjudication Request Attestation is:

["e", "<adjudication_request_event_id>", "<relay_hint>", "attests"]
["e", "<game_session_event_id>", "<relay_hint>", "<app>:session"]

The second e tag carries an application-namespaced discovery marker <app>:session referencing the Game Session (the reference timestamper uses sashite:session), mirroring the pattern used for per-Ply attestations — and, as there, the designated timestamper MUST include it (kind 3423 §Time accounting). NIP-26-delegated signatures from the timestamper are NOT accepted as authoritative.

Note: this NIP does not subject the Adjudication Request to race resolution. The protocol explicitly allows multiple Adjudication Requests per session. An arbiter MAY select any conforming Request as the triggered_by reference of their Adjudication (kind 3425); canonical timing provides authoritative ordering but no canonical “winner” — the Request defines no slot in the sense of Canonical Timing §Meta-resolution.

This selection is verdict-relevant — the chosen Request fixes the natural-state cutoff (kind 3425 §Natural state of events at adjudication), and two Requests can yield different verdicts — so arbiters SHOULD publish a deterministic selection policy (e.g., the earliest canonically timed conforming Request first — the reference arbiter’s rule). The selection is not a conformance condition of the resulting Adjudication.

The Adjudication Request’s own created_at is informational only and MUST NOT be used for any timing-dependent decision.

Tags

Reference tags

Tag	Cardinality	Value	Description
e game_session	exactly one	event id, optional relay hint, marker	reference to the Game Session (kind 3422) for this session

The e tag MUST be differentiated by a marker as the fourth element:

• ["e", "<game_session_event_id>", "<relay_hint>", "game_session"] — the Game Session event (kind 3422) for this session. Exactly one such tag is required.

The relay hint (third element) is OPTIONAL but SHOULD be present.

Player tag

Tag	Cardinality	Value	Description
p	one or more	pubkey, optional relay hint, role marker	the designated arbiters, one tag each, with role marker arbiter

Each p tag MUST carry the arbiter role marker as its fourth element, and there MUST be exactly one such tag per member of the session’s designated arbiter set (kind 3422 §Arbiter set):

["p", "<arbiter_pubkey>", "<relay_hint>", "arbiter"]

The relay hint (third element) is OPTIONAL but SHOULD be present. When omitted, an empty string MAY be used in its position.

The p tags serve a dual purpose: semantic (identifying the arbiters) and structural (notification routing via standard Nostr #p filters — every member of the set is notified by one Request, so the first to act can rule).

Lifecycle tag

Tag	Cardinality	Value	Description
nonce	exactly one	nonce + difficulty	NIP-13 proof of work

The nonce tag follows NIP-13.

Content

The content field MUST be the empty string ("").

The Adjudication Request carries no narrative payload: an arbiter rules on what is signed and published, not on what the invoker asserts. Any non-empty content would either be ignored (creating a misleading impression of relevance) or, if a future client parsed it, introduce a side channel for claims that have no normative weight. Forcing the empty string removes this ambiguity.

The empty invocation forces a corresponding requirement on the arbiters: since an invocation asserts nothing, the status vocabulary MUST be decidable from the published events alone — every verdict an arbiter can reach is a function of the natural state and the session’s public events, never of who invoked, why, or of any out-of-band claim. A vocabulary satisfying this requirement makes every conforming, canonically timed invocation interpretable without application-specific context (the reference rule system’s supporting document, Statuses — Sanki, is one conforming vocabulary; its residual-resignation rule guarantees that such an invocation always yields a verdict).

Players who wish to communicate context to an arbiter SHOULD do so out of band; this NIP intentionally provides no in-band channel for such communication.

Semantic constraints

A conforming Adjudication Request event MUST satisfy all of the following:

1. The event contains exactly one game_session-marked e tag.
2. The game_session e tag references a retrievable, signature-valid, conforming Game Session event (kind 3422, per its §Semantic constraints) that is the canonical Game Session for its founding (kind 3422 §Idempotence and race resolution).
3. The event’s pubkey (the invoker) MUST match the pubkey of one of the player-marked p tags in the referenced Game Session (i.e., the invoker is one of the session’s players).
4. The event’s p tags (each carrying the arbiter role marker as its fourth element) MUST be, as a set of pubkeys, exactly the arbiter-marked pubkeys of the referenced Game Session (kind 3422 §Arbiter set) — one tag per member, no member omitted, none added.
5. Exactly one nonce tag is present, carries its committed difficulty as its third element, and the event id satisfies NIP-13 against that committed difficulty — never against a relay’s advertised minimum (an ingestion policy, not conformance).
6. The content field is the empty string ("").

Constraints 1, 5, and 6 are checkable from the event alone. Constraints 2–4 require cross-event validation against the referenced Game Session.

Validation responsibility

Validation of an Adjudication Request against the semantic constraints (§Semantic constraints) is the responsibility of the client, the relay, and the arbiters. A relay additionally enforces its advertised NIP-13 minimum difficulty at ingestion — a relay policy, distinct from conformance.

An arbiter MAY refuse to act on an Adjudication Request that fails the semantic constraints. Such refusal is communicated by the arbiters not publishing a corresponding Adjudication. This NIP does not define an explicit refusal event.

Examples

The examples below use placeholder pubkeys, event IDs, relay URLs, and timestamps for illustration.

Example 1 — Invocation by the challenged player

Bob (the challenged player) requests adjudication:

{
 "kind": 3424,
 "pubkey": "<bob_pubkey>",
 "created_at": 1700005000,
 "tags": [
 ["e", "<game_session_event_id>", "wss://relay.example.com", "game_session"],
 ["p", "<carol_pubkey>", "wss://relay.example.com", "arbiter"],
 ["nonce", "73219", "16"]
 ],
 "content": "",
 "id": "...",
 "sig": "..."
}

An arbiter, on receiving this request, examines the natural state of events and produces an Adjudication.

Example 2 — Invocation by the challenger

Alice (the challenger) requests adjudication:

{
 "kind": 3424,
 "pubkey": "<alice_pubkey>",
 "created_at": 1700001000,
 "tags": [
 ["e", "<game_session_event_id>", "wss://relay.example.com", "game_session"],
 ["p", "<carol_pubkey>", "wss://relay.example.com", "arbiter"],
 ["nonce", "11337", "16"]
 ],
 "content": "",
 "id": "...",
 "sig": "..."
}

An arbiter examines the natural state of events and rules accordingly.

Client guidelines

Clients implementing kind: 3424 SHOULD:

1. Subscribe to kind 3424 events with a #p filter on the user’s pubkey to receive Adjudication Requests addressed to the user as one of the arbiters; before ruling, check whether another member of the set has already published an Adjudication for the session (kind 3425 §Idempotence).
2. Subscribe to kind 3424 events with an #e filter on the user’s Game Session event IDs to receive notifications of invocations on the user’s own sessions.
3. Validate received Adjudication Request events against the semantic constraints (§Semantic constraints) before treating them as actionable. In particular, reject any event whose content is non-empty.
4. Set the content field to the empty string when publishing a request; do not offer a UI affordance for attaching a message.

Security considerations

• Signatures: Adjudication Request events are signed by the invoker. An arbiter MUST verify signatures per NIP-01 before treating the request as actionable.

• Proof of work: The nonce tag follows NIP-13 and protects the arbiters from spam invocations. Relays SHOULD enforce a minimum difficulty appropriate to their policy. The nonce values shown in this NIP’s examples are illustrative placeholders; real implementations compute the nonce via proof-of-work brute force until the event ID achieves the target leading-zero-bit difficulty.

• Cross-event validation: An Adjudication Request is meaningful only in conjunction with its referenced Game Session (kind 3422). An arbiter MUST retrieve and validate this reference before issuing a ruling.

• No claims, no accusations: The Adjudication Request carries no claims, accusations, or asserted outcomes. An arbiter rules based on the natural state of signed and published events. The content field is forced to the empty string (§Content) to remove any in-band channel that could be mistaken for a structured claim.

• Multiple invocations: A session MAY receive multiple Adjudication Request events (e.g., both players invoke independently, or one player invokes from multiple client instances). The ruling arbiter selects one as the triggered_by of their verdict and rules on the natural state of events at that Request’s cutoff. The selection is verdict-relevant; arbiters SHOULD publish a deterministic policy (see §Attestation by the designated timestamper).

• Arbiter availability: This NIP does not provide a mechanism for an arbiter to acknowledge receipt of a request. An invocation that receives no corresponding Adjudication may be due to arbiters that are offline, overloaded, or have rejected the request as malformed; a set of several designated arbiters is the structural mitigation, since one Request reaches them all.

• Invocation timing: In attested mode, the Adjudication Request’s own created_at is the invoker’s claim and is not authoritative; the ruling arbiter relies on the Request’s canonical timing — the Event Timestamp Attestation (kind 3410) signed by the designated timestamper. In self-timed mode, the canonical timing IS the Request’s own created_at, made non-backdatable by the designated timing relay. Either way, the arbiter’s observation of the request’s arrival is implicit in the Verdict (via the triggered_by reference).

• Arbitration scope: This NIP does not define the ruling itself. The ruling arbiter’s response — including the result format and finality semantics — is defined in the Adjudication NIP (kind 3425).

References

• NIP-01 — Basic protocol flow description
• NIP-13 — Proof of Work
• Kind 3422 — Game Session (the session being adjudicated)
• Kind 3425 — Adjudication (an arbiter’s verdict, triggered by this Request)
• Event Timestamp Attestation — primitive for the Adjudication Request’s attestation (attested mode)
• Canonical Timing — canonical timing and meta-resolution (kind 3424 is timed but defines no slot)