Skip to main content

Governance contracts

In TON, a set of special smart contracts controls consensus parameters for node operation — including TVM, Catchain, fees, and chain topology — and how these parameters are stored and updated. Unlike older blockchains that hardcode these parameters, TON enables transparent on-chain governance. The current governance contracts include the Elector and Config contracts; DNS is a related system contract (not governing consensus). Future expansion may include a Minter for extra-currencies.

Elector​

The Elector smart contract manages validator elections, validation rounds, and reward distribution. To become a validator and interact with the Elector, follow the validator instructions and the internal guide.

Data storage​

The Elector stores:

  • Non-withdrawn Toncoin in the credits hashmap.
  • New validator applications in the elect hashmap.
  • Past election data in the past_elections hashmap (including complaints and frozen stakes held for stake_held_for periods, defined in ConfigParam 15).

Key functions​

  1. Process validator applications
  2. Conduct elections
  3. Handle validator misbehavior reports
  4. Distribute validation rewards

Processing applications​

To apply, a validator must:

  1. Send a message to the Elector with their ADNL address, public key, max_factor, and stake (Toncoin amount).
  2. The Elector validates the parameters and either registers the application or refunds the stake. Note: Only masterchain addresses can apply.

Conducting elections​

The Elector is a special smart contract that receives protocol-delivered tick‑tock transactions at the start and end of each MasterChain block. It checks whether it’s time to conduct a new election during each block.

Process details:

  • Take applications with stake ≥ min_stake (ConfigParam 17).
  • Arrange candidates by stake in descending order.
  • If applicants exceed max_validators (ConfigParam 16), discard the lowest-staked candidates.
  • For each subset size i (from 1 to remaining candidates):
    • Assume the i-th candidate (lowest in the subset) defines the baseline.
    • Calculate effective stake (true_stake) for each candidate as:
min(stake, max_factor * min_stake_in_subset)
  • Track the subset with the highest total effective stake (TES).
  • Submit the winning validator set to the Config contract.
  • Return unused stakes and excess amounts (e.g., stake[j] - min(stake[i] * max_factor[j], stake[j])) to credits.

Example breakdown:

  • Case 1: 9 candidates stake 100,000 Toncoin (max_factor=2.7), 1 candidate stakes 10,000.

    • Without the 10k candidate: TES = 900,000.
    • With the 10k candidate: TES = 9 * 27,000 + 10,000 = 253,000.
    • Result: 10k candidate is excluded.

  • Case 2: 1 candidate stakes 100,000 (max_factor=2.7), 9 stake 10,000.

    • Effective stake for the 100k candidate: 10,000 * 2.7 = 27,000.
    • Excess: 100,000 - 27,000 = 73,000 → sent to credits.
    • Result: All 10 participate.

Election constraints:

  • min_validators ≤ participants ≤ max_validators (ConfigParam 16).
  • Stakes must satisfy:
  • min_stake ≤ stake ≤ max_stake
    • min_total_stake ≤ total stake
    • Stake ratios ≤ max_stake_factor (ConfigParam 17).
  • If conditions aren’t met, elections are postponed.

Process of reporting validator misbehavior​

Each validator is periodically assigned the duty to create new blocks, with the frequency of assignments determined by their weight. After a validation round, anyone can audit the blocks to check whether the actual number of blocks produced by a validator significantly deviates from the expected number (based on their weight). A statistically significant underperformance (e.g., fewer blocks created than expected) constitutes misbehavior.

To report misbehavior, a user must:

  1. Provide cryptographic proof demonstrating the validator's failure to produce the expected blocks.
  2. Submit the proof to the Elector contract, covering the associated storage costs.

The Elector registers the complaint in the past_elections hashmap. Current round validators then verify the complaint. If the proof is valid, validators vote on the complaint. Approval requires agreement from more than three-quarters of the total validator weight and follows the wins/losses limits defined in ConfigParam 11 (not just a majority of participants).

If approved, the fine (as determined by ConfigParam 40 — MisbehaviourPunishmentConfig) is deducted from the validator's frozen stake in the relevant past_elections record. These funds stay locked for the period defined by ConfigParam 15 (stake_held_for).

Distributing rewards​

The Elector releases frozen stakes and rewards (gas fees + block rewards) proportionally to past validators. Funds move to credits, and the election record clears from past_elections.

Current Elector state​

Track live data (elections, stakes, complaints) via this dApp. This is a community tool; use at your own risk.

Config​

The Config contract manages TON’s configuration parameters, validator set updates, and proposal voting.

Validator set updates​

  1. The Elector notifies Config of a new validator set.
  2. Config stores it in ConfigParam 36 (next validators).
  3. At the scheduled time (utime_since), Config:

Proposal/voting mechanism​

  1. Submit a proposal: Pay storage fees to propose parameter changes.
  2. Vote: Validators (from ConfigParam 34) sign approval messages.
  3. Outcome:
    • Approved: After min_wins rounds (ConfigParam 11) with ≥3/4 weighted votes.
    • Rejected: After max_losses rounds.
    • Critical parameters (ConfigParam 10) require more rounds.

Emergency updates​

Code upgrades are proposed via special configuration parameters: -1000 (Config) and -1001 (Elector).

See also​

Was this article useful?