`ratePerDay` is stored, returned, advertised — and never enforced

[Miracle656]

Background

The per-key daily quota exists everywhere except where it would do something. It is a column with a default of 10000, settable via POST /admin/keys (src/api/admin.ts:59,71), returned in the admin response, settable from scripts/issue-api-key.ts, and loaded into the request context (src/api/auth.ts:14,51).

Then the rate limiter at src/index.ts:115-118 reads only req.apiKey?.ratePerMin with timeWindow: '1 minute'. Nothing in src/ references ratePerDay for enforcement. A key issued with --per-day 100 gets 60/minute, about 86,400 a day.

Acceptance criteria

• A daily counter is enforced per API key and survives a process restart
• Exceeding it returns 429 with a retryAfter pointing at the next day boundary, matching the existing error shape
• The per-minute limit keeps working unchanged
• Tests: under limit passes, over limit 429s, counter resets at the boundary
• Redis being unavailable does not silently disable the quota — decide fail-open or fail-closed and document it

Drips Wave · Complexity: Intermediate · 150 points

---

The shape of the problem

Lens aggregates SDEX trades and AMM pool prices into VWAP, OHLCV and best-route data. It is in good shape on the surface — 47 test files, 401 passing tests, a clean typecheck, changesets, OpenAPI publishing, Prometheus metrics.

Underneath it is two codebases wearing one coat. Everything written since the dual-network work (#113–#118) is network-aware. Everything written before it silently pools testnet and mainnet: exactly one of roughly twenty data-reading modules filters by network. Several issues below are that seam.

State of main before you start

Verified on 2026-09-24: npx tsc --noEmit exits 0, and npx vitest run gives 400 passed, 1 skipped, green across seven consecutive runs.

So two open issues are stale and should not scare you off:

• Fix broken @stellar/stellar-sdk vitest mock — makes every PR look red #146 ("broken @stellar/stellar-sdk vitest mock makes every PR look red") does not reproduce on main.
• Flaky test suite: auth.test.ts and pairs.test.ts fail intermittently (~1 in 5 runs) #151 ("flaky suite, fails ~1 in 5") did not reproduce in seven runs. The underlying hazard is real though: src/config.ts:245-253 memoises each NetworkConfig in a module-level Map on first access, so whichever test file imports first freezes process.env for every other file.

#113 ("restructure config.ts into a per-network map") is already fully implemented at src/config.ts:97-315.

Ground rules

• Every PR needs a test that fails before the change and passes after, unless the issue says otherwise.
• A price with the wrong units, the wrong network or the wrong timestamp is worse than no price. Prefer refusing to answer over answering confidently.
• Don't widen a Prometheus label to something unbounded. Pairs and networks are fine; issuers and pool ids are not.
• Don't reformat a file you're changing.

---

---

Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk

[beebah30]

@beebah30 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hi Maintainer, I’ve carefully examined the requirements and have a good understanding of the problem. I’m ready to work on a solution that addresses the issue and satisfies the specified criteria.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @beebah30 to this issue.

[Emmo00]

@Emmo00 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

I’d like to work on this because it’s a backend rate-limiting task involving Redis-backed state, API-key enforcement, and reliable quota handling. I have experience building Node.js/TypeScript APIs, Redis integrations, authentication systems, and production infrastructure, so I can implement the daily quota without disrupting the existing per-minute limiter. Could you assign this issue to me?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Emmo00 to this issue.

[funds0033-cmyk]

@funds0033-cmyk has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Pls I will like to work on this pls kindly assign

ℹ️ Repo Maintainers: To accept this application, review their application or assign @funds0033-cmyk to this issue.

[drips-wave]

Congratulations, @beebah30! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.

🧑‍💻 @beebah30: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊