Beacon Proxy Checker

What this tool does

The Beacon Proxy Checker reads a contract address and tells you specifically whether it resolves through an EIP-1967 beacon, which beacon contract it shares, and what implementation that beacon currently points to. It’s the same resolution engine behind the general Proxy Detector, narrowed to the one question that matters when you’re staring at a suspected beacon proxy: if I call this address, whose logic actually runs, and how many other contracts run that same logic?

How to use it

1. Paste the contract address into the form above, or pick the pre-loaded demo: The Sandbox’s avatar beacon proxy on Ethereum.
2. Pick the chain the contract is deployed to.
3. Run the query and read the resolved chain. A Beacon proxy shows two hops: the proxy pointing at its beacon, then the beacon pointing at the implementation it currently serves.

If the address isn’t a beacon proxy, the result panel says so and shows whatever pattern it did match instead, or reports that calls execute directly on the address with no proxy involved. A raw JSON toggle at the bottom shows the full response for debugging.

What is happening under the hood

Most proxy standards store an implementation address directly in the proxy’s own storage. A Beacon proxy does something different: its EIP-1967 beacon slot holds the address of a separate beacon contract, and the proxy asks that beacon for the implementation address on every call rather than keeping its own copy. The beacon contract itself is usually a small, purpose-built piece of code exposing an implementation() getter, nothing more.

This indirection exists for one reason: fan-out. A protocol that deploys many near-identical contracts, one per user, one per NFT collection, one per avatar, can point every instance at the same beacon. Upgrading the beacon’s stored implementation instantly changes the logic every proxy runs on its next call, without touching a single byte of any individual proxy’s storage. The Sandbox uses exactly this pattern for its avatar contracts: each user’s avatar is a thin proxy pointed at a shared beacon, so The Sandbox can ship a logic upgrade once and have it apply across every avatar in circulation.

evmquery resolves this server-side with the same resolution include used across all proxy detection on this site:

POST /query/describe
{
  "chain": "evm_ethereum",
  "schema": { "contracts": { "target": { "address": "0x..." } } },
  "include": ["resolution"]
}

• resolution.route is an ordered list of hops. For a beacon proxy, the first hop has kind: "eip1967-beacon" and a to address pointing at the beacon contract, not the implementation.
• The second hop has kind: "beacon-implementation", and its to address is the actual implementation the beacon currently serves. This is the address whose code runs when you call the original proxy.
• An empty route means the address isn’t a proxy at all. A route that starts with a different kind, eip1967, eip1822, eip2535-diamond, and so on, means it matched a different pattern; the Proxy Detector resolves all of them in one place.

Build this yourself

Each snippet below makes the same POST call to the evmquery REST API, then walks the returned route looking specifically for a beacon hop followed by its implementation hop. The example targets The Sandbox’s avatar beacon proxy on Ethereum, the same contract loaded by default in the tool above.

REST (curl)

curl -X POST https://api.evmquery.com/api/v1/query/describe \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "evm_ethereum",
    "schema": {
      "contracts": { "target": { "address": "0x8712238c3CCE66f7207e60BdaBF615D9A9C3d299" } }
    },
    "include": ["resolution"]
  }'

Python

import requests

resp = requests.post(
    "https://api.evmquery.com/api/v1/query/describe",
    headers={"x-api-key": "YOUR_API_KEY"},
    json={
        "chain": "evm_ethereum",
        "schema": {
            "contracts": {"target": {"address": "0x8712238c3CCE66f7207e60BdaBF615D9A9C3d299"}},
        },
        "include": ["resolution"],
    },
    timeout=10,
)
data = resp.json()
route = data["contracts"][0]["_extension"]["resolution"]["route"]

beacon_hop = next((hop for hop in route if hop["kind"] == "eip1967-beacon"), None)
impl_hop = next((hop for hop in route if hop["kind"] == "beacon-implementation"), None)

if beacon_hop and impl_hop:
    print(f"Beacon: {beacon_hop['to']}")
    print(f"Implementation served by beacon: {impl_hop['to']}")
else:
    print("Not a beacon proxy")

TypeScript

const resp = await fetch("https://api.evmquery.com/api/v1/query/describe", {
  method: "POST",
  headers: {
    "x-api-key": process.env.EVMQUERY_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    chain: "evm_ethereum",
    schema: {
      contracts: {
        target: { address: "0x8712238c3CCE66f7207e60BdaBF615D9A9C3d299" },
      },
    },
    include: ["resolution"],
  }),
});
const schema = await resp.json();
const route = schema.contracts[0]._extension.resolution.route as {
  kind: string;
  to: string;
}[];

const beaconHop = route.find((hop) => hop.kind === "eip1967-beacon");
const implHop = route.find((hop) => hop.kind === "beacon-implementation");

if (beaconHop && implHop) {
  console.log(`Beacon: ${beaconHop.to}`);
  console.log(`Implementation served by beacon: ${implHop.to}`);
} else {
  console.log("Not a beacon proxy");
}

The free tier has no monthly cap. Get a free API key to drop these snippets into your project.

When you would use this

• Auditing a single instance from a larger fleet. If a contract is one of many proxies sharing a beacon, its behavior today is only as trustworthy as the beacon it defers to. Resolving the beacon hop tells you where the real upgrade authority sits.
• Confirming a shared-upgrade pattern before you build against it. If you’re integrating with a protocol that uses beacon proxies for per-user or per-item contracts, knowing the beacon address up front means you can watch that one address for future implementation changes instead of tracking every proxy individually.
• Ruling out the beacon pattern. Not every proxy that looks similar to a beacon setup actually uses one. A clean, non-beacon result tells you to look at Transparent, UUPS, or Diamond resolution instead.

FAQ

Limits and accuracy

• The result reflects the beacon’s stored implementation at the time of the read. A beacon’s implementation can change independently of any individual proxy, so a route resolved today may point somewhere else tomorrow.
• The demo is rate limited per browser. If you hit the limit, grab a free API key and the limit goes away.

Related

• Proxy Detector: check any proxy pattern, not just beacons, Transparent, UUPS, Diamond, and more, resolved in one place
• Diamond Proxy Checker: check for Diamond (EIP-2535) proxies instead, where calls fan out across many facet contracts rather than a single beacon
• evmquery for developers: the full integration story