Helix uses the messageId of the underlying message as the unique identifier of the transaction, so when a reorg occurs on the source chain, it is possible that the same transaction will generate a different messageId to be sent to the destination chain.
For example, messageId is generated by hash(nonce, payload), the nonce is stored in the contract and is incremented.
UserA sends a transaction with nonce = 1 to a forked chain.
UserB sends a transaction that takes up nonce = 1 on the canonical chain
and then UserA's transaction is immediately packaged on the canonical chain and takes up nonce = 2.
At this point, UserA's transaction generates different messageId on the forked chain and the canonical chain, which will be considered as different messages on the target chain, generating a double spend.
Helix uses the messageId of the underlying message as the unique identifier of the transaction, so when a reorg occurs on the source chain, it is possible that the same transaction will generate a different messageId to be sent to the destination chain.
For example, messageId is generated by
hash(nonce, payload)
, the nonce is stored in the contract and is incremented.At this point, UserA's transaction generates different messageId on the forked chain and the canonical chain, which will be considered as different messages on the target chain, generating a double spend.