Announcement

Announcement is the only operation that identifies a device. It exists so issuance budgets can be enforced somewhere, and it does nothing else: it creates no mailboxes, grants no session, and returns no tokens.

A first-time announcement carries a proof of sequential work. The proof gates budget as much as registration, because a device that could cheaply mint identities could otherwise cheaply mint budgets.

Caution

Announcement is deliberately quarantined. It is the single place a server learns a Device Identity, and every other operation in this specification is designed so that knowledge is useless there. Do not extend it.

RequestAnnouncementChallenge

Obtains a challenge for a first-time announcement.

• Input: ChallengeRequest { public_key }
• Output: ChallengeResponse { challenge, iterations, expires_at }
• Auth: None
• Idempotent: No
• Errors: ANNOUNCEMENT_RATE_LIMITED, MALFORMED_REQUEST

Requirements

• Servers MUST generate challenge with cryptographically secure randomness
• Servers MUST bind the challenge to the submitted public_key and reject a proof presented under a different key
• Servers MUST expire a challenge within 5 minutes
• Servers MUST enforce MAX_CHALLENGES_PER_IP_PER_HOUR before generating a challenge
• Servers SHOULD scale iterations with current load

HTTP Binding

POST /api/v1/announce/challenge

AnnounceDevice

Registers a device record. Required before tokens can be issued.

• Input: AnnounceRequest { device_id, public_key, signature, timestamp, vdf_proof }
• Output: AnnounceResponse { device_id, expires_at }
• Auth: Device authentication
• Idempotent: By device_id - re-announcing extends the record
• Errors: ANNOUNCEMENT_RATE_LIMITED, VDF_PROOF_INVALID, CHALLENGE_EXPIRED, DEVICE_SIGNATURE_INVALID, DEVICE_ID_MISMATCH

Requirements

• Servers MUST verify device_id == Blake3(public_key) before anything else
• Servers MUST verify signature over device_id || timestamp against public_key
• Servers MUST reject a timestamp outside an acceptable window
• Servers MUST require vdf_proof on a first-time announcement and MAY ignore it thereafter
• Servers MUST check rate limits before verifying a proof
• Servers MUST NOT create mailboxes as a side effect
• Servers MUST NOT return tokens
• Device records MUST expire; 24 hours is the default

Note

Ordering is load-bearing. Verification re-computes the hash chain and costs the server as much as generation cost the client, so a server that verifies before rate limiting has built its own amplifier. Servers SHOULD ban a source presenting an invalid proof for BAN_DURATION_INVALID_PROOF.

HTTP Binding

POST /api/v1/announce

Renewal

A device record expires. Renewal is re-announcement with the same device_id, which extends expires_at and MUST NOT require a fresh proof - the device has already paid it, and its Trust Tier is computed from first announcement, not from the most recent one.

• Servers MUST retain first-announcement time across renewals
• Servers MUST NOT reset a device’s trust tier on renewal

What Announcement Does Not Do

Not this	Where it happens
Issue tokens	Tokens
Create a delivery address	Mailboxes
Establish a session	Nothing here holds sessions
Reveal the device to anyone else	Records are never exposed via API or federation