The Tokenized Bitcoin (imBTC) — what its owner can do
Who can do these things
The permissions above rest with 0xb9E29984Fe50602E7A619662EBED4F90D93824C7, a single private key rather than a multisig or a timelock. Whether that is acceptable depends on who holds it.
0xb9E29984Fe50602E7A619662EBED4F90D93824C7— a single private key, 754 transactions sent. 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?
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,bytes,bytes)
Whether minting has been used, and under what constraints, is not established here.
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: unpause(), pause()
- paused() currently returns false
This reports what the contract permits. Whether any address is currently blocked was not checked.
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 cannot be withdrawn: its LP tokens have been burned.
- Uniswap V2 WETH pool at 0x4d136871d5617019dfDB339A2CD7CB5a0b75E7F3: 1.51e-6 WETH of depth, 100% of its LP supply burned
Burned LP is unrecoverable by anyone, which is provable. This does not cover pools on exchanges outside those checked.