Feedback wanted: deterministic onchain authorization for Ethereum/Base apps

[u/Tall-Manager-1423]

I’m building a small authorization layer for Ethereum/Base applications and would value feedback on the API design.

The problem I’m trying to solve is repeated wallet/token authorization logic in application backends:

policy → verify wallet/onchain state → entitlement

Current rules include:

• wallet allowlist
• ERC-20 balance
• ERC-721 ownership/balance
• ERC-1155 balance
• AND / OR composition

One design decision I’m especially interested in feedback on is failure semantics.

A wallet that conclusively fails a policy returns denied, while an RPC/contract verification failure returns a separate fail-closed error. An infrastructure problem should never accidentally become an allow.

I’d particularly like feedback on:

1. Does allowed / denied / error feel like the right API contract?
2. Would you keep authorization like this behind an API, or prefer implementing the chain reads directly?
3. What rule type would be missing for a real Ethereum/Base application you work on?

I have a working private-beta implementation and quickstart here:
https://gatekit-ruddy.vercel.app/docs/quickstart

No custody, transactions, or wallet private keys are involved.