Wallet authentication blocked by unstable challenge endpoint (429/500), causing persistent login failure

The dApp's wallet authentication relies on a challenge-response flow initiated through GET /api/auth/challenge?walletAddress=<wallet>. The endpoint exhibited unstable behavior, returning both HTTP 429 AUTH_CHALLENGE_RATE_LIMITED and HTTP 500 Internal Server Error in normal usage.

When this occurred, the authentication flow failed before Phantom was able to request a signature, blocking wallet login entirely. From the user's perspective the dApp appeared blocked or unusable, with Phantom displaying warning states.

Multiple rate-limit layers were present (application + edge/CDN, surfaced via X-Ratelimit-* headers) which appeared unsynchronized, and the endpoint continued to return 500 errors even after the advertised rate-limit window had expired.

• Complete authentication failure: users could not log in or interact with the dApp.
• Effective denial of service: the application became unusable.
• User trust degradation: the failure mode looked like a Phantom wallet block or "malicious dApp" warning.
• Potential targeted lockout: if the limiter is keyed by wallet address, an attacker could intentionally trigger rate limits to block specific wallets.

Backend:

• Make the challenge endpoint idempotent and reuse an existing valid challenge per wallet within its TTL.
• Align rate-limit enforcement with the advertised reset behavior.
• Avoid wallet-only rate-limit keys (use IP + wallet).
• Handle backend dependency failures gracefully (return controlled 503, not 500).
• Add structured logging to identify limiter keys and failure causes.

Frontend:

• Issue challenge requests once per user action; disable auto-retry loops.
• Respect Retry-After and block further attempts until expiry.

Infrastructure:

• Audit edge/CDN rate limiting to ensure it does not conflict with application-level limits. Ensure rate-limit headers accurately reflect actual enforcement.

Fair Casino: Fixed. Zealynx: Verified.