Add HIP-1300: Increase max transaction size for governance accounts

Signed-off-by: mark-swirlds <mark@swirldslabs.com>

Author: Mark-Swirlds

HIP/hip-1300.md

@@ -0,0 +1,122 @@
+---
+hip: 1300 
+title: Increased Transaction Size for Governance Accounts
+author: Mark Blackman (@Mark-Swirlds), Akram AbouEmara (@akdev)
+working-group: Michael Tinker (@tinker-michaelj), Simi Hunjan <simi@hashgraph.com>
+requested-by: Alex Popowycz <a@hedera.com> 
+type: Standards
+category: Core
+needs-hiero-approval: Yes 
+needs-hedera-approval: Yes
+status:  Draft
+created: 2025-09-30 
+updated: 2025-09-30
+requires: 
+replaces: 
+superseded-by: 
+release: 
+---
+
+## Abstract
+
+This HIP proposes adding a new system privilege to Hedera and Hiero governance accounts accounts.treasury and accounts.systemAdmin , enabling an increased transaction size limit from the current 6KB to 130KB. This change addresses challenges faced by the growing Hedera council, whose governance transactions increasingly exceed the standard transaction size limit due to the increasing number of required signatures. The proposed 128KB limit is already supported by Hedera's existing jumbo Ethereum transaction feature, minimizing implementation complexity and potential system disruptions.
+
+## Motivation
+
+The Hedera council is responsible for the governance of the Hedera network, including signing off on major network changes such as upgrades, topology changes, and updates to fees or throttles. These governance actions require signatures from council members, which are performed from the privileged accounts `accounts.treasury` and `accounts.systemAdmin` (accounts 0.0.2 and 0.0.50).
+
+As the Hedera council continues to grow its membership, the number of keys associated with these accounts also increases. This growth has created an operational challenge where signed transactions from these accounts are exceeding the standard transactional size limit of 6KB, potentially impeding critical governance functions.
+
+## Rationale
+
+This proposal represents a targeted solution to a specific operational challenge. The 130KB size limit has been chosen because:
+
+1. It aligns with Hedera's existing jumbo Ethereum transaction feature, which has already been tested and implemented in the network
+2. It provides ample room for future council growth
+3. It minimizes the scope of changes required, focusing only on the transaction size limit rather than broader architectural changes
+
+The proposed approach leverages existing network capabilities with minimal changes, providing a straightforward solution to enable continued network governance as the council grows.
+
+## User stories
+
+As a Hedera Governing Council member, I need to sign governance transactions collaboratively with multiple council members without exceeding transaction size limits or requiring signature removal, so that I can approve network changes efficiently, securely, and transparently.
+
+## Specification
+
+This HIP proposes granting a new system-level privilege to the `accounts.treasury` and `accounts.systemAdmin` accounts. When either of these accounts is used as the payer for a transaction, the transaction size limit will increase to 128 KB, rather than the standard limit of 6 KB.
+
+1. **Affected Settings and Accounts**:
+    - Hiero  setting name - `accounts.treasury`
+        - *Hedera mainnet - account 0.0.2*
+    - Hiero setting name -  `accounts.systemAdmin`
+        - *Hedera mainnet  - account 0.0.50*
+2. **Change Details**:
+    - Current transaction size limit: 6KB
+    - Proposed transaction size limit: 130KB
+3. **Implementation Approach**:
+    - Add a conditional check in the transaction preprocessing logic that identifies if the payer account of the transaction is one of the privileged accounts (0.0.2 or 0.0.50)
+    - For these transactions, apply the extended size limit of 130KB instead of the standard 6KB limit
+    - Maintain all other transaction validation rules unchanged
+4. **Technical Requirements**:
+    - Update the transaction validation logic to apply the 130KB size limit for the specified accounts
+    - Ensure the transaction handling pipeline can properly process these larger transactions
+    - Update relevant documentation to reflect this special privilege
+
+### Impact on Mirror Node
+
+No impact to mirror node
+
+### Impact on SDK
+
+No impact to mirror node
+ 
+## Backwards Compatibility
+
+While this change increases the maximum transaction size for specific accounts, the impact on network resources is expected to be minimal because:
+
+1. These transactions are infrequent, occurring only during governance actions
+2. The accounts with this privilege are strictly limited to `accounts.treasury` and `accounts.systemAdmin` 
+3. The network already supports the jumbo Ethereum transaction feature with a 130KB size limit
+4. These accounts already have special permissions that exempt them from system throttles
+
+## Security Implications
+
+The security implications of this change are minimal:
+
+1. **Limited Scope**: Only two specific accounts (0.0.2 and 0.0.50) will receive this privilege, both of which are already highly privileged governance accounts with strict access controls
+2. **Existing Capability**: The network already supports 130KB transactions through the jumbo Ethereum transaction feature, so no new attack vectors are being introduced
+3. **Governance Protection**: This change actually enhances security by ensuring governance operations can proceed smoothly as the council grows, maintaining the intended security model of requiring multiple signatures
+
+## How to Teach This
+
+This change primarily affects Hedera council members and network operators:
+
+1. **For Council Members**:
+- No action is required; transactions from accounts 0.0.2 and 0.0.50 will automatically be allowed with sizes up to 128KB
+- Members should be aware that governance transactions can now accommodate more signatures without hitting size limits
+1. **For Network Operators**:
+    - Be aware that transactions from accounts 0.0.2 and 0.0.50 may be larger than the standard limit
+    - Ensure monitoring systems do not flag these larger transactions as anomalies
+2. **For Developers**:
+    - This change does not affect regular development practices
+
+## Reference Implementation
+The reference implementation must be complete before any HIP is given the status
+of “Final.” The final implementation must include test code and documentation.
+
+## Rejected Ideas
+Below is a list of ideas that were considered during the design process.
+
+1. Allow unlimited transaction size (for signatures only) for these accounts.
+
+## Open Issues
+
+None at this time.
+
+## References
+
+HIP 1086 - [Jumbo EthereumTransaction] (https://github.com/hiero-ledger/hiero-improvement-proposals/blob/main/HIP/hip-1086.md)
+
+## Copyright/license
+This document is licensed under the Apache License, Version 2.0 —
+see [LICENSE](../LICENSE) or <https://www.apache.org/licenses/LICENSE-2.0>.