tip: 767
title: Transitioning proposal expire time configuration to Chain Governance
author: [email protected]
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 expire time 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 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: 259200000), 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 proposalExpireTime 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 proposalExpireTime period through approving (e.g., shortening it to 48 hours to accelerate governance processes).

Specification

• Add an on-chain proposal parameter:

public enum ProposalType {
  ...
  PROPOSAL_EXPIRE_TIME(92);
}

Rationale

Proposal Voting Lifecycle​​:

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

• After exceeding the on-chain proposalExpireTime and during the nearest maintenance period, the proposal automatically expires (even if approving 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_EXPIRE_TIME 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_EXPIRE_TIME, 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 proposalExpireTime parameter to the /wallet/getchainparameters interface.

Compatibility

This feature constitutes a hard fork.