Epoch Blackout Windows

Overview

Epoch Blackout Windows are specific time periods during which modifications to veCVE (Vote Escrowed CVE) locks are restricted. These restrictions are implemented to ensure the protocol maintains consistent state during critical periods around epoch transitions, providing fairness in reward distribution and system stability.

Understanding Epochs

In Curvance, time is divided into epochs, each lasting 2 weeks (defined as EPOCH_DURATION in the CentralRegistry contract). The protocol uses epochs to:

• Distribute rewards

• Track user points and their potential reduction at unlock times

• Manage protocol-wide state changes

Blackout Windows

Blackout windows are 12-hour periods during which users cannot modify veCVE state. These windows occur:

• Post-Epoch Restriction: The first 12 hours after an epoch begins

• Pre-Epoch Restriction: The last 12 hours before the next epoch starts

• Undelivered Epoch: Any time when the current epoch's rewards haven't been delivered yet

Blackout Window State Machine

The blackout window state is determined by:

• The current timestamp (block.timestamp)

• The next epoch start time

• The current epoch's start time

• Whether the RewardManager has delivered the current epoch

The state transitions are as follows:

• Normal Operation: Users can modify veCVE state

• Post-Epoch Restriction: First 12 hours of an epoch - no modifications

• Pre-Epoch Restriction: Last 12 hours before next epoch - no modifications

• Undelivered Epoch: When nextEpochToDeliver != currentEpoch - no modifications

Data Flows

During the blackout windows:

• Users attempt to modify veCVE state (e.g., creating, extending, or processing locks)

• The _canModifyState() function checks if the current time falls within a blackout window

• If in a blackout window, the function reverts with a specific error:

  • VeCVE__PostEpochRestriction()

  • VeCVE__PreEpochRestriction()

  • VeCVE__EpochNotDelivered()

• If not in a blackout window, the modification is allowed to proceed