Why ENS Availability Checks Get Throttled
Every ENS availability check is an RPC call to an Ethereum node. You ask the node to call the available(string) function on the ENS ETHRegistrarController contract and it returns a boolean.
Public RPC providers — Infura, Alchemy, llamarpc, and others — allow this, but they impose rate limits to prevent abuse. If you check 200 names in rapid succession, you will likely see:
- HTTP 429 (Too Many Requests) errors
- Timeout responses
- Blocked requests (some public RPCs are also blocked by certain ad blockers)
This is not a bug. It is deliberate traffic management.
Why Most Bulk Checkers Fail at Scale
Most bulk ENS checkers solve the rate limit problem by running checks through their own server-side infrastructure. This works up to a point, but introduces a new bottleneck: the server. If many users are checking at the same time, you queue up behind them. Server costs also get passed on through usage caps, paywalls, or registration requirements.
The other common approach is batching calls — using Multicall contracts to bundle many availability checks into a single RPC request. This helps, but you still hit limits at high volumes.
How This Tool Handles It
The checker on this site runs entirely in your browser. No server-side RPC calls, no shared infrastructure, no queues.
Under the hood, it does a few things to stay within rate limits:
Sequential processing with delays. Rather than firing all requests simultaneously, names are checked one at a time with a 200ms pause between each. This is slower than parallel requests, but it stays well within the limits of even restrictive public RPCs.
Exponential backoff on 429 errors. If a rate limit error comes back, the checker waits 1 second, retries, then waits 2 seconds on a second failure, then 4 seconds, and so on. This handles transient throttling without user intervention.
RPC fallback list. If one RPC endpoint returns repeated errors, the checker automatically rotates to an alternative. The fallback list includes multiple public Ethereum and Base RPCs to maximize uptime.
Because the checks run in your browser, your checks do not compete with other users. You are making direct RPC calls on your own behalf, not through a shared pool.
Practical Advice for Large Batches
If you are checking hundreds of names:
Break the list into smaller batches. 50–100 names at a time is comfortable. The sequential processing means 100 names takes roughly 20–30 seconds.
Keep the tab active. Browsers throttle JavaScript timers in inactive tabs, which can extend delays unpredictably. Keep the checker tab visible while it runs.
Check off-peak hours. Public RPC nodes are under heavier load during high Ethereum network activity. Checking during quieter periods reduces the chance of hitting rate limits.
For very large lists (500+), consider spreading checks over multiple sessions. There is no account or state on this tool — just paste and run. Split your list into chunks and run them sequentially.
What the Results Actually Mean
Availability is checked in real-time against the contract on each check. A name showing as available is genuinely free to register at that moment. A name showing as registered includes the expiry date, which tells you whether it might become available soon.
Names expire and re-enter the available pool constantly. If a name you want is registered but expiring soon, note the date and check back when it enters the grace period window.