Duplicated transactions in Tenderdash chain (MAINNET / TESTNET)

[pshenmic]

Expected Behavior

Txid should be unique across the chain and cannot have the same transaction in two blocks

Current Behavior

Platform Explorer cannot properly sync due duplicated transactions in two separate blocks (206243 and 216145)

TXID
cf285c01204a6811a06b4b60f599870fffd77f2ceafd771c2608ed56a4454ca0

BgDtehKK/mXlSnfv8c9Sje0SPg90hMQhHNh8eWlmtj7wmwMDAQAGBAABAAAUNTZCt+SNdDNkjeiTu/BaUUvzIw8AAAAAQSCwlHFc1Nl/Zy+jUgWtCqLTIb/Cr7rfe+MBXTmm2yJGBHOmJJ9yQy30vKl9Kclj5ondkOPP1mbbausQuN39goZl

Context

Platform Explorer uses unique index on transactions SQL table and removing that index will require significant code refactor and will make all the queries way slower

[pshenmic]

There is another conflicting duplicated tx in the same 216245 block

9BE24F6636E70D288C82A37C6B6FF9622E8F3F7C2B6DCCB44D005305FEBEADAD tx is also duplicated in the same block

[pshenmic]

New duplicated transaction appeared on chain testnet
TxHash:
90ACB14D5E1D8807C96979E2F331F9EFBFCEF33133FD71C0841211D65BAFDB6E

https://testnet.platform-explorer.com/transaction/90ACB14D5E1D8807C96979E2F331F9EFBFCEF33133FD71C0841211D65BAFDB6E

Reappeared under the same TX at block 261921

[lklimek]

Problematic tx 90acb14d5e1d8807c96979e2f331f9efbfcef33133fd71c0841211d65bafdb6e passes check_tx, drive log:

{"timestamp":"2026-02-10T09:45:14.485504Z","level":"TRACE","fields":{
   "message":"DocumentsBatch([Replace]) state transition (90acb14d5e1d8807c96979e2f331f9efbfcef33133fd71c0841211d65bafdb6e) added to mempool",
   "check_tx_result":"CheckTxResult { 
    level: FirstTimeCheck, 
    fee_result: Some(FeeResult { storage_fee: 34722000, processing_fee: 138798540, fee_refunds: FeeRefunds({}), removed_bytes_from_system: 0 }), 
   unique_identifiers: [\"+/XMC9cneSJAmKT/9HYNPZmzOrZ+KGwq3YIL6ih+QZ8=-2FNb0tUyLwOkkXvUmvnoUZ6KZEJhxSxTavTSYOlRPLc=-3\"], 
    priority: 0, 
   state_transition_name: Some(\"DocumentsBatch([Replace])\"), 
    state_transition_hash: Some([144, 172, 177, 77, 94, 29, 136, 7, 201, 105, 121, 226, 243, 49, 249, 239, 191, 206, 243, 49, 51, 253, 113, 192, 132, 18, 17, 214, 91, 175, 219, 110])
}",
"error":"None","
st_hash":"90acb14d5e1d8807c96979e2f331f9efbfcef33133fd71c0841211d65bafdb6e"},
"target":"drive_abci::abci::handler::check_tx","threadName":"tokio-runtime-worker","threadId":"ThreadId(5869)"}

[pshenmic]

Well, that's all, This ISSUE finally came to the MAINNET network.

6 months has passed without any response from the dev team since I raised that issue. The issue is clear, neither Drive or Tenderdash chains does even have any checks on duplicated transactions, and Tenderdash may accept invalid transactions, however it will come with failed status. Although it seems logically correct it is extremely high indicator that this is a problem in the code, every state transition should be unique, it looks like there is a bug in nonce system, that allows Tenderdash to accept duplicated transactions in the chain, it should have been dropped at the broadcastStateTransition DAPI query!!!

There was plenty of time to investigate and fix this issue, and prevent it from entering the mainnet, however this issue didn't even get any reply (UPD, there is actually was a reply, thanks @lklimek) , now this has to go into documentation, and the possibility of duplicated transactions in the Tenderdash network must be mentioned.

35C08D574302D32D7160E603D8159042C8606BE12FD97D952CF5FD40DB57313C

https://platform-explorer.com/transaction/35C08D574302D32D7160E603D8159042C8606BE12FD97D952CF5FD40DB57313C

[pshenmic]

This issue has been PREMATURELY found by Platform Explorer backend but instead of working on the fix I WAS TOLD TO SIMPLY SKIP SUCH TRANSACTIONS, and therefore it made impossible to quickly identify the problem and sugges a fix!!!

I was super frustrated with this and has been resisting skipping them for several weeks in Nov 25 until it became clear that nobody going to work on that. NOW MAINNET CHAIN is spoiled with non-unique transactions.
It should have been investigated and fixed already, but now its over.

[QuantumExplorer]

I'm pretty sure the issue was fixed in 3.0, which means this is a new issue @pshenmic.

[pshenmic]

FALSE! The last issue that happened today on mainnet IS THE SAME with what I have already reported on the Feb 5, which involves a bug with Document Replaces. That two TXs are the document replace transitions.

On that day, v3.0 wasn't even officially released yet, the release date for v3.0 is Feb 6, and it needs about two weeks until all masternodes update the software. You can check it yourself. I personally messaged you and Lukasz in Slack on that day.

There was enough time to investigate and fix it!!

[shumkov]

@pshenmic here is two problems:

1. Drive has an issue with bumping nonces in case of an invalid state transition. This problem allows you to replay invalid state transitions. It's not good, but not critical - it's invalid and not executed. Here is the fix fix(drive-abci): free advanced structure validation for invalid batch transitions #3608
2. Cross-block tx-hash uniqueness is not a Tendermint/Tenderdash invariant. Tendermint's mempool has a short-lived tx-cache that dedupes recent submissions, but nothing in consensus enforces "tx hash X can only appear in one block ever." Hash uniqueness was always an emergent property: when nonces and signatures are functioning correctly, no two valid txs hash the same, and the same exact bytes can't pass CheckTx twice (because the second attempt's nonce would be stale).
   The platform-explorer schema (UNIQUE(hash) on state_transitions) baked in an assumption that's stronger than what the chain actually guarantees.