Is there a default and max TTL for transactions?

[nimrod]

I haven’t been able to find info on the above question… so is there a default and a max TTL that we can set for our transactions?

And if there’s no default, is it still possible to cancel transactions while they are still sitting in the mempool waiting to be written to a block?

[HeptaSean]

@nimrod

I haven’t been able to find info on the above question… so is there a default and a max TTL that we can set for our transactions?

I think most wallet apps set something. At least, I have to confirm something about TTL on my Ledger, when confirming the transactions. The protocol itself does not have a default, as far as I know. If I do not set --invalid-hereafter in cardano-cli transaction build, the transaction will be valid forever (with some restrictions below).

@nimrod

And if there’s no default, is it still possible to cancel transactions while they are still sitting in the mempool waiting to be written to a block?

Depends on the service used. For example, in the Blockfrost API (the one used by Nami), I do not see any cancellation feature: https://docs.blockfrost.io/

But: If other transactions (through other channels) were already successful later on, the chances will be very high, that the transaction stuck in the mempool will fail, because its inputs were already used by these other successful transactions.

You could also provoke this by once sending everything to yourself. This will use all the UTxOs (unspent transaction outputs; everything you have in your wallet once came through a transaction and now sits at the output of that transaction, until it is sent further) and then the stuck transaction (that also had to have one or more of these UTxOs as inputs) cannot succeed anymore.

[nimrod]

@HeptaSean

The protocol itself does not have a default, as far as I know.

Yeah, this is really what I’d like to find out for sure. I’d like to know for certain if this is really the case.

@HeptaSean

You could also provoke this by once sending everything to yourself.

This will be hard to do successfully. Unlike in EVM-compatible chains where we can set higher transaction fees to prioritize trxs, here on Cardano, we can’t do that. Nodes process transactions in the order they are submitted.

[HeptaSean]

@nimrod

Yeah, this is really what I’d like to find out for sure. I’d like to know for certain if this is really the case.

You could go through the code of your favourite wallet. Couldn’t do a full code review, but:

input-output-hk/nami/blob/ba09ac01d2b60d960740a2002af79bf90336dad7/src/config/config.js#L109-L111

Emurgo/yoroi-frontend/blob/8f30fa317125314a1cdad904d83e553ec790a144/packages/yoroi-extension/app/api/ada/transactions/shelley/transactions.js#L42-L46

Both, Nami and Yoroi seem to set 7200 seconds, 2 hours as their default.

@nimrod

This will be hard to do successfully. Unlike in EVM-compatible chains where we can set higher transaction fees to prioritize trxs, here on Cardano, we can’t do that. Nodes process transactions in the order they are submitted.

Yes … and no. In the Nami/SundaeSwap situation, a lot of people switched to ccvault or other wallet apps, because of the total congestion of Nami/Blockfrost. When they successfully did a transaction there (which did not use the congested Blockfrost mempool, but totally different nodes to submit), that transaction got processed first, potentially taking away the UTxO(s) of the transaction stuck in Blockfrost.

Based on this – 2 hours TTL and successful transactions taking away UTxOs – most of the transactions stuck in these mempools the past weekend, should have failed eventually.

[nimrod]

@HeptaSean

You could go through the code of your favourite wallet.

Sorry, I wasn’t clear enough - what I mean is the blockchain protocol default, not the wallet app’s default. But thank you for these references.

@HeptaSean

When they successfully did a transaction there (which did not use the congested Blockfrost mempool, but totally different nodes to submit), that transaction got processed first, potentially taking away the UTxO(s) of the transaction stuck in Blockfrost.

Yep, I see… this makes sense. But not really a reliable way to “cancel” pending transactions.

[HeptaSean]

@nimrod

But not really a reliable way to “cancel” pending transactions.

Probably, because nobody designed it to be for cancelling. On normal days, there should not really be time to cancel, so why even designing a feature for that?

(If it is pending in the mempool, before even reaching a block producing node, it is not a matter of the protocol to cancel it. Could make sense to build cancelling into the API of such a service.)

[nimrod]

@HeptaSean

so why even designing a feature for that?

I’m not really interested in discussing design motivations in this particular case. Just wanted to know what’s possible in the current design. Because I’m currently working on an app that could use such info.

That’s just it.

[HeptaSean]

@nimrod

Just wanted to know what’s possible in the current design. Because I’m currently working on an app that could use such info.

Ah, okay. I researched until the command line tools.

While https://github.com/input-output-hk/cardano-node/blob/master/doc/reference/building-and-signing-tx.md makes it sound like you have to set --invalid-hereafter to something (then there would not have to be a default, because every transaction would have to choose), the examples in https://developers.cardano.org/docs/native-tokens/minting/ do not set one at all, while the examples in https://developers.cardano.org/docs/native-tokens/minting-nfts/ do (for NFTs it has to be set, because it needs to match the minting policy). Note that examples with a TTL years in the future seem to work.

To know, what exactly happens, when nothing is set (and if there perhaps is a maximum in addition to the set invalid-hereafter parameter), you might need to dust off your Haskell skills.