# Blockchain configuration (https://docs-orhepa2tm-ton-core-docs.vercel.app/llms/foundations/config/content.md) View live values on [Tonscan](https://tonscan.org/config) or [Tonviewer](https://tonviewer.com/config). 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 [#prerequisites] The parameter values in the [current configuration](https://tonviewer.com/config), and the method of writing them into [cells](/llms/foundations/serialization/boc/content.md) are outlined in the [`block.tlb`](https://github.com/ton-blockchain/ton/blob/master/crypto/block/block.tlb) file in [TL-B](/llms/languages/tl-b/overview/content.md) format. Configuration values are TL-B typed cells serialized into [Bags of Cells (BoC)](/llms/foundations/serialization/boc/content.md). All parameters are in place, and you won't get lost. For your convenience, please use the right sidebar for quick navigation. ### Overview [#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`: ```tlb _ 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 the source file [`crypto/block/block.tlb`](https://github.com/ton-blockchain/ton/blob/05bea13375448a401d8e07c6132b7f709f5e3a32/crypto/block/block.tlb), where `ConfigParam i` is specified for different values of `i`. For example: ```tlb _ 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 currently enabled "global version". This is followed by a 64-bit integer with flags that correspond to the currently enabled capabilities. A more detailed description of all configuration parameters will be provided in an appendix to the TON blockchain documentation. In the meantime, you can review the TL-B scheme in [`crypto/block/block.tlb`](https://github.com/ton-blockchain/ton/blob/05bea13375448a401d8e07c6132b7f709f5e3a32/crypto/block/block.tlb) to see how different parameters are utilized in the validator sources. 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 [#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 [#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. In the configuration parameter, only the hash portion of the address is recorded, as the contract always resides in the masterchain (workchain -1). Therefore, the full address of the contract will be written as `-1:`. [Parameter #0 on mainnet](https://tonviewer.com/config#0) ## Param 1: elector address [#param-1-elector-address] This parameter is the address of the [elector smart contract](/llms/foundations/system/content.md), responsible for appointing validators, distributing rewards, and voting on changes to blockchain parameters. [Parameter #1 on mainnet](https://tonviewer.com/config#1) ## Param 2: TON minting address [#param-2-ton-minting-address] This parameter represents the address of the system, on behalf of which new Toncoin are minted and sent as rewards for validating the blockchain. If parameter 2 is missing, parameter 0 is used instead — newly minted Toncoin come from the configuration smart contract. [Parameter #2 on mainnet](https://tonviewer.com/config#2) ## Param 3: fee collector address [#param-3-fee-collector-address] This parameter is the address of the transaction fee collector. If this parameter is missing (for the time being), transaction fees are directed to the elector smart contract (parameter 1). [Parameter #3 on mainnet](https://tonviewer.com/config#3) ## Param 4: root DNS address [#param-4-root-dns-address] This parameter is the address of the root DNS contract of the TON network. For details, see the [TON DNS](/llms/foundations/web3/ton-dns/content.md) page and the [original specification](https://github.com/ton-blockchain/TEPs/blob/master/text/0081-dns-standard.md). This contract is not responsible for selling **.ton** domains. [Parameter #4 on mainnet](https://tonviewer.com/config#4) ## Param 6: extra currency fee [#param-6-extra-currency-fee] This parameter is responsible for minting fees for new currencies. [Parameter #6 on mainnet](https://tonviewer.com/config#6) ## Param 7: extra currency volume [#param-7-extra-currency-volume] This parameter stores the volume of each extra currency in circulation. The data is organized as a dictionary (also referred to as a **hashmap**). The structure uses the format `currency_id -> amount`, where the amount is represented as a `VarUInteger 32`, which is an integer ranging from `0` to `2^248-1`. [Parameter #7 on mainnet](https://tonviewer.com/config#7) ## Param 8: network version [#param-8-network-version] This parameter indicates the network version and additional capabilities supported by the validators. Validators are nodes in the TON Blockchain network that are responsible for creating new blocks and verifying transactions. * `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](https://tonviewer.com/config#8) ## Param 9: mandatory params [#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](https://tonviewer.com/config#9) ## Param 10: critical params [#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](https://tonviewer.com/config#10) ## Param 11: config params [#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](https://tonviewer.com/config#11) ## Param 12: Workchain config [#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 [#workchain-configuration-parameters] * `enabled_since`: A UNIX timestamp of the moment this workchain was enabled. * `actual_min_split`: The minimum depth of the split (sharding) of this workchain, supported by validators. * `min_split`: The minimum depth of the split of this workchain, set by the configuration. * `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 (handles TON coins, 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 format of the workchain, which includes `vm_version` and `vm_mode` - the virtual machine used there. [Parameter #12 on mainnet](https://tonviewer.com/config#12) ## Param 13: complaint cost [#param-13-complaint-cost] This parameter defines the cost of filing complaints about the incorrect operation of validators in the [elector smart contract](/llms/foundations/system/content.md). [Parameter #13 on mainnet](https://tonviewer.com/config#13) ## Param 14: block reward [#param-14-block-reward] This parameter indicates the reward for creating a block in the TON Blockchain. Values are in nanotons (also referred to as nanograms); therefore, the reward for block creation in the masterchain is 1.7 Toncoin, while in the basechain, it is 1.0 Toncoin. In the event of a workchain split, the block reward is also divided: if there are two shardchains within the workchain, then the reward for each shard block will be 0.5 Toncoin. [Parameter #14 on mainnet](https://tonviewer.com/config#14) ## Param 15: elections timing [#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 [#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. Each value in the arguments is determined by the `uint32` data type. ### Examples [#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 [#mainnet] Current values: ```python 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: Election timing scheme (Mainnet) #### How to calculate periods? [#how-to-calculate-periods] Let `election_id = validation_start = 1600032768`. Then: ```python 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 [#testnet] Current values: ```python 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: Election timing scheme (Testnet) #### How to calculate periods? [#how-to-calculate-periods-1] Let `election_id = validation_start = 160002400`. Then: ```python 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](https://tonviewer.com/config#15) ## Param 16: validators limits [#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 [#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 [#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](https://tonviewer.com/config#16) ## Param 17: stake limits [#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 [#configuration-parameters] * `min_stake`: This parameter represents the minimum amount of Toncoin that an interested party needs to stake to participate in the validation process. * `max_stake`: This parameter represents the maximum amount of Toncoin that an interested party can stake. * `min_total_stake`: This parameter represents the minimum total amount of Toncoin 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. Each value in the arguments is determined by the `uint32` data type. [Parameter #17 on mainnet](https://tonviewer.com/config#17) ## Param 18: storage prices [#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 [#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. `utime_since` accepts values in the `uint32` data type. The rest accept values in the `uint64` data type. [Parameter #18 on mainnet](https://tonviewer.com/config#18) ## Param 20 and 21: gas prices [#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 nanotons 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 nanotons) at which a contract is frozen and deleted, respectively. You can find more about `gas_credit` and other parameters in the section of external messages [here](/llms/foundations/messages/external-in/content.md). [Parameter #20 on mainnet](https://tonviewer.com/config#20) | [Parameter #21 on mainnet](https://tonviewer.com/config#21) ## Param 22 and 23: block limits [#param-22-and-23-block-limits] These parameters set limits on the block, upon reaching which the block is finalized and the callback of the remaining messages (if any) is carried over to the next block. ### Configuration parameters [#configuration-parameters-1] * `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. If a shard has insufficient load and there is an intention to merge with a neighboring shard, the `soft_limit` indicates a threshold. When this threshold is exceeded, internal messages will stop being processed, while external messages will still be handled. External messages will continue to be processed until the total reaches a limit that is equal to half the sum of the `soft_limit` and `hard_limit`, or `(soft_limit + hard_limit) / 2`. [Parameter #22 on mainnet](https://tonviewer.com/config#22) | [Parameter #23 on mainnet](https://tonviewer.com/config#23) ## Param 24 and 25: message price [#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 [#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). IHR is a method of message delivery in the TON Blockchain network, where messages are sent directly to the recipient's shardchain. * `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](https://tonviewer.com/config#24) | [Parameter #25 on mainnet](https://tonviewer.com/config#25) ## Param 28: catchain config [#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 [#configuration-parameters-2] * `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](https://tonviewer.com/config#28) ## Param 29: consensus config [#param-29-consensus-config] This parameter provides the configuration for the consensus protocol above `Catchain` ([Param 28](#param-28-catchain-config)) 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. `ConfigParam 29` has evolved through several updates. The latest constructor, `consensus_config_v4#d9`, is defined in [`block.tlb`](https://github.com/ton-blockchain/ton/blob/v2026.04/crypto/block/block.tlb#L782). It extends `consensus_config_v3#d8` with a new `use_quic:Bool` field, taking one bit from `flags`, which shrinks from 7 to 6 bits. It also adds `catchain_max_blocks_coeff:uint32` field at the end. ### Configuration parameters [#configuration-parameters-3] * `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](#param-30-consensus-extension). * `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 limiting the rate of block generation in `Catchain`, [description](https://github.com/ton-blockchain/ton/blob/master/doc/catchain-dos.md). For up-to-date values, see [Parameter #29 on mainnet](https://tonviewer.com/config#29). ### On-chain schema [#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 current set defined in [`block.tlb`](https://github.com/ton-blockchain/ton/blob/v2026.04/crypto/block/block.tlb#L782) is: ```tlb 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; ``` `consensus_config_v4#d9` was introduced together with the [Catchain 2.0 / Simplex](https://github.com/ton-blockchain/simplex-docs/blob/main/Simplex.md) migration tracked by [Param 30](#param-30-consensus-extension). The `use_quic` toggle in Param 29 controls the transport for the legacy Catchain path; the `use_quic` toggle in Param 30 controls the transport for the new Simplex path. They are configured independently. [Parameter #29 on mainnet](https://tonviewer.com/config#29) ## Param 30: consensus extension [#param-30-consensus-extension] * [TON v2026.03](https://github.com/ton-blockchain/ton/releases/tag/v2026.03): `ConfigParam 30` introduced on testnet. * [TON v2026.04](https://github.com/ton-blockchain/ton/releases/tag/v2026.04): `ConfigParam 30` enabled on mainnet. This parameter configures [Catchain 2.0](https://github.com/ton-blockchain/simplex-docs/blob/main/Simplex.md) — 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`](/llms/foundations/config/content.md). The `crypto/block/block.tlb` [defines](https://github.com/ton-blockchain/ton/blob/v2026.04/crypto/block/block.tlb#L782) the following schema: ```tlb 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:(## 7) 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 two optional refs in `new_consensus_config_all#10`. If a ref is absent, then the pre-2.0 Catchain config is active for the corresponding class of chains: | Field | Type | Meaning | | ------- | --------------------------- | ------------------------------------------------------- | | `mc` | `Maybe ^NewConsensusConfig` | Config for the masterchain (`workchain = -1`) | | `shard` | `Maybe ^NewConsensusConfig` | Config for shardchains (all non-masterchain workchains) | The `NewConsensusConfig` has two constructors: * `simplex_config#21` is the legacy fixed-layout format; scheduled for removal. * `simplex_config_v2#22` is the current extensible format, which supports arbitrary `noncritical_params` without changes to the `block.tlb` layout. ### Configuration parameters of `simplex_config_v2` [#configuration-parameters-of-simplex_config_v2] * `flags`: A general field that can be used to set various binary parameters. * `use_quic`: Whether the QUIC transport is used instead of RLDP2. Set to `true` on mainnet. * `slots_per_leader_window`: Number of consecutive slots assigned to one leader. Set to `4` on mainnet. * `noncritical_params`: A `HashmapE 8 uint32` map from parameter IDs to raw 32-bit values. Inherited from [Param 29](/llms/foundations/config/content.md): * `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](https://en.wikipedia.org/wiki/IEEE_754) standard in a `uint32` value. The loader then reinterprets these bits as a floating-point numeric value. IDs from `0` through `14` are recognized and supported. On the mainnet, only IDs `0`, `1`, and `13` are explicitly set. All other IDs are normally absent and use defaults. | ID | Name | Stored as | Default | Meaning | | ---- | -------------------------------------- | -------------------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------- | | `0` | `target_rate` | `uint32` milliseconds | `2400 ms` | Target slot or block interval; used for leader pacing, block production timing, and skip scheduling. | | `1` | `first_block_timeout` | `uint32` milliseconds | `1000 ms` | Base timeout before skip voting starts for the first missing block in a leader window. | | `2` | `first_block_timeout_multiplier` | `float32` bits in `uint32` | `1.2` | Multiplier applied to `first_block_timeout` after a window that had skips. | | `3` | `first_block_timeout_cap` | `uint32` milliseconds | `100,000 ms` | Cap for the adaptive `first_block_timeout` growth. | | `4` | `candidate_resolve_timeout` | `uint32` milliseconds | `1000 ms` | Initial timeout for candidate or notarization resolution requests. | | `5` | `candidate_resolve_timeout_multiplier` | `float32` bits in `uint32` | `1.2` | Backoff multiplier for candidate resolution retries. | | `6` | `candidate_resolve_timeout_cap` | `uint32` milliseconds | `10,000 ms` | Cap for candidate resolution timeout growth. | | `7` | `candidate_resolve_cooldown` | `uint32` milliseconds | `10 ms` | Cooldown between candidate resolution attempts. | | `8` | `standstill_timeout` | `uint32` milliseconds | `10,000 ms` | No-progress timeout before standstill recovery or rebroadcast logic triggers. | | `9` | `standstill_max_egress_bytes_per_s` | `uint32` | `6,553,600` (`50 << 17`) | Egress rate cap used during standstill rebroadcast. | | `10` | `max_leader_window_desync` | `uint32` | `250` | Maximum tolerated future leader-window distance for inbound Simplex traffic. | | `11` | `bad_signature_ban_duration` | `uint32` milliseconds | `5000 ms` | Temporary ban duration after receiving bad signatures from a peer. | | `12` | `candidate_resolve_rate_limit` | `uint32` | `10` | Per-peer rate limit for candidate resolution requests. | | `13` | `min_block_interval` | `uint32` milliseconds | `0 ms` | Minimum interval between parent block time and the next locally generated block. | | `14` | `no_empty_blocks_on_error_timeout` | `uint32` milliseconds | `15,000 ms` | How long empty-block fallback is allowed after the last finalized block when collation fails or times out. | [Parameter #30 on mainnet](https://tonviewer.com/config#30) ## Param 31: fee-exempt contracts [#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. [Parameter #31 on mainnet](https://tonviewer.com/config#31) ## Param 32, 34, and 36: validator lists [#param-32-34-and-36-validator-lists] Lists of validators from the previous (32), current (34), and next (36) rounds. Parameter 36 is set from the end of the elections until the start of the round. ### Configuration parameters [#configuration-parameters-4] * `cur_validators`: This is the current list of validators. Validators are typically responsible for verifying transactions in a blockchain network. * `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 list of validators in the tree format `id->validator-data`: `validator_addr`, `public_key`, `weight`, `adnl_addr`: These parameters provide details about each validator - their 256-bit addresses in the masterchain, public key, weight, ADNL address (the address used at the network level of the TON). [Parameter #32 on mainnet](https://tonviewer.com/config#32) | [Parameter #34 on mainnet](https://tonviewer.com/config#34) | [Parameter #36 on mainnet](https://tonviewer.com/config#36) ## Param 40: misbehavior punishment [#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 Toncoin. ### Configuration parameters [#configuration-parameters-5] `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](https://tonviewer.com/config#40) ## Param 43: account and message limits [#param-43-account-and-message-limits] This parameter relates to the size limits and other features of accounts and messages. ### Configuration parameters [#configuration-parameters-6] * `max_msg_bits`: Maximum message size in bits. * `max_msg_cells`: Maximum number of cells (a form of storage unit) 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 external message size in bits. * `max_ext_msg_depth`: Maximum external message depth. This could refer to the depth of the data structure within the message. * `max_acc_state_cells`: Maximum number of cells that an account state can occupy. * `max_acc_state_bits`: Maximum account state size in bits. If absent, the default parameters are taken: * `max_size` = 65535 * `max_depth` = 512 * `max_msg_bits` = 1 \<\< 21 * `max_msg_cells` = 1 \<\< 13 * `max_library_cells` = 1000 * `max_vm_data_depth` = 512 * `max_acc_state_cells` = 1 \<\< 16 * `max_acc_state_bits` = (1 \<\< 16) \* 1023 You can view more details about the standard parameters [here](https://github.com/ton-blockchain/ton/blob/fc9542f5e223140fcca833c189f77b1a5ae2e184/crypto/block/mc-config.h#L379) in the source code. [Parameter #43 on mainnet](https://tonviewer.com/config#43) ## Param 44: suspended addresses [#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. The stabilization of the tokenomics is further described in the [official report](https://t.me/tonblockchain/178) of the `@tonblockchain` Telegram channel. [Parameter #44 on mainnet](https://tonviewer.com/config#44) ## Param 45: precompiled contracts [#param-45-precompiled-contracts] The list of precompiled contracts is stored in the masterchain config: ```tlb 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](/llms/foundations/precompiled/content.md). [Parameter #45 on mainnet](https://tonviewer.com/config#45) ## Param 71 - 73: outbound bridges [#param-71---73-outbound-bridges] This parameter pertains to bridges for wrapping Toncoin in other networks: * ETH-TON **(71)** * BNB-TON **(72)** * Polygon-TON **(73)** ### Configuration parameters [#configuration-parameters-7] * `bridge_address`: This is the bridge contract address that accepts TON to issue wrapped Toncoin 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](https://tonviewer.com/config#71) | [Parameter #72 on mainnet](https://tonviewer.com/config#72) | [Parameter #73 on mainnet](https://tonviewer.com/config#73) ## Param 79, 81, and 82: inbound bridges [#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 [#configuration-parameters-8] * `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](https://tonviewer.com/config#79) | [Parameter #81 on mainnet](https://tonviewer.com/config#81) | [Parameter #82 on mainnet](https://tonviewer.com/config#82) ## Negative parameters [#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. ## Next steps [#next-steps] After thoroughly reviewing this article, it is highly recommended that you dedicate time to a more in-depth study of the following documents: * The original descriptions are present, but they may be limited, in the documents: * [The Open Network Whitepaper](/llms/foundations/whitepapers/ton/content.md) * [Telegram Open Network Blockchain](/llms/foundations/whitepapers/tblkch/content.md) * Source code: * [`mc-config.h`](https://github.com/ton-blockchain/ton/blob/fc9542f5e223140fcca833c189f77b1a5ae2e184/crypto/block/mc-config.h) * [`block.tlb`](https://github.com/ton-blockchain/ton/blob/master/crypto/block/block.tlb)