Summary
This proposal increases the minimum delay on the stake.link Governance Timelock from 24 hours to 48 hours. Every timelocked action on the core protocol contracts, including upgrades and privileged parameter changes, would need to sit in the public queue for two full days before it can be executed, instead of one.
The primary driver is Aave’s new risk framework, which classifies a multisig with a timelock below 48 hours as a weaker security configuration than one at 48 hours or above. A longer delay also gives stakers and integrators more time to review pending changes and act before they take effectt
The Governance Timelock is an OpenZeppelin TimelockController at 0xb72d8F5213b3E52FAf13Aa074b03C4788e78349F with a minimum delay of 86,400 seconds (24 hours).
The timelock owns the core protocol contracts: the stLINK Staking Pool, Priority Pool, Withdrawal Pool, SDL Pool (reSDL), Operator VCS, and Community VCS. Both parameter changes and contract upgrades flow through it.
The stake.link multisig, a 6-of-8 Safe at 0xB351EC0FEaF4B99FdFD36b484d9EC90D0422493D, is the sole proposer and canceller on the timelock.
Motivation
1. Aave’s new risk framework sets the bar at 48 hours.
In June 2026, LlamaRisk published the Aave Risk Framework ARFC, which formalizes how Aave evaluates the security configuration of asset issuers. Its timelock model states:
Level 4 is a multisig with a timelock of at least 48 hours.
Level 3 is a multisig with a short timelock below 48 hours.
At 24 hours, stake.link sits at Level 3. Raising the delay to 48 hours moves the protocol to Level 4, the strongest configuration available short of full on-chain DAO execution.
2. LlamaRisk already flagged our 24-hour delay.
In their June 2025 risk assessment for the wstLINK onboarding ARFC, LlamaRisk noted that the current delay “may potentially be too short for users to make assessments of any parameter changes and opt out.” That onboarding discussion is still open, and resolving the one governance concern raised in it strengthens wstLINK’s case there and in every future money-market integration.
3. More reaction time for users.
A 48-hour window doubles the time stakers, integrators, and monitoring services have to review a queued operation and, if they disagree with it, unstake or exit before it executes.
Specification
One parameter changes: the timelock’s minimum delay, from 86,400 to 172,800 seconds.
1. The multisig schedules a call to updateDelay(172800) on the timelock itself. The TimelockController only accepts this call from its own address, so the change passes through the existing 24-hour queue like any other operation.
2. Once the delay elapses, the operation is executed.
3. From that point on, every newly scheduled operation requires at least 48 hours before execution. Operations already in the queue keep their original ETA.
Nothing else changes: same multisig, same roles, same contracts, no new code.
Drawbacks
Planned upgrades and routine fixes land one day later than they do today.
This proposal does not add or modify any emergency mechanism; it only lengthens the standard review window. Emergency response paths are a separate topic.
Next steps
1. Community discussion on this post (~ 7 days).
2. Council vote in the stake.link space per the standard SLURP process.
3. If passed, the multisig schedules and executes the update as specified above