BITCOIN CONSUMPTION Honeypot

1. The constructor sets the deployer as moi, starts with trans = false;, grants the deployer the admin, pauser and minter roles, and mints the whole supply of 1,000,000,000,000 tokens to the deployer. It also creates the token's pair with the hard-coded router at 0x05fF2B0D…608C7F and stores it as uniswapV2Pair.
2. transferFrom is overridden with a gate: require (trans || moi == sender || moi == recipient || sender == UNI);, where UNI is uniswapV2Pair.
3. A sale through the router calls transferFrom(holder, pair, amount) with the holder as sender and the pair as recipient. While trans is false, none of the four conditions holds for an ordinary holder, so the call reverts.
4. Buys are not blocked by this gate: the pair is the sender when it pays out through the router's swap, and plain transfer is not overridden.
5. Only setTrans changes the flag: function setTrans(bool value) public { require(hasRole(MINTER_ROLE, msg.sender)); trans=value; }. The deployer holds that role from the constructor, so it can open or close selling. The same role can also call piocher, which mints new tokens to any address, and the pauser role can freeze all transfers with pause().
6. The functions that read like safety features do nothing: renounceOwnership() only runs emit OwnershipRenounced(address(0), address(this)); and lockLiquidity() only runs emit liquidityLocked(uniswapV2Pair, address(0));. Neither changes any roles or any liquidity.

The code allows this; no transaction was opened showing setTrans, piocher or pause being called, and no source reports how much holders lost.