# block.timestamp as deadline provides no protection because it references the time at execution Functions that accept a deadline parameter enforce temporal bounds via `require(block.timestamp <= deadline)`. When a contract passes `block.timestamp` as the deadline, this becomes `require(block.timestamp <= block.timestamp)`, which is always true regardless of when the transaction executes. The purpose of a deadline is to protect against temporal manipulation: a transaction submitted at time T should not execute at time T+4 hours when conditions have changed. By using `block.timestamp`, the deadline moves with the execution time, providing zero protection. A validator or sequencer can hold the transaction indefinitely and include it at any future time. This affects any time-bounded operation: swaps, auctions, governance proposal execution, permit signatures, and oracle price consumption. This is distinct from having no deadline parameter at all. Since [[missing deadline parameters allow transactions to linger in the mempool and execute at substantially worse prices than at submission time]], the missing-deadline case has no check at all. The `block.timestamp` case is subtler: the check exists in the code and may appear correct during review, but it is semantically vacuous. The presence of the check creates false confidence that temporal protection exists. The fix: deadlines must be calculated from a reference point before the transaction enters the mempool. For user-facing functions, the frontend computes `block.timestamp + maxDelay` at submission time and passes it as a parameter. For automated protocol functions, use a cached timestamp from a previous block plus a bounded delay. --- Relevant Notes: - [[missing deadline parameters allow transactions to linger in the mempool and execute at substantially worse prices than at submission time]] -- the parent pattern: temporal slippage from absent or ineffective deadlines - [[slippage protection with zero minTokensOut exposes users to unlimited loss and must always be flagged as critical in audits]] -- sibling: price-dimension slippage protection that also fails when derived from manipulable state - [[block timestamp manipulation within protocol bounds enables exploitation of time-dependent contract logic]] -- related: block.timestamp is validator-controllable within bounds, compounding the deadline weakness - [[on-chain slippage calculation using Quoter contracts is subject to the same manipulation as the spot price it queries]] -- sibling swap protection failure: Quoter-based slippage and block.timestamp deadlines both provide syntactically present but semantically vacuous protection Topics: - [[vulnerability-patterns]]