Do not turn an RPC failure into a non-holder decision.

ANTI-PATTERN

Returning false or zero on RPC failure can revoke legitimate access

A common token-gating helper catches a readContract or balanceOf failure and returns false or 0. That is convenient for UI display code, but dangerous when the value controls authorization.

If the same helper feeds a protected route, holder-only action, periodic recheck or kick flow, an RPC outage can be interpreted as a real non-holder result.

try {
  const balance = await token.balanceOf(wallet);
  return balance >= minimum;
} catch {
  return false; // infrastructure failure now looks like a real denial
}

THREE STATES

Authorization needs allowed, denied and error

A trustworthy authorization boundary should distinguish a conclusive policy miss from a verification failure.

AccessVerdict returns allowed when the policy is proven true, denied when the policy is conclusively false, and error when the verifier cannot establish a trustworthy answer.

allowed -> continue
denied  -> 403 access_denied
error   -> 503 verification_unavailable

NEXT.JS

Use the route guard at the protected server boundary

The Next.js/Node guard maps a real policy denial to HTTP 403 and verification or adapter failure to HTTP 503. The caller can retry an infrastructure failure without pretending the wallet failed the policy.

import {
  createAccessVerdictRouteGuard,
  accessVerdictGuardResponse,
} from "@accessverdict/sdk";

const guard = createAccessVerdictRouteGuard({
  apiKey: process.env.ACCESSVERDICT_API_KEY!,
  policyId: process.env.ACCESSVERDICT_POLICY_ID!,
});

const decision = await guard.authorize(wallet);
const blocked = accessVerdictGuardResponse(decision);
if (blocked) return blocked;

// Return the protected resource only after an allowed decision.

MIGRATION

Replace one existing holder check first

The smallest useful integration test is one existing authorization boundary that currently turns balanceOf into a boolean.

Keep wallet authentication, sessions and product logic unchanged. Replace only the token-ownership decision, then compare the custom RPC/error-handling code removed and the failure behavior before and after.

RECHECKS

Periodic holder rechecks should not false-kick users

This distinction matters even more in background rechecks. A temporary RPC outage should not be silently converted into a non-holder state that removes access or ejects a user.

Treat verification_unavailable as a separate operational condition and decide explicitly whether to retry, delay, alert or preserve the last known state according to your product's risk model.