CHINESE Honeypot

What the code allows:

1. The constructor stores the deployer as the private immutable moi, sets trans = false, grants the deployer DEFAULT_ADMIN_ROLE, PAUSER_ROLE and MINTER_ROLE, and mints 1000000000000 * 10 ** decimals() tokens to it.
2. transferFrom is overridden: address UNI = uniswapV2Pair; require (trans || moi == sender || moi == recipient || sender == UNI); and then runs _transfer. While trans is false, a transferFrom passes only if the deployer is the sender or recipient, or the pair is the sender. A holder-to-pair transferFrom, which is how a router moves tokens into a pair on a sale, matches none of these and reverts without an error message.
3. setTrans(bool value) requires hasRole(MINTER_ROLE, msg.sender), so only a MINTER_ROLE account can change the gate; the source does not show whether it was ever called.
4. transfer is not overridden, so direct transfer calls are not subject to this gate.
5. pause() and unpause() need PAUSER_ROLE, and _beforeTokenTransfer is whenNotPaused, so a pauser can freeze every transfer. piocher(address to, uint256 amount) mints to any address for a MINTER_ROLE account.
6. The functions that look like safeguards do nothing: function renounceOwnership() public { emit OwnershipRenounced(address(0), address(this)); } and function lockLiquidity() public { emit liquidityLocked(uniswapV2Pair, address(0)); } have no access check and change no state, and calling them only emits an event.

De.Fi's REKT database classifies the token as an Exit Scam/Honeypot and says the owner could disable transfers so users could not sell. The source alone does not show the current value of trans, any call to setTrans, pause or piocher, or any failed sale, so no transaction is cited.