Ensuring uniqueness of transaction IDs

[walter-hernandez]

---

hip: XX
title: Ensuring uniqueness of transaction IDs
author: Jiahua Xu [email protected], Walter Hernandez [email protected], Juan Ignacio Ibañez [email protected], Paolo Tasca [email protected], Nikhil Vadgama [email protected]
type: Service
category: Service
needs-council-approval: Yes
status: Draft
created: 2025-02-28
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/XX

Abstract

This proposal introduces a nonce-based approach to enhance transaction ID representation in the Hedera network to resolve the observed duplication of transaction identifiers. Empirical analysis of network transaction data reveals systematic patterns of identifier duplication across heterogeneous transaction categories, primarily manifesting in cases where multiple operations share timestamps and account parameters. The proposed enhancement mandates the explicit inclusion of the transaction nonce parameter in the canonical transaction ID representation, resolving ambiguity while maintaining backward compatibility with existing infrastructure.

Motivation

According to Hedera documentation (https://docs.hedera.com/hedera/core-concepts/transactions-and-queries), a transaction ID is composed of the account ID of the fee payer and the transaction's valid start time. The current format appears as [email protected], where 0.0.9401 represents the fee payer's account ID and 1598924675.82525000 indicates the timestamp in seconds.nanoseconds.

While the protocol architecture includes a nonce parameter for distinguishing transactions with identical account and timestamp parameters, this nonce is not reflected in the canonical transaction ID representation. This implementation inconsistency has led to several documented instances where distinct transactions exhibit identical transaction IDs, creating significant operational challenges:

1. Divergent transaction indexing behavior across explorers (e.g., hashscan.io displays all transactions, while hederaexplorer.io displays only single transactions)
2. Compromised traceability in multi-transaction contexts
3. Potential indeterminism in application logic that relies on transaction ID uniqueness
4. Audit complexity due to ambiguous transaction references
5. User confusion when attempting to verify transaction execution

Rationale

Transaction IDs serve as critical identifiers within the Hedera network. However, in certain situations, some transactions share the same ID. For example:

Transaction ID	Transaction Hash	Consensus Timestamp	Name	Result	Valid Start Timestamp
0.0.5006237-1737073021-093220619	3zNCMSe5j58h0K6W7rBpHCaP2DVGJktTsLBtU25381ZPMAX4Z69ee6Vv6TMays1E	1737073022.044907289	CRYPTOCREATEACCOUNT	SUCCESS	1737073021.093220619
0.0.5006237-1737073021-093220619	70wVhz3yScUC/iNW9lnwQJhudTJ9DIYhWtCH9fbWbubk9lVps9Y49KyShe1TOKBA	1737073022.044907290	CRYPTOTRANSFER	SUCCESS	1737073021.093220619
0.0.8114735-1737158196-856167570	ZoR0VnsG28bmUewJQiVO3nuyokZ9Xki8PgCJnHeZDW0YZdd7sv93qS0bqXkQhjAD	1737158215.655805999	CRYPTOCREATEACCOUNT	SUCCESS	1737158196.856167570
0.0.8114735-1737158196-856167570	ZvMPudFKHZWaunOedJ1SVp8vWU17clOTsQ8LCHsN5Bgm+A5jscxA5iVpktdSfZPH	1737158215.655806000	CRYPTOTRANSFER	SUCCESS	1737158196.856167570
0.0.1386381-1737158132-780786060	iV9tGid6T3Fc33LHza8TbROZ/D4s/720GDsqApPPmE0d7KYPbK3W63TTcOXTdjXQ	1737158249.445848001	CRYPTOTRANSFER	SUCCESS	1737158132.780786060
0.0.1386381-1737158132-780786060	iaae2KNSSECf/N9DUP0ScScWexBHWPmhVr0WN5lpezLIElachJfClc7qoYvE92mJ	1737158138.385972000	SCHEDULECREATE	SUCCESS	1737158132.780786060
0.0.6282929-1737081360-658639098	twwhGvryFvWSNmOb9KIl7GYBYLBp0HYgak2XJP2PpntOx9AcDcIsELES4F/ob+Qg	1737081404.997836001	CRYPTOTRANSFER	SUCCESS	1737081360.658639098
0.0.6282929-1737081360-658639098	C8boD/BidS68aUvRAqvG3rms4LS5D4Kv2BJv1ImFpWBkE0+P8Myzlw7qFsVxl/nr	1737081373.835421389	SCHEDULECREATE	SUCCESS	1737081360.658639098
0.0.6405563-1737082574-101266374	E0ccPXXsEkFS6Ty3MPC7BZYuxBzbJgSZbtFdqoiaxuHUrRMVUmobUzjwSUw4pK4b	1737082583.405135000	SCHEDULECREATE	SUCCESS	1737082574.101266374
0.0.6405563-1737082574-101266374	Ai5Pe6ERW40QvdcuV53T3M+JCCzop+17xs1qHyTn0wqUXmkaNw3gHmG6xlhZEFSF	1737082601.585652255	TOKENBURN	SUCCESS	1737082574.101266374
0.0.606043-1737082598-383000000	Lpwig+V/x5ceg4l/bwIu0YTK4o2DzjVAMbWQYnuZdPsGbasan4A21TmX3ei9mmtx	1737082609.547226000	SCHEDULECREATE	SUCCESS	1737082598.383000000
0.0.606043-1737082598-383000000	OCWNoyTA/ir4RrIj3rNTp7IPaad+1AGVIU122g3H5ElrXDafILEX/3V7of/kl3FM	1737082638.577640464	CRYPTOTRANSFER	SUCCESS	1737082598.383000000
0.0.4168447-1737082868-222471200	WOSXKPKC/AOGWyoTqgsEePFc5f3SPlRzLGtO3Y4hv7iIXikCNTex1znMF4L6KUin	1737082881.717818362	CRYPTOCREATEACCOUNT	SUCCESS	1737082868.222471200
0.0.4168447-1737082868-222471200	L8taMCU7O9t2c+xLORVpfg+paBJUK3FCaE/tkerTJ4J/9Q4KToTS8sNfvDfi7V/v	1737082881.717818363	CRYPTOTRANSFER	SUCCESS	1737082868.222471200
0.0.606043-1737083031-610000000	wGQKPhP4BIQtBTbxrv+BBJPLcLC1fKrgeSlrmw2U7bSSj6+qZ9qMtJxdhKUWunKI	1737083042.431051013	SCHEDULECREATE	SUCCESS	1737083031.610000000
0.0.606043-1737083031-610000000	5w5QPljdWiWA5rgCgOrpqP0modBpt8+tEEr7wdCO8GG1d8wCfZMc4yGb+jFVz2l4	1737083079.739058437	CRYPTOTRANSFER	SUCCESS	1737083031.610000000
0.0.4306803-1737156557-702811648	elTDqWD5gbvDkeP0obSfHWNa89lwnplU1KcoyRYIqp2gc05Y6hcr3kxsTnRYgxN2	1737156568.487731999	CRYPTOCREATEACCOUNT	SUCCESS	1737156557.702811648
0.0.4306803-1737156557-702811648	wF8Kd+ZxH7hnW/D7+50SFMvEHOr5oNHz8UAZiCWiGVeGwXqxLSrNzckxSluk+DeS	1737156568.487732000	CRYPTOTRANSFER	SUCCESS	1737156557.702811648

A comparative analysis of major block explorers reveals inconsistent treatment of these duplicated identifiers:

1. Hashscan.io correctly indexes and displays all transactions, properly differentiating between transactions with identical IDs. Example: https://hashscan.io/mainnet/transactionsById/0.0.5006237-1737073021-093220619
2. Hederaexplorer.io displays only a single transaction per ID, creating misleading transaction visibility. Example: https://hederaexplorer.io/search-details/transaction/0.0.5006237-1737073021-093220619

This inconsistency creates significant user confusion, particularly for cross-reference verification between explorers, and indicates the need for a standardized, unambiguous transaction identification format.

User stories

• As a developer of financial reconciliation systems, I require guaranteed unique and consistent transaction IDs across all infrastructure components to ensure accurate transaction correlation and auditing.

• As a block explorer provider, I need a standardized, canonical transaction ID format that intrinsically captures all differentiating parameters to ensure consistent user experiences across the Hedera ecosystem.

• As an end user verifying transaction execution, I require a transaction ID format that provides unambiguous reference to a single transaction to eliminate confusion when using different exploratory tools.

• As a compliance officer conducting transaction analysis, I need deterministic transaction identification to ensure comprehensive audit trails without identifier collisions.

Specification

The proposed enhancement modifies the canonical transaction ID representation to explicitly incorporate the nonce parameter, which already exists within the system but is not reflected in the transaction identifier string.

The enhanced transaction ID format transitions from:
accountID@timestamp

To:
accountID@timestamp/nonce

Examples:

• Current: [email protected]
• Enhanced: [email protected]/0 (with nonce=0)
• Enhanced: [email protected]/1 (with nonce=1)

Implementation requirements include:

1. Standardization of transaction ID string representation across all Hedera interfaces
2. Update of client SDKs to generate and parse the enhanced format
3. Block explorer modification to consistently display the complete ID format
4. Documentation updates reflecting the canonical ID structure

Importantly, this approach leverages existing protocol parameters and requires no fundamental changes to the underlying transaction structure, focusing instead on representation standardization.

Backwards Compatibility

The proposed enhancement maintains strong backward compatibility through:

1. Utilization of the existing nonce parameter already employed in the protocol
2. Optional elision of explicit nonce representation for the default case (nonce=0)
3. No modification to transaction generation, submission, or processing logic
4. No changes to underlying data structures or cryptographic operations

Security Implications

The proposed enhancement offers several security benefits:

1. Elimination of transaction ID ambiguity, reducing the potential for reference confusion
2. Enhanced auditability through unambiguous transaction referencing
3. Improved cross-platform consistency in transaction representation
4. Reduced potential for user error in transaction verification

No new security vulnerabilities are introduced, as the approach:

1. Utilizes existing protocol parameters
2. Requires no additional cryptographic operations
3. Maintains all current transaction validation mechanisms
4. Preserves the temporal and account-based properties of transaction IDs

How to Teach This

Open Issues

References

1. Hedera Documentation on Transaction IDs: https://docs.hedera.com/hedera/core-concepts/transactions-and-queries
2. Hashscan.io explorer behavior: https://hashscan.io
3. Hedera Explorer behavior: https://hederaexplorer.io

Copyright/license

This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

[steven-sheehy]

Note that there's also the scheduled flag that is included in the TransactionID proto and is used for uniqueness as well. So you can have two transactions with the same account, valid start, and nonce with only the scheduled flag varying. The nonce came later and non-zero nonces were never used for scheduled transactions. Scheduled transactions should probably be changed to use nonce as well, though that doesn't help historical transactions.