Skip to content

feat(foundations): update config for [04.2026] release #2083

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
reveloper wants to merge 7 commits into
base: main
Choose a base branch
from
+93 −0
Draft

feat(foundations): update config for [04.2026] release #2083

Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
88e9d67
Update config docs
reveloper Apr 14, 2026
4b1d3f4
Apply suggestion
novusnota Apr 14, 2026
58cf126
Apply suggestion
novusnota Apr 14, 2026
cda2bd9
fmt and ID
novusnota Apr 14, 2026
22c529f
edits
novusnota Apr 14, 2026
694a47c
whoopsie
novusnota Apr 14, 2026
88efab9
no slashes
novusnota Apr 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 93 additions & 0 deletions foundations/config.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -462,6 +462,99 @@ For up-to-date values, see [https://tonviewer.com/config](https://tonviewer.com/

[Parameter #29 on mainnet](https://tonviewer.com/config#29)

## Param 30: consensus extension

<Aside type="note">
The [TON v2026.03](https://github.com/ton-blockchain/ton/releases/tag/v2026.03) update introduced this parameter on testnet. With the [TON `v2026.04`](https://github.com/ton-blockchain/ton/releases/tag/v2026.04) update, `ConfigParam 30` was enabled on mainnet.
Copy link
Copy Markdown
Contributor

@delovoyhomie delovoyhomie Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nit inside the Aside: TON v2026.03 is plain text while TON \v2026.04`is wrapped in a code span, even though they are the same kind of release tag. Could we pick one and apply it to both? I would lean toward code spans for both, since the surrounding section refers toConfigParam 30/ConfigParam 29` in code font.

</Aside>

This parameter stores optional per-workchain settings for the [Simplex](https://github.com/ton-blockchain/simplex-docs/blob/main/Simplex.md)-based Catchain 2.0 consensus path. It does not fully replace `ConfigParam 29`: the node still uses `max_block_size` and `max_collated_data_size` from the `ConfigParam 29`.
Copy link
Copy Markdown
Contributor

@delovoyhomie delovoyhomie Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we replace ConfigParam 29 here with a deep link to the existing ## Param 29: consensus config section on this same page ([Param 29](#param-29-consensus-config))? The style guide asks for deep-linking to the exact section that contains the needed fact, and every other reference to a parameter on this page uses the Param N form — ConfigParam N is only used inside TL-B. Also the phrase from the \ConfigParam 29`at the end of the sentence reads a bit awkward;from Param 29` would fix both in one go.


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;
```

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.

The `simplex_config_v2#22` constructor moves noncritical configuration parameters into a sparse dictionary:

```tlb
simplex_config_v2#22 flags:(## 7)
Copy link
Copy Markdown
Contributor

@delovoyhomie delovoyhomie Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This simplex_config_v2#22 block is an exact duplicate of the one in the full schema above (lines 484–488). Could we drop this second copy? The sentence introducing it (moves noncritical configuration parameters into a sparse dictionary) already makes the point, and the table of IDs below makes the payload concrete — having the same TL-B twice on the same screen just invites the two copies to drift later if one is edited.

use_quic:Bool
slots_per_leader_window:uint32
noncritical_params:(HashmapE 8 uint32)
= NewConsensusConfig;
```

### 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** in mainnet.
- `slots_per_leader_window`: Number of consecutive slots assigned to one leader. Set to **4** in mainnet.
Comment thread
novusnota marked this conversation as resolved.
- `max_block_size = 4 MiB`
Copy link
Copy Markdown
Contributor

@delovoyhomie delovoyhomie Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the simplex_config_v2#22 TL-B above, the constructor only has flags, use_quic, slots_per_leader_window, and noncritical_params — max_block_size and max_collated_data_size are not fields of this structure. The opening paragraph already says the node keeps reading those two from ConfigParam 29, so listing them under ### Configuration parameters of simplex_config_v2 reads as if they were part of the v2 constructor. Could we move these two bullets out of this list (or put them under a separate Inherited from Param 29 sub-bullet) so the list matches the TL-B?

- `max_collated_data_size = 4 MiB`
- `noncritical_params`: A `HashmapE 8 uint32` map from parameter IDs to raw 32-bit values.

The `noncritical_params` dictionary contains tunable timing and DoS-protection parameters that might differ between validators:

- 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/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 | `100000 ms` | Cap for the adaptive `first_block_timeout` growth. |
Copy link
Copy Markdown
Contributor

@delovoyhomie delovoyhomie Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style-guide nit (style-guide-extended.mdx asks for thousands separators on values ≥ 10,000): in the Default column that applies to ID 3 (100000 ms → 100,000 ms), IDs 6 and 8 (10000 ms → 10,000 ms), ID 9 (6553600 → 6,553,600), and ID 14 (15000 ms → 15,000 ms). Values below 10,000 (2400, 1000, 5000, etc.) are already fine.

| `4` | `candidate_resolve_timeout` | `uint32` milliseconds | `1000 ms` | Initial timeout for candidate / notarization resolution requests. |
Comment thread
novusnota marked this conversation as resolved.
Outdated
| `5` | `candidate_resolve_timeout_multiplier` | `float32` bits in `uint32` | `1.2` | Backoff multiplier for candidate resolution retries. |
| `6` | `candidate_resolve_timeout_cap` | `uint32` milliseconds | `10000 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 | `10000 ms` | No-progress timeout before standstill recovery or rebroadcast logic triggers. |
| `9` | `standstill_max_egress_bytes_per_s` | `uint32` number | `6553600` (`50 << 17`) | Egress rate cap used during standstill rebroadcast. |
| `10` | `max_leader_window_desync` | `uint32` number | `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` number | `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 | `15000 ms` | How long empty-block fallback is allowed after the last finalized block when collation fails or times out. |
Copy link
Copy Markdown
Contributor

@delovoyhomie delovoyhomie Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Every other parameter section on this page ends with a [Parameter #N on mainnet](https://tonviewer.com/config#N) link right before the next ## heading (see Param 29 at line 463 and Param 31 at line 562). Param 30 is the only section without it — could we add [Parameter #30 on mainnet](https://tonviewer.com/config#30) here for consistency?


## 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.
Expand Down
Loading