Chain Configurations
The Thanos Stack offers a variety of configurable parameters that can be customized to better suit specific operational goals or use cases. While the default settings provided by Optimism are the result of extensive testing and are considered the most stable, making adjustments may be necessary in certain scenarios. However, it's crucial to proceed with caution, as excessive or improper modifications could potentially impact the stability of the network.
1. Configurable FPS Parameters from the Downloaded Config File

Parameters to Consider
faultGameMaxDepth
faultGameSplitDepth
preimageOracleChallengePeriod
faultGameClockExtension
faultGameWithdrawalDelay
proofMaturityDelaySeconds
faultGameMaxClockDuration
preimageOracleMinProposalSize
disputeGameFinalityDelaySeconds
For detailed explanations of these parameters, refer to the Link
Warning: Risks of Modifying Parameters
System Stability:
Reducing values like
faultGameMaxDepth
orfaultGameSplitDepth
could compromise the fault proof system’s ability to process complex disputes, leading to incomplete resolutions.
Fairness of Disputes:
Shortening time-related parameters such as
faultGameClockExtension
,faultGameMaxClockDuration
, orfaultGameWithdrawalDelay
might not provide participants enough time to respond or complete disputes, leading to unfair outcomes.Excessively long durations may cause unnecessary delays in resolution, thereby extending the withdrawal period.
Inadequate review periods, such as lowering
preimageOracleChallengePeriod
, could increase the risk of errors or malicious actions going undetected.
Operational Efficiency:
Adjustments to
preimageOracleMinProposalSize
could lead to inefficiencies by allowing trivial submissions or premature actions that are not thoroughly validated.Longer delays in finality and maturity settings (
disputeGameFinalityDelaySeconds
,proofMaturityDelaySeconds
) could reduce the system’s throughput and slow down operations.
2. Adjustment of Initial Bond(DisputeGameFactory_setInitBond)

Fig. Safe Wallet sending ‘new transaction’.
After deploying the DisputeGameFactory contract, you need to configure the
initBonds
value. Follow the steps here to set the initial bond for each DisputeGameFactory you create.
Initial Bond Risks.
Setting an insufficiently high
InitialBond
may enable malicious actors to engage in disputes with low stakes, increasing spam or frivolous activities within the system.Conversely, an excessively high
InitialBond
could discourage legitimate participants from entering disputes, thereby reducing system fairness and efficiency.
3. Proposer and Batcher Poll Interval (Helm Deployment):
To deploy a Helm chart, a values file containing the deployment configurations is required. You can create this file by referring to this guide. In the
thanos-stack-values.yaml
file,max_channel_duration
is set to 1500, andproposal_interval
is set to 21600s. You can adjust these variables to customize the polling intervals for both the batcher and the proposer.
// thanos-stack-values.yaml
{
......
op_batcher:
env:
max_channel_duration: 1500
op_proposer:
enabled: true
env:
# l2oo_address: {L2_OUTPUT_ORACLE_ADDRESS}
game_factory_address: {GAME_FACTORY_ADDRESS}
proposal_interval: 21600s
......
}
Proposer
PollInterval
: Configures the delay between querying L2 for transactions and creating a new output root proposal.thanos-stack-values.yaml
Batcher Poll Interval (
max-channel-duration
): Specifies the maximum duration (in L1 blocks) to keep a channel open for batching transactions. For example, if themax-channel-duration
is set to30
and the L1 block time is 12 seconds, the batch submission interval would be30 * 12 = 360 seconds
(6 minutes).
Warning on Modifying PollInterval
PollInterval
Changes to the PollInterval
parameter have a direct impact on system performance and operational costs:
Short intervals:
May lead to excessive system load and higher costs due to frequent operations.
Long intervals:
For batchers, delaying batch submissions to L1 postpones the inclusion of transaction data in finalized batches, which can slow down the finalization of state commitments. This, in turn, delays when users can initiate withdrawals, leading to a sub-optimal user experience and reduced system responsiveness.
For proposers, long intervals delay the submission of output roots, which serve as proof for withdrawals. This increases the time users have to wait to initiate their withdrawals, impacting the system's responsiveness and user experience.
Recommendation
Last updated