Replace in-memory fixed-window rate limiting with Redis-backed sliding window, tiered endpoint limits, per-signer limits, and temporary banning. ## Acceptance Criteria - [ ] Redis added to `docker-compose.yml` with health check - [ ] Rate limiting uses Redis when available, falls back to in-memory when Redis is down - [ ] Sliding window algorithm (no fixed-window burst vulnerability) - [ ] Per-IP limits enforced for all endpoints - [ ] Per-signer limits enforced for API key-authenticated requests - [ ] Signing endpoints: 20 req/min, Auth: 10 req/min, General: 100 req/min - [ ] `X-RateLimit-Limit` and `X-RateLimit-Remaining` headers in all responses - [ ] `Retry-After` header in 429 responses - [ ] Temporary ban after 10 consecutive violations - [ ] All limits configurable via environment variables - [ ] Redis password support enabled ## Tasks - [ ] Add `redis` service to `docker-compose.yml` - [ ] Create `redis.module.ts` - [ ] Create `rate-limiter.service.ts` with sliding window + Redis - [ ] Rewrite `rate-limit.guard.ts` with tiers - [ ] Apply `@RateLimit()` decorators to signing, auth, DKG controllers - [ ] Write tests: sliding window, Redis fallback, 429 headers, temporary ban
Replace in-memory fixed-window rate limiting with Redis-backed sliding window, tiered endpoint limits, per-signer limits, and temporary banning.
Acceptance Criteria
docker-compose.ymlwith health checkX-RateLimit-LimitandX-RateLimit-Remainingheaders in all responsesRetry-Afterheader in 429 responsesTasks
redisservice todocker-compose.ymlredis.module.tsrate-limiter.service.tswith sliding window + Redisrate-limit.guard.tswith tiers@RateLimit()decorators to signing, auth, DKG controllers