A deleted account's label is burned for good (FormerAccount, crates/didbot-pds/src/names.rs). Only an operator's hard delete frees one, after a 30-day hold (DEFAULT_HOLD). The default mineral+creature pool "starts failing to issue one near 11_000" (crates/didbot-config/src/sections.rs, max_accounts docs). So the pool is spent by cumulative account creations, whatever the live count.
Arithmetic, not measured:
- At the pre-cleanup rate of about 110 creations a day, 11,000 names last about 100 days.
- At 10x (about 1,100 a day) they last about 10 days.
- An ordinary delete, like most of a cleanup, frees no names.
- Production already shows a numbered retry name (
aquamarine-kodkod-2).
Options: add +n to the default spec (it never runs out, but discloses the creation count), add a third word list, or report pool use in stats so an operator sees it coming. Which name a deployment discloses is the owner's call.
Still real on main at 1351e8b33. The code change is small, but it is a naming decision for the owner, as the issue says:
+ndiscloses the creation count, and a third word list changes every new name. An operator can already avoid it today by setting a pool's spec, for examplemineral+creature+n, in config. Reporting pool use is a new stats field, so it needs review of whatbot.did.statspublishes.