Description
Is your feature request related to a problem? Please describe.
In public-facing setups, it's currently difficult to prevent unauthorized users from interacting with arbitrary contracts via eRPC. For projects that only need to call their own smart contracts, this opens up a vector for misuse, rate exhaustion, or unintended access patterns.
Describe the solution you'd like
It would be great to support request-level access control in the eRPC auth config. Specifically, this means being able to define rules that allow or block requests based on:
- The target contract address
- The function selector or method signature being called
This would make it much easier for projects to enforce strict boundaries on what their endpoints are used for, especially when exposing them to the public.
Describe alternatives you've considered
One approach might be handling this at the application layer by proxying through a custom backend that filters requests. However, this reintroduces the kind of infrastructure eRPC was designed to simplify.
Additional context
This could potentially be implemented within the existing allow or ignore methods in the upstream configuration, offering a flexible and declarative way to define contract-level or method-level restrictions.
It would also be beneficial to support combining multiple authentication methods (e.g., domain-based, token-based, and request-content-based) for a single project—allowing for scenarios like different API keys having access to different contracts or function scopes.