PRIVATE BETA
Replace custom token-gating code with one authorization API.
AccessVerdict turns wallet and token state into deterministic application permissions. We are inviting a small group of developers to test real integrations before public release.
Best for developers already building wallet-aware products
The beta is aimed at Next.js, Node.js, SaaS, community, dashboard and API developers who need access rules based on wallet allowlists, ERC-20 balances, ERC-721 ownership or ERC-1155 balances.
Base and Ethereum are supported first. AccessVerdict reads chain state only; it does not custody wallets, request private keys, trade, issue tokens or deploy contracts.
One real integration is more useful than ten Playground clicks
First prove an allowed and denied wallet in the Console. Then call the same policy from a trusted server route or backend using the REST API or server SDK.
We care most about time from signup to first useful verification, how much custom code AccessVerdict removes, and whether the allowed/denied/error model is easy to integrate correctly.
Send friction, not secrets
Useful feedback includes your framework, access rule, setup friction, whether you completed a server integration, and what would make you keep AccessVerdict instead of maintaining the authorization logic yourself.
Never send AccessVerdict API keys, wallet private keys, seed phrases or other credentials in feedback.
Submit integration feedbackAuthorization failures fail closed
A conclusive policy denial returns status: "denied". If chain verification cannot produce a trustworthy result, AccessVerdict returns status: "error" instead of silently granting access.
Project API keys are server-side credentials. Do not put them in browser JavaScript or NEXT_PUBLIC_* environment variables.
Target: first verification in under three minutes
Start with Wallet Allowlist so no RPC knowledge is required. Then test a Base or Ethereum token rule and move the policy into real server code.