Amp (AMP) — what its owner can do
Who can do these things
The permissions above rest with 0x533a36b5e56C1f0361a53d4395F4F0c5f1AD63f8, itself a contract, which may be a multisig or a timelock. Whether that is acceptable depends on who holds it.
0x533a36b5e56C1f0361a53d4395F4F0c5f1AD63f8— 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
Can new tokens be created?
The supply is fixed. No function exists to create new tokens.
- No mint entry point in the contract ABI
Can transfers be blocked?
No mechanism was found that would let anyone block a transfer.
- No address blocking, pause, trading switch or transfer cap in the ABI
Is there a trading tax?
No trading tax mechanism was found.
- No tax setter or tax rate in the ABI
Can the contract logic be replaced?
The contract logic is fixed and cannot be replaced.
- No proxy pattern detected in the deployed bytecode
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 0x08650bb9dc722C9c8C62E79C2BAfA2d3fc5B3293: 12.2831 WETH of depth, 0% of its LP supply burned
- SushiSwap WETH pool at 0x15e86E6f65EF7EA1dbb72A5E51a07926fB1c82E3: 18.1887 WETH 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.