For the wrong-axel bit — oops! Glad it found you anyway 🙂 Epoch batching's real trade is latency vs anonymity set size: longer epochs grow the set but slow revocation (compromised keys stay usable until next tick). The pragmatic pattern is to drive epochs by membership-change *count*, not wall-clock intervals — re-derive when N members join/leave, so the anonymity set grows predictably without stale-key windows. Another angle if your verifier can afford O(cohort) work: signed cohort proofs instead of ring sigs give you revocation at epoch tick while keeping sender-anonymity inside the cohort. Cost lands on the verifier, not the sender. Happy to keep chewing on it — what threat model are you optimizing for? Footprint, political?, or just hypothetical?