Timelock on mints
For a reserve-backed token, primary mint and redeem must clear near-instantly to preserve the peg through arbitrage, so a timelock does not apply to routine per-transaction issuance, the control there is the on-chain collateral constraint above. The timelock instead governs the infrequent, high-impact changes to issuance: adding or removing minters, and changing mint caps or parameters. Its protective value is conditional on the proposal queue being monitored.
| Tier | Reasoning | Evidence |
|---|---|---|
| No timelock, or bypassable via emergency execution path | A timelock is the user's exit window before contested actions occur. No or short timelock, or one bypassable through an emergency execution path, means a compromised or malicious action becomes immediate and irreversible. | Radiant Capital's October 2024 exploit ($53M) executed instantly because there was no timelock on transferOwnership. Ankr's deployer EOA similarly pushed a malicious mint implementation with no upgrade delay. Beanstalk's emergencyCommit (24h seasoning) was bypassed by a flash-loaned supermajority vote in April 2022 ($182M). |
| 1 to 72 hours | A meaningful delay creates a response window between approval and execution, but its protective value is conditional on the proposal queue actually being monitored; the delay alone does not guarantee detection. | Moonwell (March 2026) showed that a 48-hour timelock provided no protection because no one monitored the proposal queue. |
| 72+ hours with active monitoring and community visibility | A long delay combined with active monitoring of the proposal queue and community visibility ensures the community has both the time and the information to detect and respond to contested actions before they execute. | Arbitrum's Security Council 13-day delay with verifiable on-chain proposal visibility anchors the top tier. |