1

I have an issue on which I have been stuck for 4 days since the release of Sundaeswap and the congestion of the network. I have my own node on the mainnet. I have the same on the testnet and everything is working well on the testnet.

With the congestion of the network, I noticed that doing simple transfers from a wallet works well. (Maybe it's worth mentioning the wallet did not delegate to any pool) Meaning the transaction gets processed and is visible on the various Cardano explorer after 10min.

However when I'm trying to have a transaction that is doing some minting. It gets signed and submitted, I have a transaction id, but after 12 hours, my wallet is still not updated with the potential minted tokens.

I know that my transaction got submitted , otherwise, I would not have had a transaction id or cardano-cli would have returned me an error.

Also, the exact same process on the testnet is working fine. And the process was working well before the congestion of the network.

My guess is that the transaction is still stuck on the mempool. But why do some other simple transfer transactions get through and not the one with minting ? I thought there was no prioritization on Cardano transaction? Moreover, I saw some minting transactions still happening on the network, so what do the other node have that I'm missing to be able to mint?

Many thanks in advance for any documentation or tracks to explore.

Anselme

Improve this question

2 Answers 2

Reset to default
2

The fact that you have a transaction ID does not mean it was successfully submitted. The moment you create locally a transaction file, you already have a transaction ID for it, no matter if you submit it or not (even before you sign it). You can see the transaction ID with the command:

cardano-cli transaction txid --tx-body-file tx.raw

Are you using the --invalid-hereafter parameter when you create the transaction? Maybe you are giving it a too low validity period and it expires before being processed. I created a few transactions in the last days and submitted them through my Daedalus, and they were all processed in a few minutes.

Improve this answer
5
  • Many thanks for your answer @george-apex-stake-pool. Indeed you are right, I meant submitted because the command cardano-cli transaction submit --tx-file ... did not return me an error. I checked my here after, and it's talking the adding 10000 to the current slot (so transaction should be invalid after around 166 minutes which seems enough No ? ... However where you might be right, is about my policyscript where there is a time constraint of 5min... I will try to raise it to 15min (meaning the policy does not accept any minting after currentslot + 5*60 slots when the transaction is submitted.
    – Anselme
    Jan 23 at 12:45
  • So indeed, by extending my time constraint it worked. However I'm facing another issue. For the moment around 10 minutes happens between the transaction is submitted and the transaction get produced on a block. In the meantime, I cannot submit another transaction. Each time I have the following error: (ValueNotConserved)
    – Anselme
    Jan 23 at 14:27
  • 1
    You can submit other transactions if you consume other UTxOs. You cannot submit other transactions consuming the same UTxO.
    – George - APEX Stake Pool
    Jan 23 at 17:55
  • Indeed, I forgot about that. Just out of curiosity, is there any way documentation on how cardano is keeping track of current pending utxos. Example:I have two wallets sync using two different nodesi could theoritically submit two transactions with the same utxos? Ultimately only one would get validated, but it's theoritcally possible right?
    – Anselme
    Jan 23 at 19:31
  • Yes, this is correct. But the network should be congested for this to work, otherwise the transaction from the first's node mempool will be quickly in the second's node mempool and you will not be able to submit the second transaction.
    – George - APEX Stake Pool
    Jan 24 at 6:16
0

When the network is congested, your transaction can take some time before it gets processed within a block. Therefore, you need to make sure the --invalid-hereafter is sufficient.

In my case I put up to 15 minutes after the submission.

In the case where your transaction is minting, remember your policy script which could also have some time constraint. Therefore, make sure the slot is sufficient and also consider the potential delay before your transaction gets confirmed within a block

Improve this answer
1
  • The parameter --invalid-hereafter is optional, you can skip it and the transaction will be valid forever.
    – George - APEX Stake Pool
    Jan 24 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.