Epochs and Delays

Epochs are the time rules of Symbiotic. They tell you when validator sets update, when withdrawal requests can be claimed, and how long captured guarantees stay slashable. Grouping changes at epoch boundaries keeps the stake that networks rely on stable and easy to verify.

Vault Epochs

Each vault has an epoch duration set at deployment (epochDuration). All epochs for that vault:

• are consecutive and equal length
• use the same duration unless the curator later increases it

Vault epochs drive two things:

1. When queued withdrawals become claimable
2. The maximum look-back window for slashing previously captured guarantees

Withdrawal Timing

Withdrawals are a two-step, epoch-based process.

• A user submits a withdrawal request at time t inside epoch k.
• The request becomes claimable after epoch k+1 ends.

If the epoch length is E:

• the effective delay from request to claim is in [E, 2E) depending on when in the epoch the user requested
• until the boundary at the end of epoch k+1, the requested funds remain slashable

After that boundary, the withdrawal can be claimed and is no longer subject to new slashes.

Capture and Slashing Window

Networks do not slash against live state; they slash against captures.

• A captureTimestamp is the time a Network uses to snapshot stake and validator sets.
• At capture, the Network receives a guarantee that the captured amounts remain slashable for one vault epoch after that timestamp.

When a slashing request is executed, the Slasher enforces:

1. Freshness

   If the capture is older than one epoch at execution time, the request is rejected: now − captureTimestamp ≤ vaultEpoch

2. Bounded amount

   Let

   • G = guarantee captured at captureTimestamp
   • C = cumulative slashes already applied for that same capture

   Then any new slash must satisfy: slashAmount ≤ G − C

This anchors penalties to a specific snapshot and prevents double-charging or overshooting the guarantee.

Network Epochs and Buffers

Vault epochs need to be large enough to contain the end-to-end slashing path for a Network.

Roughly:

validatorSetCaptureDelay + networkEpoch + vetoWindow + executionWindow ≪ vaultEpoch

Where:

• validatorSetCaptureDelay – time to produce and publish the operator set / stake snapshot
• networkEpoch – how often your network rotates or commits a new set
• vetoWindow – VetoSlasher review period, if used
• executionWindow – operational buffer to actually call the Slasher and finalize the transaction

If the sum approaches the vault epoch, captures risk expiring before penalties can be executed. Either shrink the network-side timings or use a vault with a longer epoch.

Lifecycle Notes

Epoch changes and events interact like this:

• Freshness checks use the current vault epoch at verification time, not the epoch duration that was in effect when the capture was taken.
• Withdrawals are slashable until the first boundary where they become claimable (end of epoch k+1 for a request in epoch k).

Examples

• E = 7 days.
• User requests withdrawal on day 2 of epoch k.
• Claim is possible right after epoch k+1 ends → between 7 and 14 days from the request, depending on where in the epoch they requested.
• Funds remain slashable until that boundary.

• Vault epoch E = 8 days.
• validatorSetCaptureDelay = 6h, networkEpoch = 24h, vetoWindow = 12h, executionWindow = 6h.
• Total = 48h, well below 8 days → captures stay fresh and enforceable with plenty of margin.