[Dev Tools] known transaction error returned, but transaction not visible on chain after 1h

[pkjha527]

Team or Project

GAMP

ZK chain

SOPHON

Environment

Mainnet

Select the Dev Tool you are using

IDE

Provide the version of the tool (if applicable)

zksync2==2.0.0 ( python sdk )

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

Hi team 👋

We’re seeing an issue using zksync2 SDK when submitting transactions on SOPHON (a ZkSync-based L2 chain). The node returns a known transaction error, but after over 1 hour, the transaction has not appeared on-chain and is not queryable.

---

⚠️ Error Received

{
  "code": 3,
  "message": "known transaction. transaction with hash 0x76f9...e76a is already in the system",
  "data": "0x"
}

---

🧪 Context

• We’re using the zksync2 Python SDK:

  from zksync2.module.module_builder import ZkSyncBuilder

• Raw transaction is sent using:

  zksync_web3.zksync.send_raw_transaction(raw_transaction)

• Nonce is managed via Redis, synced from eth_getTransactionCount, with one transaction per nonce.

---

✅ What We’ve Checked

• The transaction has not been mined after >1 hour.
• We cannot query it via:

  web3.eth.get_transaction(tx_hash)
  web3.eth.get_transaction_receipt(tx_hash)

• Contract storage remains unchanged.
• We are not resending duplicate transactions manually — this was a one-time send.

---

🧾 Questions

1. What does the known transaction error actually imply in ZkSync context?
   Is it purely mempool presence? Could it be from a stale cache or prior attempt?

2. If the transaction does not appear via get_transaction, should we assume it was dropped?
   How do we handle this scenario robustly?

3. Does ZkSync SDK (or the node) guarantee that "known transaction" means the tx is accepted into the mempool?

4. Is there a recommended way to force replace or verify mempool acceptance of such transactions?

---

📌 Sample Transaction Hash

0x76f982d997ee3c9c514e847bfb183518878ccbc9e0d4138d57339a347caae76a

Repo Link (Optional)

No response

Additional Details

No response

[antonbaliasnikov]

Hi @pkjha527 ,
I'm checking the issue now, and get back to you as soon as I have more info.

[antonbaliasnikov]

@pkjha527 ,

After checking, the transaction is indeed in the mempool, but the max fee per gas (2033003457740) is too low compared to the current L2 fair gas price (2083884053924) for the latest batch. This means your transaction is pending because it doesn't meet the required gas price for inclusion in the next batch.

Your transaction will likely get executed if gas prices drop, but there’s no guarantee of when.

🔧 Recommended Actions

You have a few options now:

• Wait and Monitor
  • If gas prices decrease, your transaction may eventually be picked up and processed.
• Resubmit with a higher gas fee

If you want to speed things up, you can resend the transaction with a higher gas.

====================================================================================

🧾 Questions

What does the known transaction error actually imply in ZkSync context?
Is it purely mempool presence? Could it be from a stale cache or prior attempt?

Yes, it is about mempool presence, there is no cache or something else.

If the transaction does not appear via get_transaction, should we assume it was dropped?
How do we handle this scenario robustly?

Can you try to use zks_get_transaction_details method to check the details of the transaction? It should give you more info about the transaction status.

Does ZkSync SDK (or the node) guarantee that "known transaction" means the tx is accepted into the mempool?

Yes, this is guaranteed.
But the transaction being in the mempool does not guarantee that it would ever be executed.

Is there a recommended way to force replace or verify mempool acceptance of such transactions?

We suggest re-sending the transaction with the higher gas fee.
Please, make sure you are using the same nonce and the transaction will be replaced.

====================================================================================

Please, let me know if you have any further questions.

[antonbaliasnikov]

@pkjha527 , can you also provide the full code on how did you submit the transaction through Python SDK? Did you specify some logic for the gas or Python SDK was handling it for you?

[pkjha527]

@antonbaliasnikov please find the below code for transaction submission. we are estimating gas_limit using the estimate_gas method from zksync libraries

zksync initialisation code

      zksync_web3 = ZkSyncBuilder.build(config_data['provider_url'])
      account = Account.from_key(config_data['private_key'])
      signer = PrivateKeyEthSigner(account, config_data['chain_id'])
      contract = zksync_web3.eth.contract(
        address=zksync_web3.to_checksum_address(config_data['contract_address']),
        abi=config_data['contract_abi']
      )

    # Estimate gas
    gas_estimate = zksync_web3.zksync.eth_estimate_gas(tx.tx)
    tx_712 = tx.tx712(gas_estimate)

    # Sign and send transaction
    signed_message = signer.sign_typed_data(tx_712.to_eip712_struct())
    raw_transaction = tx_712.encode(signed_message)

    # Submit transaction
    tx_hash = zksync_web3.zksync.send_raw_transaction(raw_transaction)

[antonbaliasnikov]

@pkjha527 , thanks for sharing.
We hope you're unblocked now with this transaction, can you, please, confirm?

We will be separately checking two issues you highlighted though:

1. Transaction in the mempool should be visible through web3.eth.get_transaction(tx_hash), if it's not the case, it is problematic to monitor its status.
2. When SDK is estimating the gas, it should be already the right estimation without any additional tweaks.

We'll keep you updated.

[itegulov]

After running an investigation I believe we found a potential bug with eth_getTransactionByHash where it can behave inconsistently. A fix is being discussed and we will roll it out as soon as we can. I assume this resolves your report, thanks for taking the time to fill it in!