Blockchain configuration

TON features a complex configuration comprising many technical parameters, some of which are used by the blockchain itself, while others serve the ecosystem. However, only a limited number of individuals fully understand the significance of these parameters. This article aims to provide users with an overview of configuration parameters, their modification processes, and a straightforward explanation of each parameter and its purpose.

Prerequisites

The explorer shows the active mainnet configuration and testnet configuration. Filter by signed parameter index to inspect decoded fields and the raw cell hex bytes.

Configuration values are TL-B-typed cells serialized into Bags of Cells (BoC). Non-negative parameters and their serialization are defined in block.tlb.

Overview

The configuration parameters are specific values that influence the behavior of validators and fundamental smart contracts on the TON blockchain. The current values of all configuration parameters are stored as a distinct part of the masterchain state and are retrieved whenever necessary. Consequently, we can refer to the values of the configuration parameters concerning a particular masterchain block. Each shardchain block includes a reference to the most recently known masterchain block; the values from the corresponding masterchain state are considered active for this shardchain block and are used during its generation and validation.

For masterchain blocks, the state of the previous masterchain block is used to extract the active configuration parameters. Therefore, even if certain configuration parameters are attempted to be modified within a masterchain block, any changes will only take effect in the subsequent masterchain block.

Each configuration parameter is identified by a signed 32-bit integer known as the configuration parameter index, or simply the index. The value of a configuration parameter is always a Cell. In some cases, certain configuration parameters may be absent, and it is generally assumed that the value of these missing parameters is Null. Additionally, there is a list of mandatory configuration parameters that must always be present. This list is stored in configuration parameter #9.

All configuration parameters are combined into a configuration dictionary with signed 32-bit keys (the configuration parameter indices) and values that consist of exactly one cell reference. The collection of all configuration parameters is retained in the masterchain state as a value of the TL-B type ConfigParams:

_ config_addr:bits256 config:^(Hashmap 32 ^Cell) = ConfigParams;

In addition to the configuration dictionary, ConfigParams contains config_addr—the 256-bit address of the configuration smart contract within the masterchain. Further details on the configuration smart contract will be provided later.

The configuration dictionary, which contains the active values of all configuration parameters, is accessible to all smart contracts through a special TVM register called c7 during the execution of a transaction. Specifically, when a smart contract is executed, c7 is initialized as a tuple. This tuple consists of a single element, which is another tuple containing several "context" values that are useful for executing the smart contract, such as the current Unix time (as recorded in the block header).

The tenth entry of this inner tuple (i.e., the one indexed with zero-based index 9) contains a Cell representing the configuration dictionary. This configuration dictionary can be accessed by using the TVM instructions PUSH c7; FIRST; INDEX 9 or the equivalent instruction CONFIGROOT. Furthermore, special TVM instructions like CONFIGPARAM and CONFIGOPTPARAM streamline this process by combining the previous actions with a dictionary lookup, allowing smart contracts to retrieve any configuration parameter by its index.

It is important to note that all configuration parameters are readily accessible to all smart contracts, whether they operate on the masterchain or shardchain. As a result, smart contracts can inspect these parameters and utilize them for specific checks. For instance, a smart contract might extract data storage prices for different WorkChains from a configuration parameter in order to calculate the cost of storing a piece of user-provided data.

The values of configuration parameters are not arbitrary. Specifically, if the configuration parameter index i is non-negative, then its value must correspond to a valid value of the TL-B type ConfigParam i. Validators enforce this restriction and do not accept changes to configuration parameters with non-negative indices unless the values are valid for the corresponding TL-B type.

The structure of these parameters is defined in crypto/block/block.tlb, where ConfigParam i is specified for different values of i. For example:

_ config_addr:bits256 = ConfigParam 0;
_ elector_addr:bits256 = ConfigParam 1;
_ dns_root_addr:bits256 = ConfigParam 4;  // root TON DNS resolver

capabilities#c4 version:uint32 capabilities:uint64 = GlobalVersion;
_ GlobalVersion = ConfigParam 8;  // all zero if absent

The configuration parameter #8 includes a Cell that has no references and contains exactly 104 data bits. The first eight bits are allocated for 11000100 (0xc4), followed by 32 bits that represent the enabled global TVM version. This is followed by a 64-bit integer with flags that correspond to the enabled capabilities.

The block.tlb definitions provide the canonical TL-B schemas for all non-negative parameters.

Unlike configuration parameters with non-negative indices, those with negative indices can hold arbitrary values. Validators do not enforce any restrictions on these values. As a result, they can be used to store essential information, such as the Unix time when specific smart contracts are set to begin operating. This information is not critical for block generation but is necessary for some fundamental smart contracts.

Changing configuration parameters

The current values of configuration parameters are stored in a special section of the masterchain state. But how are they changed?

There is a special smart contract known as the configuration smart contract that resides in the masterchain. Its address is specified by the config_addr field in ConfigParams. The first cell reference in its data must contain an up-to-date copy of all configuration parameters. When a new masterchain block is generated, the configuration smart contract is accessed using its address (config_addr), and the new configuration dictionary is extracted from the first cell reference of its data.

Following some validity checks—like ensuring that any value with a non-negative 32-bit index i is indeed a valid TL-B type (ConfigParam i)—the validator copies this new configuration dictionary into the portion of the masterchain that contains ConfigParams. This operation occurs after all transactions have been created, meaning only the final version of the new configuration dictionary stored in the smart contract is evaluated.

If the validity checks fail, the existing configuration dictionary remains unchanged, ensuring that the configuration smart contract cannot install invalid parameter values. If the new configuration dictionary is identical to the current one, no checks are performed, and no changes are made.

All changes to configuration parameters are executed by the configuration smart contract, which defines the rules for modifying these parameters. Currently, the contract supports two methods for changing them:

• External message: This method involves an external message signed by a specific private key, which corresponds to a public key stored in the configuration smart contract's data. This approach is typically used in the testnet and, possibly, in smaller private test networks controlled by a single entity, as it allows the operator to easily modify any configuration parameter values.

  It is important to note that this public key can be changed through a special external message signed by the previous key, and if changed to zero, this mechanism becomes disabled. This means the method can be used for fine-tuning right after launch and then permanently disabled.

• Configuration proposals: This method involves creating "configuration proposals" that validators vote on. Generally, a configuration proposal must gather votes from more than 3/4 (75%) of all validators by weight, and this requires approval in multiple rounds (i.e., several consecutive sets of validators must confirm the proposed parameter change). This serves as the distributed governance mechanism for the TON blockchain Mainnet.

Param 0: config address

This parameter is the address of a special smart contract that stores the blockchain's configuration. The configuration is stored in the contract to simplify its loading and modification during validator voting.

Parameter #0 on mainnet

Param 1: elector address

This parameter is the address of the elector smart contract, responsible for appointing validators, distributing rewards, and voting on changes to blockchain parameters.

Parameter #1 on mainnet

Param 2: GRAM minting address

This parameter is the address of the masterchain smart contract that controls GRAM minting.

Parameter #2 on mainnet

Param 3: fee collector address

This parameter is the address of the transaction fee collector.

Parameter #3 on mainnet

Param 4: root DNS address

This parameter is the address of the root DNS contract of the TON network.

Parameter #4 on mainnet

Param 5: burning configuration

This parameter controls two independent mechanisms for removing Gram from circulation:

• fee_burn_num and fee_burn_denom: These fields define the fraction of Gram-denominated transaction and message import fees to burn. A masterchain block applies the fraction to its fees and imported shardchain fees after subtracting shard block rewards. The result rounds down to whole nanograms, and the remainder enters the validator fee balance. The numerator cannot exceed the denominator, and the denominator must be at least 1.

• blackhole_addr: The masterchain burn address (account ID) — each inbound message to this address burns its remaining Gram value instead of crediting it to the account. This mechanism does not burn the account's existing balance or extra currencies.

Parameter #5 on mainnet

Param 6: extra currency minting prices

This parameter stores the mint_new_price and mint_add_price values in Gram for extra-currency minting governance. The collator's minting calculation does not use these values.

Parameter #6 on mainnet

Param 7: extra currency volume

This parameter stores target amounts for extra-currency minting. It maps each 32-bit currency ID to a VarUInteger 32 amount. A masterchain block mints the positive difference between a target and the previous global balance — lowering a target does not burn currency.

Parameter #7 on mainnet

Param 8: network version

This parameter indicates the network version and additional capabilities supported by the validators.

• version: This field specifies the version.

• capabilities: This field is a set of flags that are used to indicate the presence or absence of certain features or capabilities.

Thus, when updating the network, validators will vote to change parameter 8. This way, the TON Blockchain network can be updated without downtime.

Parameter #8 on mainnet

Param 9: mandatory params

This parameter contains a list (binary tree) of mandatory parameters. It ensures that certain configuration parameters are always present and cannot be removed by a proposal to change the configuration until parameter 9 changes.

Parameter #9 on mainnet

Param 10: critical params

This parameter represents a list (binary tree) of critical TON parameters whose change significantly affects the network, so more voting rounds are held.

Parameter #10 on mainnet

Param 11: config params

This parameter indicates under what conditions proposals to change the TON configuration are accepted.

• min_tot_rounds: The minimum number of rounds before a proposal can be applied. Currently, this parameter is not used: only max_tot_round (when the proposal will be rejected) and min_wins (when the proposal will be accepted) matter.

• max_tot_rounds: The maximum number of rounds, upon reaching which the proposal will automatically be rejected

• min_wins: The required number of wins (3/4 of validators by the sum of the pledges must vote in favor)

• max_losses: The maximum number of losses, upon reaching which the proposal will automatically be rejected

• min_store_sec and max_store_sec determine the possible time interval during which the proposal will be stored

• bit_price and cell_price indicate the price of storing one bit or one cell of the proposal

Parameter #11 on mainnet

Param 12: workchain config

This parameter represents the configuration of a workchain in the TON Blockchain. workchains are designed as independent blockchains that can operate in parallel, allowing TON to scale and process a large number of transactions and smart contracts.

Workchain configuration parameters

• enabled_since: A UNIX timestamp of the moment this workchain was enabled.

• monitor_min_split: The minimum depth of the split of this workchain at which deeper shards are grouped for node monitoring, overlays, and archive distribution. It does not control shard splitting itself.

• min_split: The minimum depth of the split of this workchain, set by the configuration, which must be greater than or equal to monitor_min_split. Unlike monitor_min_split, min_split affects shard splits and merges — shards shallower than min_split must split, and shards at or below it cannot merge.

• max_split: The maximum depth of the split of this workchain.

• basic: A boolean flag (1 for true, 0 for false) indicating whether this workchain is basic, i.e., handles Gram values (smart contracts based on the TON Virtual Machine).

• active: A boolean flag indicating whether this workchain is active at the moment.

• accept_msgs: A boolean flag indicating whether this workchain is accepting messages at the moment.

• flags: Additional flags for the workchain (reserved, currently always 0).

• zerostate_root_hash and zerostate_file_hash: Hashes of the first block of the workchain.

• version: Version of the workchain.

• format: The workchain address and virtual machine format, including vm_version and vm_mode values.

• split_merge_timings: The preparation delay, active interval, minimum interval, and maximum delay for shard split and merge operations.

• persistent_state_split_depth: The shard split depth used when creating and downloading persistent state files.

Parameter #12 on mainnet

Param 13: complaint cost

This parameter defines the cost of filing complaints about the incorrect operation of validators in the elector smart contract.

Parameter #13 on mainnet

Param 14: block reward

This parameter controls the Gram rewards for producing blocks. The masterchain_block_fee is applied to each masterchain block, while the basechain_block_fee applies to a workchain. If there is a split in the workchain, the basechain_block_fee is distributed among its shard blocks based on their depth.

Parameter #14 on mainnet

Param 15: elections timing

This parameter contains the duration of different stages of elections and validators' work in the TON Blockchain.

For each validation period, there is an election_id equal to the UNIX-format time at the start of the validation.

You can get the current election_id (if elections are ongoing) or the past one by invoking the elector smart contract's respective get-methods active_election_id and past_election_ids.

Election and validation timing parameters

• validators_elected_for: The number of seconds the elected validators perform their role (one round).

• elections_start_before: The seconds before the end of the current round, when the election process for the next period will start.

• elections_end_before: The seconds before the end of the current round, the validators for the next round will be chosen.

• stake_held_for: The period for which a validator's stake is held (for handling complaints) after the round expires.

Examples

In the TON Blockchain, validation periods are typically divided into even and odd rounds that alternate. Voting for the next round occurs during the previous one, so a validator must allocate their funds into two separate pools to participate in both rounds.

Mainnet

Current values:

constants = {
    'validators_elected_for': 65536,  # 18.2 hours
    'elections_start_before': 32768,  # 9.1 hours
    'elections_end_before': 8192,     # 2.2 hours
    'stake_held_for': 32768           # 9.1 hours
}

Scheme:

How to calculate periods?

Let election_id = validation_start = 1600032768. Then:

election_start = election_id - constants['elections_start_before'] = 1600032768 - 32768 = 1600000000
election_end = delay_start = election_id - constants['elections_end_before'] = 1600032768 - 8192 = 1600024576
hold_start = validation_end = election_id + constants['validators_elected_for'] = 1600032768 + 65536 = 1600098304
hold_end = hold_start + constants['stake_held_for'] = 1600098304 + 32768 = 1600131072

Therefore, at this time, the length of one round of one parity is 1600131072 - 1600000000 = 131072 seconds = 36.40888... hours

Testnet

Current values:

constants = {
    'validators_elected_for': 7200,  # 2 hours
    'elections_start_before': 2400,  # 40 minutes
    'elections_end_before': 180,     # 3 minutes
    'stake_held_for': 900            # 15 minutes
}

Scheme:

How to calculate periods?

Let election_id = validation_start = 160002400. Then:

election_start = election_id - constants['elections_start_before'] = 160002400 - 2400 = 160000000
election_end = delay_start = election_id - constants['elections_end_before'] = 160002400 - 180 = 160002220
hold_start = validation_end = election_id + constants['validators_elected_for'] = 160002400 + 7200 = 160009600
hold_end = hold_start + constants['stake_held_for'] = 160009600 + 900 = 160010500

Therefore, at this time, the length of one round of one parity is 160010500 - 160000000 = 10500 seconds = 175 minutes = 2.91666... hours

Parameter #15 on mainnet

Param 16: validators limits

This parameter represents the limits on the number of validators in the TON Blockchain. It is directly used by the elector smart contract.

Configuration parameters for the number of validators for elections

• max_validators: This parameter represents the maximum number of validators that can participate in the network operation at any given time.

• max_main_validators: This parameter represents the maximum number of masterchain validators.

• min_validators: This parameter represents the minimum number of validators that must support the network operation.

Notes

• The maximum number of validators is greater than or equal to the maximum number of masterchain validators.

• The maximum number of masterchain validators must be greater than or equal to the minimum number of validators.

• The minimum number of validators must be no less than 1.

Parameter #16 on mainnet

Param 17: stake limits

This parameter represents the stake parameters configuration in the TON Blockchain. In many blockchain systems, especially those using the Proof-of-Stake or Delegated Proof-of-Stake consensus algorithm, cryptocurrency owners native to the network can "stake" their tokens to become validators and earn rewards.

Configuration parameters

• min_stake: This parameter represents the minimum amount of Gram that an interested party needs to stake to participate in the validation process.

• max_stake: This parameter represents the maximum amount of Gram that an interested party can stake.

• min_total_stake: This parameter represents the minimum total amount of Gram that the chosen set of validators must hold.

• max_stake_factor: This parameter is a multiplier indicating how many times the maximum effective stake (pledge) can exceed the minimum stake sent by any other validator.

Parameter #17 on mainnet

Param 18: storage prices

This parameter represents the configuration for determining the prices for data storage on the TON Blockchain. This serves as a measure to prevent spam and encourages network maintenance.

Dictionary of storage fee parameters

• utime_since: This parameter provides the initial Unix timestamp from which the specified prices apply.

• bit_price_ps and cell_price_ps: These parameters represent the storage prices for one bit or one cell of information in the main workchains of the TON Blockchain for 65536 seconds.

• mc_bit_price_ps and mc_cell_price_ps: These parameters represent the storage prices per bit and per cell in the TON masterchain for 65536 seconds.

Parameter #18 on mainnet

Param 19: global ID

This parameter stores the network identifier. Blocks and shard states carry the same global_id, and validators reject data whose identifier does not match the configured network. Smart contracts can read it with the GLOBALID TVM instruction.

Parameter #19 on mainnet

Param 20 and 21: gas prices

These parameters define the cost of computations in the TON network. The complexity of any computation is estimated in gas units.

Note: Param 20 defines gas settings for the masterchain; Param 21 defines gas settings for other workchains.

• flat_gas_limit and flat_gas_price: A certain starting amount of gas is provided at a price of flat_gas_price (to offset the costs of launching the TON Virtual Machine).

• gas_price: This parameter reflects the price of gas in the network, in nanograms per 65536 gas units.

• gas_limit: This parameter represents the maximum amount of gas that can be consumed per transaction.

• special_gas_limit: This parameter represents the limit on the amount of gas that can be consumed per transaction of a special (system) contract.

• gas_credit: This parameter represents a credit in gas units provided to transactions to process an external message.

• block_gas_limit: This parameter represents the maximum amount of gas that can be consumed within a single block.

• freeze_due_limit and delete_due_limit: Limits of accumulated storage fees (in nanograms) at which a contract is frozen and deleted, respectively.

Parameter #20 on mainnet | Parameter #21 on mainnet

Param 22 and 23: block limits

Parameter 22 applies to masterchain blocks, while parameter 23 applies to workchain blocks. They classify block load and limit block bytes, gas, time deltas, collated data, and imported message queue proofs.

Configuration parameters

• bytes: This section sets the limits on the block size in bytes.

• underload: Underload is a state when the shard realizes that there is no load and is inclined to merge if a neighboring shard is willing.

• soft_limit: Soft limit - when this limit is reached, internal messages stop being processed.

• hard_limit: Hard limit - this is the absolute maximum size.

• gas: This section sets the limits on the amount of gas that a block can consume. Gas, in the context of blockchain, is an indicator of computational work. The limits on underload, soft and hard limits work the same as for size in bytes.

• lt_delta: This section sets the limits on the difference in logical time between the first and last transaction. Logical time is a concept used in the TON Blockchain for ordering events. The limits on underload, soft and hard limits work the same as for size in bytes and gas.

• collated_data: The underload, soft, and hard size limits for serialized collated data. Older parameter values omit this field and use the bytes limits instead.

• imported_msg_queue: The maximum byte size and message count for an imported message queue proof.

Parameter #22 on mainnet | Parameter #23 on mainnet

Param 24 and 25: message price

Parameter 24 represents the configuration for the cost of sending messages in the masterchain of the TON Blockchain.

Parameter 25 represents the configuration for the cost of sending messages in all other cases.

Configuration parameters defining the costs of forwarding

• lump_price: This parameter means the base price for forwarding a message, regardless of its size or complexity.

• bit_price: This parameter represents the cost per bit of message forwarding.

• cell_price: This parameter reflects the cost of forwarding a message per cell. A cell is the basic unit of data storage on the TON Blockchain.

• ihr_price_factor: This is a factor used to calculate the cost of immediate hypercube routing (IHR).

• first_frac: This parameter defines the fraction of the remaining amount that will be used for the first transition along the message route.

• next_frac: This parameter defines the fraction of the remaining amount that will be used for subsequent transitions along the message route.

Parameter #24 on mainnet | Parameter #25 on mainnet

Param 28: catchain config

This parameter provides the configuration for the Catchain protocol in the TON Blockchain. Catchain is the lowest-level consensus protocol used in the TON to achieve agreement among validators.

Configuration parameters

• flags: A general field that can be used to set various binary parameters. In this case, it equals 0, which means that no specific flags are set.

• shuffle_mc_validators: A Boolean value indicating whether to shuffle the masterchain validators or not. If this parameter is set to 1, the validators will be shuffled; otherwise, they will not.

• mc_catchain_lifetime: The lifetime of masterchain's Catchain groups in seconds.

• shard_catchain_lifetime: The lifetime of shardchain's Catchain groups in seconds.

• shard_validators_lifetime: The lifetime of a shardchain's validators group in seconds.

• shard_validators_num: The number of validators in each shardchain validation group.

Parameter #28 on mainnet

Param 29: consensus config

This parameter provides the configuration for the consensus protocol above Catchain (Param 28) in the TON Blockchain. The consensus protocol is a crucial component of a blockchain network: it ensures that all nodes agree on the state of the distributed ledger.

Configuration parameters

• flags: A general field that can be used to set various binary parameters.

• use_quic: A Boolean value indicating whether the legacy Catchain consensus path uses QUIC transport instead of RLDP2. Introduced in consensus_config_v4#d9; has the same meaning as the use_quic field in Param 30.

• new_catchain_ids: A Boolean value indicating whether to generate new Catchain identifiers.

• round_candidates: The number of candidates to be considered in each round of the consensus protocol.

• next_candidate_delay_ms: The delay in milliseconds before the right to generate a block candidate passes to the next validator.

• consensus_timeout_ms: The timeout for block consensus in milliseconds.

• fast_attempts: The number of "fast" attempts to reach consensus.

• attempt_duration: The duration of each attempt at agreement, in seconds.

• catchain_max_deps: The maximum number of dependencies of a Catchain block.

• max_block_bytes: The maximum size of a block in bytes.

• max_collated_bytes: The maximum size of serialized block correctness proofs in bytes.

• proto_version: The protocol version.

• catchain_max_blocks_coeff: The coefficient that limits the Catchain block generation rate, as described in Catchain DoS protection.

On-chain schema

ConfigParam 29 is a tagged union: validators must accept all of its constructors, including legacy ones. This ensures that older serialized configurations continue to be valid while newer on-chain values are written using the latest tag.

The constructors defined in block.tlb are:

consensus_config#d6 round_candidates:# { round_candidates >= 1 }
  next_candidate_delay_ms:uint32 consensus_timeout_ms:uint32
  fast_attempts:uint32 attempt_duration:uint32 catchain_max_deps:uint32
  max_block_bytes:uint32 max_collated_bytes:uint32 = ConsensusConfig;

consensus_config_new#d7 flags:(## 7) { flags = 0 } new_catchain_ids:Bool
  round_candidates:(## 8) { round_candidates >= 1 }
  next_candidate_delay_ms:uint32 consensus_timeout_ms:uint32
  fast_attempts:uint32 attempt_duration:uint32 catchain_max_deps:uint32
  max_block_bytes:uint32 max_collated_bytes:uint32 = ConsensusConfig;

consensus_config_v3#d8 flags:(## 7) { flags = 0 } new_catchain_ids:Bool
  round_candidates:(## 8) { round_candidates >= 1 }
  next_candidate_delay_ms:uint32 consensus_timeout_ms:uint32
  fast_attempts:uint32 attempt_duration:uint32 catchain_max_deps:uint32
  max_block_bytes:uint32 max_collated_bytes:uint32
  proto_version:uint16 = ConsensusConfig;

consensus_config_v4#d9 flags:(## 6) { flags = 0 } use_quic:Bool new_catchain_ids:Bool
  round_candidates:(## 8) { round_candidates >= 1 }
  next_candidate_delay_ms:uint32 consensus_timeout_ms:uint32
  fast_attempts:uint32 attempt_duration:uint32 catchain_max_deps:uint32
  max_block_bytes:uint32 max_collated_bytes:uint32
  proto_version:uint16 catchain_max_blocks_coeff:uint32 = ConsensusConfig;

_ ConsensusConfig = ConfigParam 29;

Parameter #29 on mainnet

Param 30: consensus extension

This parameter configures Catchain 2.0 — the Simplex-based consensus protocol that succeeds the original Catchain. The settings are optional and can be supplied independently for each chain. Block-size limits are not duplicated here: the node continues to read max_block_bytes and max_collated_bytes from ConfigParam 29.

crypto/block/block.tlb defines the following schema:

simplex_config#21 flags:(## 7)
  use_quic:Bool
  target_rate_ms:uint32
  slots_per_leader_window:uint32
  first_block_timeout_ms:uint32
  max_leader_window_desync:uint32
  = NewConsensusConfig;

simplex_config_v2#22 flags:(## 5)
  protocol_version:(## 2)
  use_quic:Bool
  slots_per_leader_window:uint32
  noncritical_params:(HashmapE 8 uint32)
  = NewConsensusConfig;

new_consensus_config_all#10
  mc:(Maybe ^NewConsensusConfig)
  shard:(Maybe ^NewConsensusConfig)
  = NewConsensusConfigAll;

_ NewConsensusConfigAll = ConfigParam 30;

The simplex_config_v2#22 constructor moves noncritical configuration parameters into a sparse dictionary. There are 2 optional references in new_consensus_config_all#10. If a reference is absent, the pre-2.0 Catchain configuration remains active for the corresponding class of chains:

The NewConsensusConfig has two constructors:

• simplex_config#21 is the legacy fixed-layout format; scheduled for removal.
• simplex_config_v2#22 is the modern extensible format, which supports arbitrary noncritical_params without changes to the block.tlb layout.

Configuration parameters of simplex_config_v2

• flags: A reserved 5-bit field for miscellaneous binary parameters.
• protocol_version: Selects protocol behaviors within the Simplex implementation.
• use_quic: Whether the protocol uses QUIC instead of RLDP2.
• slots_per_leader_window: The number of consecutive slots assigned to 1 leader.
• noncritical_params: A HashmapE 8 uint32 map from parameter IDs to raw 32-bit values.

Inherited from Param 29:

• max_block_bytes — maximum block size.
• max_collated_bytes — maximum size of serialized block correctness proofs.

The noncritical_params dictionary contains adjustable timing and DoS-protection parameters that can be changed via a config update without altering the block.tlb layout:

• The key is an 8-bit parameter ID.
• The value is always a raw 32-bit word.
• Unknown IDs are ignored by the current implementation.
• Missing IDs use default values.
• Duration-like parameters store milliseconds directly.
• Floating-point parameters store float32 bits according to the IEEE-754 standard in a uint32 value. The loader then reinterprets these bits as a floating-point numeric value.

IDs from 0 through 16 are recognized and supported. Missing IDs use the defaults shown below — the explorer shows which IDs are present on-chain.

Parameter #30 on mainnet

Param 31: fee-exempt contracts

This parameter represents the configuration of smart contract addresses from which no fees are charged for either gas or storage, and where tick-tock transactions can be created. The list usually includes governance contracts. The parameter is presented as a binary tree structure — a tree (HashMap 256), where the keys are a 256-bit representation of the address. Only addresses in the masterchain can be present in this list.

Validators classify an account as special when it resides in the masterchain and its address appears in this parameter. The configuration smart contract and the elector smart contract are also special, even when their addresses do not appear in parameter 31.

Every basechain account and every other masterchain account is non-special (regular). Only special accounts receive the protocol privileges associated with this classification, including permission to change public libraries.

Parameter #31 on mainnet

Param 32, 34, and 36: validator lists

These parameters store validator sets from the previous (32), current (34), and next (36) election rounds. Parameter 36 is set from the end of an election until the start of its round — it is not available at other times.

Configuration parameters

• utime_since and utime_until: These parameters provide the time period during which these validators are active.

• total and main: These parameters provide the total number of validators and the number of validators validating the masterchain in the network.

• total_weight: This adds up the weights of the validators.

• list: A dictionary keyed by validator index. Each value contains the validator's public key, weight, and optional ADNL address.

Parameter #32 on mainnet | Parameter #34 on mainnet | Parameter #36 on mainnet

Param 33, 35, and 37: temporary validator lists

These parameters are the temporary counterparts of parameters 32, 34, and 36. They use the same validator sets schema for the previous (33), current (35), and next (37) election rounds.

Parameter #33 on mainnet | Parameter #35 on mainnet | Parameter #37 on mainnet

Param 39: temporary validator keys

This parameter maps permanent validator key hashes to signed temporary-key certificates. Each certificate records an ADNL address, temporary public key, sequence number, expiration time, and validator signature.

Parameter #39 on mainnet

Param 40: misbehavior punishment

This parameter defines the structure of the configuration for punishment for improper behavior (non-validation). In the absence of the parameter, the default fine size is 101 Gram.

Configuration parameters

MisbehaviourPunishmentConfig: This data structure defines how improper behavior in the system is punished.

It contains several fields:

• default_flat_fine: This part of the fine does not depend on the stake size.

• default_proportional_fine: This part of the fine is proportional to the validator's stake size.

• severity_flat_mult: This is the multiplier applied to the default_flat_fine value for significant violations by the validator.

• severity_proportional_mult: This is the multiplier applied to the default_proportional_fine value for significant violations by the validator.

• unpunishable_interval: This parameter represents the period during which offenders are not punished to eliminate temporary network problems or other anomalies.

• long_interval, long_flat_mult, long_proportional_mult: These parameters define a "long" period of time and multipliers for flat and proportional fines for improper behavior.

• medium_interval, medium_flat_mult, medium_proportional_mult: Similarly, they define a "medium" period of time and multipliers for flat and proportional fines for improper behavior.

Parameter #40 on mainnet

Param 43: account and message limits

This parameter imposes various limits on account state, messages, public libraries, and TVM data. New fields are added over time — fields absent from an older on-chain constructor tag use node defaults.

Configuration parameters

• max_msg_bits: Maximum message size in bits.

• max_msg_cells: Maximum number of cells a message can occupy.

• max_library_cells: Maximum number of cells that can be used for library cells.

• max_vm_data_depth: Maximum cell depth in messages and account state.

• max_ext_msg_size: Maximum serialized external message size in bytes.

• max_ext_msg_depth: Maximum cell depth of an external message.

• max_acc_state_cells and max_mc_acc_state_cells: Maximum number of cells in an account state outside and inside the masterchain, respectively.

• max_acc_public_libraries: Maximum number of public libraries in an account state.

• defer_out_queue_size_limit: Outbound queue size threshold used to defer message processing during collation.

• max_msg_extra_currencies: Maximum number of nonzero extra currencies in a message.

• max_acc_fixed_prefix_length: Maximum fixed address-prefix length accepted for an account.

• acc_state_cells_for_storage_dict: Account-state cell threshold for storing its hash in storage statistics.

• max_transaction_library_loads: Optional maximum number of public-library loads during 1 transaction. An absent value leaves the number unlimited.

• max_total_msg_bits and max_total_msg_cells: Maximum aggregate size of messages created during 1 transaction.

Parameter #43 on mainnet

Param 44: suspended addresses

This parameter defines the list of suspended addresses, which cannot be initialized until suspended_until. It only applies to yet uninitiated accounts. This is a measure for stabilizing the tokenomics (limiting early miners). If not set, there are no limitations. Each address is represented as an end node in this tree, and the tree-like structure allows efficient checking of whether an address is in the list.

Parameter #44 on mainnet

Param 45: precompiled contracts

The list of precompiled contracts is stored in the masterchain config:

precompiled_smc#b0 gas_usage:uint64 = PrecompiledSmc;
precompiled_contracts_config#c0 list:(HashmapE 256 PrecompiledSmc) = PrecompiledContractsConfig;
_ PrecompiledContractsConfig = ConfigParam 45;

More details about precompiled contracts are on this page.

Parameter #45 on mainnet

Param 46: validator registry

This parameter configures the validator registry that assigns collators to validators.

• contract_address: The masterchain address of the registry smart contract. The contract must also be listed as fundamental in parameter 31.

• max_collators_per_validator: The maximum number of collator entries that a node reads for 1 validator.

• new_code_hash: An optional replacement code hash recorded for a registry upgrade.

Parameter #46 on mainnet

Param 71 - 73: outbound bridges

This parameter pertains to bridges for wrapping Gram in other networks:

• ETH-TON (71)
• BNB-TON (72)
• Polygon-TON (73)

Configuration parameters

• bridge_address: This is the bridge contract address that accepts Grams to issue wrapped Grams in other networks.

• oracle_multisig_address: This is the bridge management wallet address. A multisig wallet is a type of digital wallet that requires signatures from multiple parties to authorize a transaction. It is often used to increase security. The oracles act as the parties.

• oracles: List of oracles in the form of a tree id->address

• external_chain_address: This is the bridge contract address in the corresponding external blockchain.

Parameter #71 on mainnet | Parameter #72 on mainnet | Parameter #73 on mainnet

Param 79, 81, and 82: inbound bridges

This parameter relates to bridges for wrapping tokens from other networks into tokens on the TON network:

• ETH-TON (79)
• BNB-TON (81)
• Polygon-TON (82)

Configuration parameters

• bridge_address and oracles_address: These are the blockchain addresses of the bridge and the bridge management contract (oracles multisig), respectively.

• oracles: List of oracles in the form of a tree id->address

• state_flags: State flag. This parameter is responsible for enabling/disabling separate bridge functions.

• prices: This parameter contains a list or dictionary of prices for different operations or fees associated with the bridge, such as bridge_burn_fee, bridge_mint_fee, wallet_min_tons_for_storage, wallet_gas_consumption, minter_min_tons_for_storage, discover_gas_consumption.

• external_chain_address: The bridge contract address in another blockchain.

Parameter #79 on mainnet | Parameter #81 on mainnet | Parameter #82 on mainnet

Negative parameters

Validators enforce TL-B validity only for configuration parameters with non-negative indices. Values with negative indices are not validated against a specific ConfigParam i type. These values are also referred to as negative parameters or extension slots.

Extension slots are implementation-specific, and their meaning comes from the contracts that read them rather than from block.tlb — extension slots are absent from it.

The following table lists known named extension slots:

Reference

Source code:

• mc-config.h
• block.tlb

Original descriptions, which may be limited or outdated with respect to source code:

• The Open Network Whitepaper
• Telegram Open Network Blockchain