Contract Powers Registry / polygon

USDT (Polygon)

0xc2132d05d31c914a87c6611c10748aeb04b58e8f on polygon

Can this code be replaced?

Yes — this is a proxy. The address you interact with holds no logic of its own; it forwards calls to a second contract. Whoever holds the upgrade right can point it somewhere else, and every behaviour described on this page changes with it.

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.

What this page did not categorise

1 more function here is restricted to a privileged role, and this engine has no category for it. The list above matches function names against a fixed set of power categories. These ones are gated in the published source — an only… modifier or a sender check — but their names match nothing, so no card was written for them. They are named here in full rather than dropped, because a report that looks complete is worse than one that says where it stops.

Where to start: 1 of these 1 are a repeating name shape — 1 sets a value — which usually means configuration rather than a new capability. The name shape is read from the name alone and claims nothing about behaviour; setOracle and setFeeRecipient share it and differ completely.

What to do with this: open the contract on the explorer and read this function. The gate shown is the exact text found in the source. This engine does not guess what the function does. Of the 27 state-changing functions in the published interface, 6 matched a known category and 1 is listed here.

Is there a bug bounty on this?

No live bug-bounty program matched this contract’s name in my index (169 Immunefi + 52 Cantina programs, rebuilt daily). Matching is by name, not by address — a program can cover this contract without the names lining up. Browse the full index at Bounty Radar.

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 1289 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.