Polkadot Tx IDs that don't make it onto the chain

Hi Polkadot community,

I’ve been in crypto a few years, though not technically involved deeply.
I have DOT in my wallets and trade with these as well.

Transfers of DOT on the native Polkadot chain seem to work well, never had any issues with the exchanges I use.

However, there’s a company that I use to bridge DOT sometimes between different chains. This company frequently assigns Polkadot Tx IDs and marks a withdrawal as complete. The Tx Id does not actually exist/ make it onto the Polkadot chain when I check in DOT explorer.
Is this a common issue with DOT? How do some exchanges avoid this (e.g. Binance) while this bridging company claims it’s an issue with the DOT chain outside of their control?

They then go on to cancel the non-existing Tx after 1-3 days and I can withdraw my funds a 2nd time - but it’s driving me crazy.
Is this indeed an issue with the chain? Or rather something that the bridging company could avoid if they coded correctly?

Many thanks for potential help to try to explain what is/ might be happening in this case. Curious to understand from a tech perspective.
Best, Phil

PS: Let me know if you need more info or I if I would need to be more specific/ provide any additional detail for you to reconcile this topic.

@Phil this looks like a common mistake from third parties who do not know how to interface with Polkadot.

This is called out explicitly here: Polkadot Protocol Information · Polkadot Wiki

Transaction Hash is not a unique identifier

The assumption that a transaction’s hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully.

This is the correct way:

The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic’s index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to reference a previous transaction from the Multisig pallet.

So your bridging system should be providing you with a block number/hash and extrinsic id. I would generally suggest you do not use bridges which cannot do this right.

1 Like