It’s been brought to our attention that some protocol parameters might require updating due to the recent Ethereum move to PoS last September.
With the merge the block time has changed from an average of 13.4 seconds to a fixed 12 seconds. This means that any protocol parameters that depend on or were set considering the pre-merge average block time are now slightly off their intended targets since essentially the clock is running faster. While this is not necessarily detrimental to the protocol it signifies a “silent” update and participants interacting with the protocol might experience unexpected behavior.
We need to evaluate if we want to update the parameters to match their original targets in days/hours. We have already done this process for the protocol’s issuance rate (see forum discussion and GGP) however there are at least two more parameters we should review:
This parameter sets the length of an epoch in blocks and it’s currently set to 6646 blocks on mainnet. Pre-merge this translated to epoch duration of ~24 hours; post-merge it means epochs are ~22.15 hours long.
This is most noticeable for example when considering the allocation epoch cap (
maxAllocationEpochs), which is set in epochs so it changed from ~28 days to ~25,8 days. Anyone can close allocations after this period which means unaware indexers might lose out on rewards due to griefers closing allocations they thought were still safe.
Thawing period is the amount of time tokens are locked after unstaking and it’s also set in blocks; on mainnet it’s set to 186092 which means ~28 days pre-merge and ~25,8 days post-merge.
Here are the proposed changes we would need to apply to bring these parameters back in line with their original target:
|Parameter||Current value||Proposed value|
|EpochManager.epochLength||6646 (~24 hours pre-merge; ~22.15 hours post-merge)||7200 (24 hours post-merge)|
|Staking.thawingPeriod||186092 (~28 days pre-merge; ~25.8 days post-merge)||201600 (28 days post-merge)|