What We Learned
A singleton service that issues scarce, cryptographically signed tokens needs three independent enforcement layers — not one. The golden-press service protects a hard cap of 5 Golden Tickets using: (1)pg_advisory_xact_lock(42) as a blocking transaction-scoped lock that serialises all issuance attempts, (2) an application-level count >= 5 guard that rejects before INSERT, and (3) a database CHECK (ticket_number <= 5) constraint as the final safety net.
Any single layer can be circumvented by bugs, race conditions, or operator error. All three together make double-issuance require simultaneous failures across the application, the lock, and the schema — which is the security posture a value-bearing token demands.
The JSON Envelope Pattern
The original scaffold used a canonical string format (ticket:{id}:user:{uid}:number:{num}:timestamp:{ts}) for Ed25519 signing. This was replaced with a JSON envelope {ticket_number, recipient, timestamp} that the signature field is appended to after signing. Verification strips the signature, rebuilds canonical JSON, and checks Ed25519.
The JSON envelope is better for downstream consumers because: any language with JSON + Ed25519 support can verify a ticket without parsing a custom format. The Verifier type is the SDK extraction point — only the 64-char hex public key is needed.