Contract Powers Registry / ethereum

Uniswap V2 Router 02

0x7a250d5630b4cf539739df2c5dacb4c659f2488d on ethereum

Can this code be replaced?

No proxy pattern found. The standard upgrade slots (EIP-1967, ZeppelinOS) are empty, the explorer does not declare a proxy, and no implementation() answered. The code at this address is very likely the code that runs. Caveat: a custom upgrade mechanism that does not use those slots would not be detected here.

Who holds the keys?

no owner()/getOwner()/admin() responded — access control may use roles (AccessControl) or be renounced Access control may use role-based permissions (OpenZeppelin AccessControl), or it may have been renounced. This registry does not enumerate role holders.

What the privileged role can still do

Each card is a capability found in the code. declared = the contract’s published interface exposes it. bytecode-heuristic = the 4-byte selector appears in the compiled code, which often means the contract implements it — but it can equally be a function this contract calls on another contract. Only a verified source settles that.

Nothing confirmed here. Every match below is heuristic. A swap router, for example, carries mint(address) because it calls mint on a pool — not because it can mint anything itself. Treat these as leads to check, not as findings.

What this page did not categorise

Nothing was dropped. Every state-changing function that the source restricts to a privileged role also matched one of the categories above — 0 of 17 functions in the published interface. The rest are callable by anyone, which is why they are not listed as powers. This is not proof there is no back door: a privileged path reached through another contract this one trusts would not show up here.

Is there a bug bounty on this?

The contract name matched 1 live program(s) in my Bounty Radar index. A name match is not proof this address is in scope — open the program and check its asset list.

Raw facts

Has any of this changed?

This page is rebuilt from the chain and diffed against the previous day. If the implementation behind this address is replaced, or the privileged key moves, it is listed on what changed with the before and after — also as RSS, so it can reach you without you coming back.

How this was produced, and what it cannot tell you

Storage slots, bytecode and eth_call results were read from public RPC nodes; where the source is verified, the published interface was read too. Nothing here is copied from another site’s opinion. Generated in 700 ms on 2026-10-12.

• confidence="declared" means the ABI exposes the function. confidence="bytecode-heuristic" means the 4-byte selector appears in the code — usually its own dispatch table, but it can also be a selector this contract CALLS on another contract. Only a verified ABI settles it.
• admin.controller identifies a Safe-style multisig, an OZ timelock, or an owned admin contract by the functions it answers. A contract that answers none is reported as unknown-contract, not as safe.
• bounty.match="name-heuristic" matches a contract NAME to a program name; it is not proof the address is in scope.
• coverage.unclassifiedOwnerOnly lists functions the source restricts to a privileged role but which match no power category here. It is read from the verified source by matching function name + argument count, so an overloaded or inherited function can be attributed imprecisely. When coverage.checked is false the engine could not read the source at all, and the power list must be treated as a floor.

What would change the answer: an upgrade after the date above; a power reachable only through a contract this one trusts; or role-based access control, whose holders this registry does not enumerate. Re-read the chain before you rely on it.