SMS OTP as a ledger entry: one challenge, one send, and a server that owns expiry

The load-bearing artefact in this design is the event log, not the code generator. The write-up wants a reviewer able to follow issued, attempted, suppressed and verified events for one login without trusting a client timestamp ^[13], and the same record is what gives support a correlation ID and tells a reconciliation job what "one send" actually means ^[12]. That is the difference between a duplicate tap being a billing question and a billing dispute.

The race that makes it necessary is ordinary latency. Two requests carrying the same idempotency key arrive 40 milliseconds apart while the first worker is still blocked on the carrier adapter; the first reserves the challenge and the intent, the second reads that reservation and returns the same opaque identifier, and no second code is minted ^[10]. Verification is the mirror image: consuming the challenge has to be atomic, so two concurrent verifies cannot both win ^[5].

Now the arithmetic the invariant list does not do. The Go sketch mints six random digits and sets expiry five minutes out ^[15]. That is a million candidates, so a guesser needs roughly 500,000 tries for even odds, about 1,700 verify calls per second inside the 300-second window ^[1]. Comfortable, until you read the storage interface: it offers Create, Consume and CountResends, and nothing that counts failed verifications ^[2]. A resend cooldown and a rolling budget govern the request side ^[6]. They do not slow a guesser at all. If the client never decides whether a code is valid ^[4], the attempt ceiling has to live server side too, per challenge and per recipient, or the keyspace is the only control in the system.

Suppression is where the money failure and the privacy failure share a path. The article checks the suppression list before dispatch and again when delivery feedback is ingested, which is what catches bounces, reassigned numbers and manually blocked recipients ^[7]. The recycled number is the case worth writing down first: the code reaches whoever holds the handset now, and a recycled number sits alongside duplicate taps and delayed carrier messages as a route into account enumeration or SMS bombing ^[3]. Delivery feedback is the only evidence you get that a recipient moved, so one check before send is a check against a stale list.

Client-side OTP state is rejected for the reason you would expect: a rooted device can edit its clock or replay a request ^[8]. The concession is honest, though. It survives in an offline puzzle where validity carries no security meaning ^[8].

The response shape does real work here as well. Suppressed recipients, over-budget recipients and a storage failure all return the same generic accepted response ^[16], which pairs with a generic verify failure so the endpoint never reveals whether a number has an account ^[9]. The price is that callers stop being an information source. If the endpoint answers identically in every direction, your only view of abuse is the audit stream, which is where this design put it to begin with ^[1].