TIP-767: Transitioning Voting Window configuration to Chain Governance

[lxcmyf]

tip: 767
title: Transitioning Voting Window configuration to Chain
author: lxcmyf@gmail.com
discussions-to: https://github.com/tronprotocol/tips/issues/767
status: Draft
type: Standards Track 
category: Core
created: 2025-06-09

Simple Summary

This proposal suggests migrating the proposal voting window period from node-local configurations to on-chain governance parameters, ensuring all Super Representatives (SRs) adhere to a unified proposal expiration rule (proposal expires after the voting window period and during the maintenance period). The default value is the number of blocks corresponding to 72 hours (86400), but subsequent adjustments must be made through an SR vote.

Abstract

Currently, Super Representatives (SRs) can locally configure the proposal voting window period (proposalExpireTime), which may lead to inconsistent judgments on proposal expiration times across different nodes. This proposal recommends changing it to an on-chain governance parameter (default: 86400), with future adjustments requiring an SR vote. This ensures network uniformity and supports flexible governance optimization.

Motivation

Fully Decentralized Governance​​: Key network parameters (such as the proposal voting window period) should be determined by on-chain voting rather than relying on manual node configurations.

Enhanced Consensus Security​​: Unify the judgment logic for proposal voting expiration times across all nodes.

Support Dynamic Adjustments​​: The community can flexibly adjust the proposal voting window period through voting (e.g., shortening it to 48 hours to accelerate governance processes).

Specification

1. Remove the proposalExpireTime parameter from local configuration files (e.g., config.conf).

2. Add an on-chain proposal parameter:

public enum ProposalType {
  ...
  PROPOSAL_VOTING_WINDOW(90);
}

NOTE： This parameter represents the number of blocks during the voting window period.

Rationale

Proposal Voting Lifecycle​​:

• The countdown for proposal voting expiration starts from its creation time.

• After exceeding the on-chain Proposal Voting Window and during the nearest maintenance period, the proposal automatically expires (even if voting is incomplete).

​​Block Validation​​: Nodes must reject transactions that rely on expired proposals (based on on-chain parameters).

​​Pre-Upgrade​​: proposalExpireTime will still be set via the default value or local configuration (if it exists).

Post-Upgrade​​: After all SRs complete the upgrade, the timing for initiating the PROPOSAL_VOTING_WINDOW proposal will be discussed. Once the proposal takes effect, the expiration logic will be executed by reading the proposal value.

Implementation

Protocol Changes​​

​​Core Modules​​:

• Modify ProposalService to add PROPOSAL_VOTING_WINDOW, making it governed by proposals and ignoring local configurations.

​​Interface Adjustments​​:

• Deprecate the proposalExpireTime parameter in the node configuration file config.conf after the proposal is activated.

Add the proposalVotingWindow parameter to the /wallet/getchainparameters interface.

Compatibility

This feature constitutes a hard fork.

[halibobo1205]

Great, local inconsistent configuration causing block execution failures will be fully eliminated.

[GuipaiQigong111]

Agreed, this will further enhance the robustness and stability of the proposal voting.

[lxcmyf]

@halibobo1205 @GuipaiQigong111
Yes, the proposalExpireTime in the historical configuration of config. conf is not only semantically ambiguous, but also difficult to maintain. This update will completely eliminate its impact.

[Sunny6889]

Excellent and crucial suggestions—I hope they can be implemented as soon as possible.

[xxo1shine]

@lxcmyf I personally think that anything related to consensus should not be effective through the configuration file. In addition to this configuration, are there any other configurations that also have this problem? Do they also need to be optimized?

[lxcmyf]

@xxo1shine
Thank you for raising this important point. Consensus-related parameters should indeed not be managed through local configuration files but rather through on-chain governance to achieve decentralization and consistency.

Regarding other configurations that may have similar issues, ongoing reviews are being conducted on core protocol parameters that could impact network consensus or governance behavior. If there are specific parameters or scenarios to suggest, further discussion or TIP proposals are welcome to jointly drive optimizations.

[bladehan1]

Well done, looking forward to this improvement

[Federico2014]

Excellent suggestions. However, the title of the tip seems incorrect. You may need to check it.

[Federico2014]

@lxcmyf check this title.

tip: 767
title: Enhance Verification of Transaction Limitation at Consensus Layer

[lxcmyf]

Excellent suggestions. However, the title of the tip seems incorrect. You may need to check it.

OK，thanks.