TrueUSD (TUSD) — what its owner can do

Ethereum · 0x0000000000085d4780b73119b644ae5ecd22b376
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, 0xdbc97a631c2fee80417d5d69f32b198c8c39c27e, since that is the code that actually runs.

Who can do these things

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

  • 0x0000000000075EfBeE23fe2de1bd0b7690883cc9 — 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.

  • Address blocking: setBlacklisted(address,bool)

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 0xdbc97a631c2fee80417d5d69f32b198c8c39c27e
  • 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 0xb4d0d9df2738abE81b87b66c80851292492D1404: 2.1768 WETH of depth, 0% of its LP supply burned
  • Uniswap V2 USDC pool at 0xf1f27Db872b7F6E8B873C97F785fe4f9a6C92161: 2,106 USDC of depth, 0% of its LP supply burned
  • Uniswap V2 USDT pool at 0x615Cc08dF9084e3faC80FE19045A55612185B6a4: 0.0127 USDT of depth, 100% of its LP supply burned
  • SushiSwap WETH pool at 0x760166FA4f227dA29ecAC3BeC348f5fA853a1f3C: 2.4021 WETH of depth, 0% of its LP supply burned
  • SushiSwap USDC pool at 0x45679D087f7e01E517204b78825Faf0F68C19CBc: 0.0018 USDC of depth, 0% of its LP supply burned
  • SushiSwap USDT pool at 0x6D0083Fb8c8d4c62441FeE5B5be2CC21182b5FE3: 0.0002 USDT 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