Paxos Gold (PAXG) — what its owner can do

Ethereum · 0x45804880de22913dafe09f4980848ece6ecbaf78
Read from the chain on 2026-10-14. All checks completed.

This address is a proxy. The checks below were run against the implementation it delegates to, 0x7da4c5d9eca180a03765a6d27196f2a0380fa543, since that is the code that actually runs.

Who can do these things

The permissions above rest with 0x6D8B8f7eBD9860E80694665f05033dF06ddC3acC, itself a contract, which may be a multisig or a timelock. Whether that is acceptable depends on who holds it.

  • 0x6D8B8f7eBD9860E80694665f05033dF06ddC3acC — a contract, possibly a multisig. Found via owner().

Only named getters were read. If this contract uses role-based access control without enumeration, its role holders cannot be listed, and the absence of a controller here does not mean there is none.

What the contract permits

Present

Can new tokens be created?

New tokens can be created after deployment.

Whoever holds that permission can increase the supply, which reduces the share each existing token represents.

  • mint(address,uint256)

Whether minting has been used, and under what constraints, is not established here.

Present

Can transfers be blocked?

Transfers can be blocked by whoever holds the relevant permission.

If the mechanism is applied to your address, or to the pool you would sell into, you would be unable to sell.

  • Pause controls: pause(), unpause()
  • paused() currently returns false

This reports what the contract permits. Whether any address is currently blocked was not checked.

Not present

Is there a trading tax?

No trading tax mechanism was found.

  • No tax setter or tax rate in the ABI
Present

Can the contract logic be replaced?

The contract logic can be replaced.

Everything else described here reflects the code running today, and could be changed by whoever holds the upgrade rights.

  • The block explorer resolves this as a proxy for 0x7da4c5d9eca180a03765a6d27196f2a0380fa543
  • It uses a non-standard storage slot, so the upgrade rights could not be read on-chain

Who holds the upgrade rights was not determined.

Present

Is the liquidity locked?

The trading liquidity can be withdrawn by whoever holds the LP tokens.

Withdrawing liquidity leaves holders with tokens and no pool to sell them into. This is the mechanism behind most losses described as rug pulls.

  • Uniswap V2 WETH pool at 0x9C4Fe5FFD9A9fC5678cFBd93Aa2D4FD684b67C4C: 3,102 WETH of depth, 0% of its LP supply burned
  • Uniswap V2 USDC pool at 0x6D74443bb2d50785989a7212eBfd3a8dbABD1F60: 4,728 USDC of depth, 0% of its LP supply burned
  • Uniswap V2 USDT pool at 0xf3f8a942f9d0827D32ea1b9f1A0724b5FA7397dB: 0.0364 USDT of depth, 100% of its LP supply burned
  • SushiSwap WETH pool at 0xf957FC1B6Ed557c698Ed6f1D336e00f306773975: 0.1216 WETH of depth, 0% of its LP supply burned
  • SushiSwap USDC pool at 0x56983Afc748EE88D695F1BcF8d8Fa25831a71a21: 0.2206 USDC of depth, 0% of its LP supply burned

Who holds the unburned LP tokens cannot be established: ERC20 holders cannot be enumerated over RPC. It may sit in a time-lock contract, or in a wallet, and this check cannot tell those apart.

This is not advice, and it is not complete. It reports what the contract allows and who can act on it. It cannot tell you whether anyone intends to. Treat a clean report as the absence of one kind of evidence, not as a recommendation.

Check another

← Back to the checker