Smart way of sending multiple transactions?

So I’m currently doing a thesis for school and we want to do some monitor some tests on the cardano testnet network. One of the tests we’re interested in is to try and load the network with a bunch of transactions so as to max the amount of transactions for a block.

When I send multiple transactions using the TxHash they all get lumped as one transaction, so i take it I have to use different TxHashes for each transaction to register separate ones?

Is there a smart way of doing this or do I have to create some sort of script that creates a bunch of different transacations by querying the CLI to get different hashes?

No, they are not lumped together. The transaction hashes are the inputs to a transaction and the inputs can only be used once. If you submit a lot of transactions taking the same input, all but one of them will fail.

You will first have to create enough UTxOs at your address, in your wallet to be able to do transactions in parallel at all.

Then, you can query these UTxOs and create transactions to be submitted in parallel for all of them.

If you do it with cardano-cli or use some of the available APIs for that is up to you.

Hmm but why does this block say 6 transactions but I’m making like 400 1ADA transactions?

Unfortunately, that’s not a link to anything that makes sense. And the number in there is neither a Cardano block number nor a transaction ID on mainnet or testnet. Can you provide a proper link to what you mean?

It also depends a bit on the size of the transactions. Currently, the size limit is 16 kiB, so if they are really large smart contract transactions, only five will fit into an 80 kiB block.

Additionally, if nobody wants to do a transaction, then blocks will, of course, not contain many.

Hmm what about this link: Block | Cardano Explorer

This is the block id 94634e171e0d250db450549adee7b30fcbfa155488fd5f38bd3bd59031fad368

Ah, thanks! Interesting, Cardanoscan does not find the ID important enough to even show it:

Since, the blocks before and after that one also do not have that many transactions, I’d think that there is simply not enough traffic to have more transactions per block.


But isn’t that supposed to be more than one transaction?

Cardanoscan shows 337 outputs, for my transaction(s) but only one transaction, so how is that not being lumped together?

I mean they’re all using the same TxHash so is that always the same as a single transaction?

No, you created it as one transaction with one input and 337 outputs.

Most transactions have multiple outputs, typically one to the target and one back to the sender’s wallet as change, but, e. g., exchanges often do transfers to lots of their customers in one transaction and wallet apps may choose to reorganise the stuff in your wallet in multiple outputs instead of only one.

Okay, you could say that it is lumped together, but it is lumped together by you, while building the transaction. One call to cardano-cli transaction build (or the equivalent in whatever API you use) results in one transaction, irrespective of the number of outputs you choose to put in that transaction.

Later systems on the way – the node you are submitting to or the block producer putting the transaction on chain – cannot lump together or modify the transaction. It stays as it has been signed.

There are several hashes involved here. The TxHash given as ID in your example (e4eee3ea…e8b5647d) is not really used. It is generated from hashing the transaction after it is built, when you already decided that you want to have 337 outputs in it.

The hash(es) you have given as input(s) to the transaction, when building it, are the hashes of previous transactions to you. And they can only be spent once. As long as they are not spent they are called “unspent transaction outputs” (UTxOs).

Your example transaction results in 337 UTxOs – e4eee3ea…e8b5647d#0 to e4eee3ea…e8b5647d#336. When building later transactions, you can choose to spend some of these UTxOs by giving them as inputs – --tx-in when using cardano-cli, the equivalent when using some other tool for building them.

Since UTxOs can only be used once, when you submit several transactions with the same UTxOs as inputs, only one of them will succeed and the others will fail.

1 Like

So @HeptaSean explained it very well, but just to confirm in case it’s still confusing:

  • With cardano-cli transaction build you generate 1 transaction with UTXO inputs that you can spend and 1 or many outputs to your or someone else’s addresses. (In your case the ADA went to 337 different addresses as part of that single transaction).

  • After you submit the transaction it ends up in the Mempools of the block producers. It is not yet part of a block on the blockchain.

  • The Block Producer elected to mint the next block takes transactions out of the Mempool and mints a block. The number of transactions included in the block depends on their size and the max block size, as @HeptaSean described. Your transaction will be part of some of the upcoming blocks.

So to summarize, the block mentioned above includes a total of 6 transactions where 1 transaction is the one you submitted which includes ADA output to 337 different addresses.

1 Like

And to come back to the original post:

If you want to do a load test, you should build a lot of separate, independent transactions taking different UTxOs as inputs, and try to submit them all at the same time.

For example, you could use the UTxOs you just created to be these inputs. You will need two of those for each of these load test transactions, since an output has to have at least 1 (t)ADA after fees. So, the 1 (t)ADA outputs you created are not enough.

Next time, create a lot of 2 (t)ADA outputs in one or several transactions. Then, you can use each of these alone to create a lot of load test transactions.

1 Like

They actually all went to the same address.

But, since Cardano is not account-, but UTxO-based, they still produce different UTxOs that can then be used independently.


Wow thanks a lot man, really helpful and informative, kinda sucks that I have insufficient ADA in each UTXO but also reassuring that I’m on the right track!

since an output has to have at least 1 (t)ADA after fees

So are my 1 tADA UTXO’s locked now or is there a way to move them?

And furthermore, if you don’t mind me asking, what can be a reason as to why transactions can have different sizes in terms of memory?

A transaction can have different numbers of inputs (UTxOs that are spent in this transaction), each requiring a few bytes, different numbers of outputs (future UTxOs created by this transaction), which can also require more or less bytes depending on the target address and if native tokens other than ADA are contained in that output. It can have metadata and scripts (or script hashes) included in the transaction data.

The transaction fee is then calculated based on the length in bytes after encoding all these data in CBOR.

Since all native tokens in the inputs of a transaction have to go to one of the outputs, either sent to the recipient or as change back to the own wallet, it is quite costly to have large amounts of tokens on one UTxO that needs to be used (e.g., when selling one of the tokens or when no other UTxO with enough ADA is available). On the other hamd, since native tokens have to be accompanied by a minimum amount of ADA, having all tokens separated in single UTxOs locks large amounts of ADA. At least Eternl has a setting to automatically balance between these and try to always put a certain amount of native tokens (default 20) together in UTxOs.

1 Like

If you use two or more of these as inputs, there is no problem moving them together again.

1 Like

Semi-related followup question, is there a way to get the information that is represented in cardanoscan to show up directly in the CLI?

No, a cardano-node does not store the chain in an easily accessible indexed way. You can get the current UTxOs of an address (because such information is needed to build and verify transactions), but not the whole history.

There is cardano-db-sync, which parses the blockchain and stores the information in it in an SQL database, so that you can query it. Needs an additional huge pile of disk space, though.