RPC timeouts, Rate limiting, and Cache: A Week in Review

[collinsezedike]

A batch of fixes shipped this week covering RPC timeouts, rate limiting, error handling, caching, and input validation.

Soroban RPC timeouts (#217, #218, #229)
All Soroban RPC calls on both the read and write paths now have explicit timeouts. Previously, a slow or unresponsive RPC node could hang a request indefinitely until Vercel's function deadline fired. Calls now fail fast with a readable error.

Rate limiting (#209, #210)
Rate limiting is now applied to GET /vaults and GET /positions. Previously only the transaction routes were protected. The limit is aligned to 100 requests per minute across both the Fastify server and Vercel handlers so both environments behave identically.

Error handling and security (#206, #215)
RPC URLs and contract addresses are scrubbed from 500 error responses, so a failed request does not expose internal infrastructure details. Error handling has also been added to the Fastify vaults routes so unhandled rejections no longer crash the server silently.

Cache fixes (#204, #205, #214)
Cache-Control headers are now set correctly on the vaults endpoints. The cache hit status is reported accurately rather than hardcoded to false. The DeFiLlama cache no longer overwrites a warm cache with an empty result when the upstream returns nothing; the previous data is served instead.

Input validation (#207)
The vaultId query parameter is now validated before use. Passing an invalid type previously produced a confusing downstream error.

---

Issues: github.com/drydocs/meridian/issues

Back to building.
— Collins