Just want to foresee if we'll run into any issues sending/consuming thousands, or tens of thousands of UTXO's at a script address.
4 Answers
Is there any limit to the number of UTXO's sitting at a script address?
There shouldn't be any practical limit.
UTxOs aren't stored in some memory at an address. The address determines who can spend a UTxO, not where it resides. And that address is included on the UTxO, not vice versa.
In other words, when you send UTxOs to an address there is no check on which/how many UTxOs are owned by that address. You are just adding a new UTxO to the blockchain that the intended recipient can identify as their own and spend.
Check out my answer here for more details on how UTxOs are associated with addresses.
-
1Thank you! This is exactly the answer I was looking for :) Commented Nov 1, 2021 at 21:37
-
@Mitchell Turner Since the address is just a hashed string of the script attached to a UTXO, it doesn’t specify where the UTXO resides. So, what does it mean when you say “send UTXOs to an address” in the third paragraph? Does it mean that we create a new UTXO using the same hashed script AS the address attached to that new UTXO?– JonasCommented Mar 2, 2022 at 3:53
-
I mean when you create any transaction that has an output owned by the script address. I'm using the term "send" loosely. Similar to when you "send" or transfer funds to another wallet. In reality you aren't "sending" it anywhere, you're just creating a new UTxO who's owner is the recipient of the value in the UTxO. Sorry if that was confusing. I was intentionally mixing vernacular to draw parallels. Commented Mar 3, 2022 at 4:09
This sounds like a two part question:
- Is there any limit to the number of UTXOs stored at a script address
- Is there any limit to consuming UTXOs stored at a script address
For the first one, yes and no. While you can theoretically store as many UTXOs as you like at a script address, there are some resource constraints you're likely to run into:
- The size of a single transaction is currently limited to 16k and the max size of a single block is 64k. And while these numbers are adjustable, this puts an upper limit on the rate of ingestion.
- The same issue will apply when you wish to spend the UTXO as well. 16k is the limit for the entire transaction, inputs, outputs, witness, all of it.
For the second question, yes, there are a number of limits on consuming UTXOs:
- Within the 16k transaction size limit, the smart contract (currently) needs to fit into that space, significantly reducing the amount of space available for UTXO
- Odds are, you'll probably want to do some verifications as well on the UTXOs so cpu and memory execution limits may also play a factor
- Like the 64k block size limit, there are also block limits for cpu and memory
Official documentation is silent about it.
Since many UTxOs can exist within one wallet address, the same way they can exist within a script address. You can potentially have even 10,000 Tx inputs per script address, but in reality, I'm sure, their number is below 1000, because it'll take a fair amount of network power to scan all inputs and outputs of each such an address. The only way to find out the exact number of tx-ins is to experiment in testnet.
However, the max number of UTxOs processed per transaction is known.
The maximum number of UTxOs per single transaction is about 70. Going higher will likely result in the network rejecting the transaction and defrag-ops.py will warn about this if --max is set higher than 70.
In addition to the above, I think everyone will be interested in reading this post.
-
1This is per transaction, not per script address, right? Commented Oct 31, 2021 at 21:46
-
I've updated my answer.– user4023Commented Nov 1, 2021 at 8:37
-
1Thanks for adding more details! Gave an upvote, but I still don't think this definitively answers the original question of max # of UTXO's allowed to sit at a script address. Commented Nov 1, 2021 at 17:37
I am failing to spend even 10 utxos from the script address because of CPU and memory limits, using AlwaysSucceeds validator. More info: Transaction memory and cpu usage limits