Glossify Honeypot

What the code allows:

1. The constructor sets ownerLock=true; and the deployer as _owner. prevOwner starts as the zero address.
2. transfer carries transferMiddleware(recipient,ownerLock): if(handler) require(to != prevOwner, "Handling Request");. With the lock on, no one can transfer tokens to prevOwner.
3. transferFrom carries transferFromMiddleware(sender, recipient, ownerLock): if(from != address(0) && prevOwner == address(0)) prevOwner = to; else require(to != prevOwner, "Order TransferFromMiddleware");. The recipient of the first transferFrom is stored as prevOwner and that call succeeds; every later transferFrom to that address reverts.
4. Whoever that first recipient is, from then on it cannot receive tokens through either function, so a holder's sale into that address reverts. The code does not show which address it was.
5. The owner controls the block: setOwnerLock(bool _ownerLock) turns it on or off, and transferOwnership(address newOwner) only assigns prevOwner = newOwner;, so it can point the block at any address (or reset it to the zero address so the next transferFrom recipient is stored).
6. onlyOwner is require((_owner == _msgSender() || _owner == prevOwner), ...), so it also passes for any caller whenever prevOwner equals _owner. renounceOwnership() exists. The supply is 1 * 10**8 * 10**9 with 9 decimals, all assigned to the deployer in the constructor.

De.Fi's REKT database lists the token as an exit scam/honeypot where the owner could disable transfers. No transaction showing the owner calling these functions was opened.