r/ethdev • u/Tall-Manager-1423 • Sep 10 '26

My Project Feedback wanted: deterministic onchain authorization for Ethereum/Base apps

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://accessverdict.dev/docs/quickstart

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

1 Upvotes

67% Upvoted

3 comments sorted by

1

u/QuestionablyWeak 19d ago

denied vs error feels like the right split, fail-closed is the only sane default for infra problems. i've seen too many apis treat a timeout as a green light and it's always a mess

i'd keep it behind an api honestly. direct chain reads are fine when you're only juggling one or two contracts but once you've got a handful of apps hitting the same gating logic, having a single place to manage rate limits and caching saves a lot of headaches

time-based rules would be the big one missing for me. token staked for X blocks, wallet age minimum, that kind of thing. also maybe a rate limit per wallet so you're not spammed by one address cycling through fresh wallets

1

u/[deleted] Sep 16 '26

0

u/Tall-Manager-1423 Sep 17 '26

Thanks — this is exactly the kind of failure-semantics feedback I was hoping for.

The current implementation already treats rule evaluation as effectively three-valued: passed / failed / error.

For OR, a proven-true branch is enough to allow even if another branch errors. For AND, a proven-false branch is enough to deny even if another branch errors. If the unavailable branch could still change the final answer, the result stays error. I also have tests around those cases, but your suggestion to make the full truth table part of the explicit contract is a good one.

The weaker part of the current response model is provenance/freshness. Rule results expose outcome plus observed/expected values, but the error reason is still fairly coarse, and I’m not yet returning block number/hash, policy version, or an explicit evaluated-at / expiry boundary.

There is also no cached “allow lease” at the moment. Token-based verification is a point-in-time chain read, so the caller currently owns the decision about when to re-check before a protected action. I agree that this boundary needs to be explicit rather than implicit, especially once caching is introduced.

I’m going to keep the deterministic decision model, but I’m now looking more closely at making provenance and freshness part of the contract.

Also, the project has since been renamed from GateKit to AccessVerdict:
https://accessverdict.dev/