System Parameters

Kleidi uses several configurable parameters that control the behavior and security of your timelock wallet. These parameters determine how long transactions must wait before execution and when proposals expire.

Overview

System parameters are the fundamental settings that govern your Kleidi wallet's operation. Most parameters are set during deployment and can only be changed through the timelock governance process itself, ensuring that any parameter changes go through the same security review as regular transactions.

Timelock Parameters

Minimum Delay

The minimum delay is the waiting period that must pass before any timelocked proposal can be executed.

What It Does

When cold signers schedule a transaction, it enters a queue and cannot be executed until the minimum delay has elapsed. This waiting period provides a critical security window:

• Gives you time to detect unauthorized or malicious proposals
• Allows you to cancel suspicious transactions before they execute
• Provides transparency for all wallet stakeholders

Configuration

Bounds: 10 seconds to 30 days

Default Recommendation: 7-14 days for most use cases

Set During: Wallet deployment via the minDelay parameter

Can Be Changed: Yes, through a timelocked proposal (the change itself must wait through the current delay)

How It Works

1. Cold signers schedule transaction
   ↓
2. Transaction enters timelock queue
   ↓
3. [Minimum Delay Period - e.g., 7 days]
   ↓
4. Transaction becomes executable
   ↓
5. Anyone can execute (or it expires)

During the delay period:

• The transaction is visible to all observers on-chain
• Cold signers can cancel the proposal
• You have time to review and verify the transaction

Security Considerations

Longer delays provide:

• More time to detect and respond to unauthorized transactions
• Greater transparency and review time
• Better protection against coercion attacks

Shorter delays provide:

• Faster operational velocity
• Less time for market conditions to change
• Reduced exposure to time-sensitive opportunities being missed

Trade-offs:

Delay Period	Security Level	Operational Speed	Best For
10 sec - 1 day	Lower	Very Fast	Testing, low-value wallets
3-7 days	Medium	Moderate	Individual users, small teams
7-14 days	High	Slower	DAOs, protocols, large treasuries
14-30 days	Maximum	Slow	Critical infrastructure, very high value

Expiration Period

The expiration period determines how long a scheduled proposal remains executable before it expires and must be rescheduled.

What It Does

Once a proposal becomes executable (after the minimum delay), it doesn't remain executable forever. The expiration period sets a deadline:

• Prevents indefinitely old proposals from being executed
• Ensures proposals are executed in a timely manner
• Reduces confusion about which proposals are still valid
• Requires stale proposals to be explicitly rescheduled (and reviewed again)

Configuration

Bounds: Minimum 10 seconds, no maximum limit

Default Recommendation: 7-30 days (longer than your minimum delay)

Set During: Wallet deployment via the expirationPeriod parameter

Can Be Changed: Yes, through a timelocked proposal

How It Works

Proposal Lifecycle:

Schedule → [Min Delay] → Executable → [Expiration Period] → Expired

Example with 7-day delay and 14-day expiration:

Day 0: Scheduled
Day 7: Becomes executable
Day 21: Expires (7 + 14)

After expiration:

• The proposal can no longer be executed
• Anyone can call cleanup() to remove it from the queue
• To execute the same action, cold signers must schedule a new proposal
• The new proposal goes through the full delay period again

Configuration Best Practices

Rule of thumb: Expiration Period ≥ Minimum Delay

This ensures proposals have at least as much time to be executed as they had to wait.

Recommended configurations:

Use Case	Min Delay	Expiration Period	Total Window
High frequency operations	3 days	7 days	10 days
Standard security	7 days	14 days	21 days
High security	14 days	21 days	35 days
Maximum security	21 days	30 days	51 days

Longer expiration periods:

• Provide more flexibility for execution
• Reduce need to reschedule if team is unavailable
• Allow more time for coordination

Shorter expiration periods:

• Force more frequent review of pending actions
• Reduce clutter in proposal queue
• Ensure only recent decisions are executed

Maximum Concurrent Proposals

A hardcoded limit on the number of proposals that can be scheduled simultaneously in the timelock queue.

What It Does

The system enforces a maximum of 100 proposals that can exist in the queue at the same time. This limit serves a critical security function:

When the pause guardian activates a pause, all pending proposals are canceled. If there were thousands of proposals, this cancellation process could consume too much gas and fail, breaking the emergency pause mechanism.

Configuration

Value: 100 proposals (fixed)

Can Be Changed: No, this is a hardcoded constant in the smart contract

Why 100: This limit balances operational flexibility with the gas costs of the pause guardian's emergency cancellation function.

Practical Impact

For most users, this limit is not a concern:

• 100 simultaneous pending proposals is a very large number
• Most wallets operate with 1-10 pending proposals at a time
• Expired proposals can be cleaned up to free slots
• Executed proposals are automatically removed from the queue

If you hit the limit:

• Wait for some proposals to be executed or expire
• Use the cleanup() function to remove expired proposals
• Batch multiple operations into a single proposal
• Consider if your workflow needs adjustment

Technical Details

Location in code: src/utils/Constants.sol:15

uint256 constant MAX_PROPOSAL_COUNT = 100;

When scheduling fails due to this limit, you'll see:

"Timelock: too many proposals"

Configuration Examples

High Security Setup

For protocols and DAOs managing significant value:

Minimum Delay: 14 days
Expiration Period: 21 days

Rationale:

• 14-day delay provides ample time for community review
• 21-day expiration gives 7 days to execute after delay

Balanced Security Setup

For teams and medium-value treasuries:

Minimum Delay: 7 days
Expiration Period: 14 days

Rationale:

• 7-day delay balances security and operational speed
• 14-day expiration provides 7 days for execution

Individual User Setup

For personal wallets with lower values:

Minimum Delay: 3 days
Expiration Period: 7 days

Rationale:

• 3-day delay catches obvious attacks while maintaining agility
• 7-day expiration gives 4 days to execute

Updating Parameters

Which Parameters Can Be Updated

Updatable through timelock:

• Minimum Delay
• Expiration Period

Cannot be updated:

• Maximum Concurrent Proposals (hardcoded constant)
• The Safe address (immutable)

Update Process

To change a parameter:

1. Schedule a timelocked proposal where the target is the Timelock contract itself
2. Set the calldata to call the appropriate update function:
   • updateDelay(uint256 newDelay) for minimum delay
   • updateExpirationPeriod(uint256 newPeriod) for expiration period
3. Wait for the current minimum delay to pass
4. Execute the proposal to apply the new parameter

Important: The parameter change itself goes through the timelock, so plan accordingly. If you're increasing the delay, the change will use the current (shorter) delay. If you're decreasing it, you'll still wait through the current (longer) delay one final time.

Safety Checks

The smart contract enforces bounds on all parameter updates:

• Minimum Delay: Must be between 10 seconds and 30 days
• Expiration Period: Must be at least 10 seconds

Attempts to set parameters outside these bounds will revert.

Related Concepts

• Timelock - Overview of the timelock mechanism
• Guard Contract - Security restrictions
• Architecture - Complete system overview

---

Parameter Coordination

When setting your parameters, ensure they work together coherently. The expiration period should be at least as long as the minimum delay to give adequate time for execution: Expiration Period ≥ Minimum Delay.