Rate limit per app/api-key on the authed endpoint

[haardikk21]

Introduces functionality to rate limit on a per app or per API Key basis. Also enables being able to set ip rate limiting to 0 which effectively disables it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
rollup-boost	⬜️ Ignored (Inspect)	Visit Preview		Jun 12, 2025 3:31pm

[ferranbt]

Hey! In the same vein as #281 the initial goal is to keep in the proxy as little features as possible and build that in upper levels of the application stack.

I think adding API Keys adds more follow up problems like how do you manage those APIs.

[haardikk21]

Hey! In the same vein as #281 the initial goal is to keep in the proxy as little features as possible and build that in upper levels of the application stack.

I think adding API Keys adds more follow up problems like how do you manage those APIs.

Im not sure I get what you mean re: managing those APIs.

Since API keys already exist here, our plan was to run effectively two clusters of this proxy. One that is unauthenticated and used for a public endpoint with decent IP rate limits, and another that will be used by RPC providers and such that requires authentication and will have API key based rate limits instead of per IP

[haardikk21]

Also to add, since API keys are managed at the proxy level it imo makes sense to have rate limiting for them also be managed here. IP rate limits and API keys feels like a hacky combination which is why we did this.

For what its worth, its one of the last relatively significant changes on our radar right now we'd like to get in to the proxy before mainnet.

Most other pending work (eth_call support for example) is on the custom rpc node where we're converging and eventually want to adopt and contribute to the one youre working on separately instead of maintaining a different fork