On the TON blockchain there is no standard “tx hash” definition like on most other blockchains. Normally, it is a unique hash sequence composed of the transaction’s serialized bytes used to identify the transaction on the blockchain and confirm it was finalized. However, in the TON blockchain, a transaction consists of a series of messages passed between smart contracts. Each message-exchange phase has its own tx hash, which is a sequence of the smart contract’s combined input & output messages.

This tx hash cannot be predetermined since it is produced only after the transaction is executed on the blockchain. Therefore, it cannot be used in order to track the transaction on the blockchain because it isn't associated with the initial serialized bytes produced on the blockchain.

A TON transaction consists of two message types:

1. External messages, which originate outside of the blockchain (as in a wallet transaction) and are normally accepted by wallet smart contracts. 
2. Internal messages, which are passed to and between smart contracts. 

A typical TON transaction serialized to the blockchain consists of an external message containing one or more internal messages with an instruction to a wallet smart contract to spend some funds. As per TON's specifications, only the internal message is cryptographically signed, but the external message is not. When Fireblocks serializes a TON transaction, it uses the hash of its combined external and internal message to track the transaction on the blockchain, since these are the serialized bytes that are guaranteed to appear. This hash is what TON refers to internally as the "message hash". It is also supported by blockchain explorers such as Tonviewer.

We detected that in some of outgoing transactions whose validators repackaged their external message, the original hash was altered. We alerted the TON foundation of this, and began investigating the issue. Since the external message is not cryptographically signed, it is not possible to prevent a validator or a third-party from committing the transaction with the repackaged external message. Since the internal message is cryptographically signed, there is no security concern, but it does hinder our ability to track transactions on the blockchain explorer. 

Solution

As a temporary solution, we implemented a workaround where we repackage transactions that we detect to be outgoing from Fireblocks, while scanning the blockchain for the external message that we expect, and thus producing the expected message hash. However, these transactions do not show up in the blockchain explorer with the hash produced by Fireblocks.