How the block is implemented
Common techniques include an allow-list that only the deployer is on, a sell tax set to one hundred percent, a transfer function that reverts when the destination is a pool, a blacklist applied after purchase, and a pausable transfer controlled by an owner key.
Some are time-delayed: selling works for the first hours to build confidence, then a parameter is flipped.
What it looks like from outside
A chart that only rises. Very few unique sellers relative to buyers. A tiny holder count with concentrated supply. Liquidity that is not locked, or is locked for a suspiciously short period. An unverified contract, or a verified one with owner-only functions.
Aggressive promotion with a countdown is the usual accompaniment, because the model needs a flow of new buyers.
Testing before committing
Buy a trivial amount and immediately attempt to sell a portion of it. If the sell reverts or quotes an absurd output, you have your answer for the cost of two gas fees.
Honeypot scanners exist and catch the common patterns. They are useful and not conclusive — a contract can detect simulation, and a time-delayed honeypot passes every scan on day one.
Reading the contract itself
On the explorer, look for owner-only functions that can change fees, pause transfers, or modify a blacklist. The presence of any of those means the deployer can make the token unsellable at will, whether or not they have yet.
A renounced owner removes that specific risk and does not remove logic already written into the transfer function.