Skip to content
Open
Changes from 7 commits
Commits
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
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)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

small dup: the same Parameter #29 on mainnet link already shows up at line 467 (For up-to-date values, see [Parameter #29 on mainnet](...)), so this trailing standalone link is redundant after the rewrite. probably it makes sense to drop one of them?

Suggested change
[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.
Comment thread
reveloper marked this conversation as resolved.
Outdated
</Aside>
Comment thread
novusnota marked this conversation as resolved.

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`.
Comment thread
reveloper marked this conversation as resolved.
Outdated

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;
Comment on lines +528 to +532
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

small but worth double-checking against the upstream block.tlb at v2026.04 line 782: consensus_config_v4#d9 (line 492 here) has flags:(## 6) { flags = 0 }, while both simplex_config#21 and simplex_config_v2#22 have flags:(## 7) with no { flags = 0 } constraint. is that intentional, or did the flags = 0 predicate just get dropped in the copy? if the upstream schema does require flags = 0 for the simplex configs too, we should keep it here for reviewers who use this page as the spec reference


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)
Comment thread
reveloper marked this conversation as resolved.
Outdated
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.
Comment on lines +558 to +559
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

bolding values like **True** and **4** falls under the no-bold-on-tokens rule of the style guide (see emphasis), code font keeps the literal grep-friendly and matches how Bool values are written elsewhere in the repo (lowercase)

Suggested change
- `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.
- `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.

- `max_block_size = 4 MiB`
Comment thread
reveloper marked this conversation as resolved.
Outdated
- `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:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

tiny but the phrasing might differ between validators reads as if every validator runs its own noncritical config, which isn't the case - the dictionary lives in ConfigParam 30 on-chain, so all validators apply the same values. could we soften to something like tunable across config updates without changing the block.tlb layout?

Suggested change
The `noncritical_params` dictionary contains tunable timing and DoS-protection parameters that might differ between validators:
The `noncritical_params` dictionary contains tunable 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 | `100000 ms` | Cap for the adaptive `first_block_timeout` growth. |
Comment thread
reveloper marked this conversation as resolved.
Outdated
| `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 | `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. |
Comment thread
reveloper marked this conversation as resolved.
Outdated

## 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