Access Denied Error Explainer

WHAT IT DOES

Access Denied Error Explainer takes a pending or recent transaction hash and determines whether the sender has the required permissions to call the target contract function. Many contracts implement access control patterns such as OpenZeppelin's Ownable (onlyOwner) or AccessControl (hasRole) to restrict sensitive functions to specific addresses. If the sender lacks the required role, the transaction will revert with an "Ownable: caller is not the owner" or "AccessControl: account is missing role" error. This tool reads the transaction's target address and sender, then attempts to identify the contract's access control pattern by calling standard view functions: owner(), isOwner(), admin(), isAdmin(), hasRole(), and DEFAULT_ADMIN_ROLE(). It also decodes the function selector to identify which function is being called. Historical access control events (RoleGranted, RoleRevoked, OwnershipTransferred) are fetched using chunked log scanning to provide context on recent permission changes. The output includes the owner/admin address, the sender's permission status, any roles held, and a plain‑language explanation of whether the transaction will fail and what the user should do.

HOW TO USE

Paste any transaction hash into the input field, select the network, and click "Check access". The tool connects to your wallet via the EVM bridge (read‑only; it never signs or sends anything) to fetch the transaction details and the target contract's access control state. It attempts multiple standard access control functions (owner, isOwner, admin, isAdmin, hasRole) to maximize compatibility with both Ownable and AccessControl patterns. It also decodes the function selector to show which function the transaction is calling. Historical events are fetched in chunks (500 blocks per request) with automatic backoff and halving on failure to avoid public RPC caps. The AI layer generates a plain‑English summary: whether the sender has the required permission, what role is needed, and what action the user can take. You can click on the transaction hash or contract address to view them on the block explorer.

CHUNKED LOG SCANNING WITH BACKOFF FOR ACCESS EVENTS

Access control events are critical for understanding the state of roles and ownership, but public RPCs aggressively cap eth_getLogs block ranges. A naive full‑range request over 10,000 blocks will fail with a "block range too large" error. This tool automatically chunkes log requests into 500‑block slices to stay within safe limits for all major RPC providers. If a chunk fails (due to timeout or provider‑specific limits), it halves that chunk and retries recursively—ensuring that even with aggressive caps, the tool reliably retrieves all relevant events. This is essential for detecting recent RoleGranted, RoleRevoked, and OwnershipTransferred events that might have changed the sender's permissions since the transaction was constructed. The tool also caches the current block number at the start of the scan to maintain consistency across all requests.

WHAT IT CANNOT SEE

This tool cannot detect access denials that depend on off‑chain state (e.g., roles that are granted via off‑chain governance votes that haven't been executed, or permissions that depend on external oracle data). It cannot predict future role changes or ownership transfers that might occur before the transaction is mined—the check reflects the current block, not the future. It cannot verify that the sender intended to call the function despite lacking permissions—the tool reads what is on‑chain, not the user's intent. It cannot detect access control in contracts that use non‑standard patterns (e.g., custom modifiers that are not exposed via view functions, or role checks that are performed in assembly). It cannot guarantee that a retry will succeed even if the sender appears to have the required permissions, as other conditions (e.g., paused state, balance, allowance) may also need to be met. It cannot detect if the function is intentionally restricted as a security measure—this tool only checks whether the sender has the required permission based on the current contract state, it does not assess intent or risk. It also cannot detect access control in proxy contracts if the implementation's access control functions are not exposed through the proxy's own interface.

PLEASE NOTE

This tool works only for EVM‑compatible chains (Ethereum, Polygon, BSC, Arbitrum, Optimism, Avalanche C‑chain, etc.) and relies on standard access control function signatures (owner, isOwner, admin, isAdmin, hasRole). It does not support custom access control patterns that use non‑standard naming or storage. All explanations are AI‑generated from data the app reads on‑chain—the AI synthesizes the permission status, owner/admin addresses, event history, and transaction context into plain English, but it does not have special access to private contract logic or off‑chain data. Always review what you are actually signing in your wallet before approving any transaction; an access check does not replace your own verification of the transaction details, including the target contract and the function you are calling. This tool is provided free of charge, with no warranty of accuracy or completeness.