Timelock & Execution

Mandatory delays between proposal approval and on-chain execution

The Dualis timelock system introduces a mandatory waiting period between a proposal passing its governance vote and being executed on-chain. This delay gives the community time to review approved changes, identify potential issues, and react before the protocol state is modified. The timelock duration varies by proposal type, reflecting the risk and impact level of each category.

Timelock Durations

Each proposal type is assigned a specific timelock delay. Once a proposal passes the voting phase and enters the Queued state, the timelock countdown begins. The proposal cannot be executed until the full delay has elapsed.

Proposal Type	Timelock	Execution Window	Rationale
PARAMETER_CHANGE	48 hours	7 days	Standard delay for routine parameter updates.
NEW_POOL	48 hours	7 days	Sufficient time for market participants to prepare.
POOL_DEPRECATION	48 hours	7 days	Allows users to exit positions before deprecation.
TREASURY_SPEND	72 hours	7 days	Extended review for fund deployment decisions.
EMERGENCY_ACTION	0 hours	7 days	Immediate execution for critical safety operations.
PROTOCOL_UPGRADE	96 hours	7 days	Maximum delay for high-impact contract upgrades.

Emergency Actions Have Zero Timelock

EMERGENCY_ACTION proposals execute immediately upon passing the vote with no delay. This is by design -- emergency actions address critical threats such as oracle failures, active exploits, or market circuit breakers where any delay could result in protocol losses. Emergency proposals are subject to the admin veto as a final safeguard.

Execution Window

After the timelock delay expires, the proposal enters the execution window. Any address can trigger the execution of a queued proposal during this window -- the executor does not need to be the original proposer. The execution window is 7 days for all proposal types.

If the proposal is not executed within the 7-day window, it expires permanently. Expired proposals cannot be revived or re-queued; they must be resubmitted as a new DIP with a fresh voting cycle. This prevents stale proposals from being executed long after their original context may have changed.

Grace Period

The protocol includes a 48-hour grace period at the end of the execution window. During the grace period, the governance dashboard displays a prominent warning that the proposal is about to expire. This gives the community a final opportunity to execute proposals that may have been overlooked.

The grace period is purely informational -- it does not extend the execution window. Proposals that are not executed by the end of the 7-day window (including the grace period notification) are marked as expired.

Admin Veto Mechanism

As a final security safeguard, the protocol maintains an admin veto capability. The veto power is held by a multi-signature wallet controlled by the Dualis security council, a committee of protocol contributors and independent security researchers.

The veto can be exercised during the timelock period to cancel a queued proposal before execution. The veto mechanism is designed exclusively for scenarios where a passed proposal would compromise protocol security, violate regulatory requirements, or contain a technical error that could lead to loss of funds.

Veto Limitations

The admin veto cannot be used after a proposal has been executed. It can only cancel proposals that are in the Queued state during their timelock period. The veto power itself is subject to governance -- the community can vote to revoke or transfer veto authority through a PROTOCOL_UPGRADE proposal.

Veto Transparency

Every veto action is recorded on-chain with a mandatory justification. The security council must publish a detailed explanation for each veto, including the specific risk identified and the recommended path forward. This transparency requirement ensures that veto power is exercised responsibly and remains accountable to the community.

On-chain record -- The veto transaction includes the proposal ID, timestamp, council member signatures, and a justification hash.
Public disclosure -- The full justification text is published to the governance forum within 24 hours of the veto.
Community review -- After a veto, the community may submit a revised proposal addressing the identified concerns. Vetoed proposals are tracked separately in the governance dashboard.

End-to-End Flow

The complete governance execution timeline for a standard PARAMETER_CHANGE proposal illustrates how these mechanisms work together:

Day 0 -- Proposal submitted on-chain as a DIP. Voting begins.
Day 5 -- Voting period ends. Proposal passes with quorum met and majority For votes.
Day 5 -- Proposal enters the timelock queue. 48-hour countdown begins.
Day 7 -- Timelock expires. The 7-day execution window opens.
Day 7-14 -- Any address may execute the proposal on-chain.
Day 12 -- Grace period warning appears (48 hours before expiry).
Day 14 -- Execution window closes. If not executed, the proposal expires.