<p>MAST isn't really relevant here. As the Ark vtxo trees are just trees of sequential transactions. In theory they can be arbitrarily large.</p>
<p>Some things are to take into account though:</p>
<ul>
<li><p>More round participants means more interactivity. Since all participants in the round have to provide signatures for the round to be successful, more participants means higher likelihood a round will fail and will have to be restarted, so the longer a round will take, time-wise. Note that ASPs can limit the number of participants in a round if needed and even run multiple rounds in parallel.</p>
</li>
<li><p>More vtxo tree leaves means a higher cost for unilateral exit. The number of transactions a user has to broadcast (and pay fees for) for a unilateral exit is <code>log2(n)</code> with <code>n</code> being the number of leaves in the vtxo tree. While this scales logarithmically, which is pretty great, it can still become a significant burden for users to participate.</p>
</li>
<li><p>When broadcasting multiple transactions for a unilateral exit, probably using a fee strategy like <a href="https://bitcoinops.org/en/topics/cpfp/" rel="nofollow noreferrer">CPFP</a> (child pays for parent), mempool policy puts an effective limit on the size of the exit transaction package. Currently, Bitcoin Core has a <a href="https://bitcoin.stackexchange.com/questions/118160/whats-the-governing-motivation-for-the-descendent-size-limit">descendent limit</a> of 25 transactions. Current work on <a href="https://bitcoinops.org/en/topics/cluster-mempool/" rel="nofollow noreferrer">cluster mempool</a> will probably change this limitation and replace it with a cluster size limit (IIRC of 100). The way either of these limits affect Ark exit transactions is subtle and depends on how many people are exiting from the same Ark tx at the same time.</p>
</li>
</ul>
<p>Eventually, I think the latter consideration will be the realistic limiting factor on realistic Ark vtxo tree size.</p>
<p>For example, using pre-signed transactions (clArk, i.e. covenant-less Ark) or using <a href="https://bitcoinops.org/en/topics/op_checktemplateverify/" rel="nofollow noreferrer">OP_CTV</a>, this effectively limits the number of nodes in the entire tree*. With a limit of 25, that would mean a tree with up to 24 leaves and with a cluster limit of 100, that would mean 99 leaves.</p>
<p>However, with more powerful introspection opcodes**, the intermediate leaves could be fee-bumped so that this limit no longer holds.</p>
<hr />
<p>*: In fact if only one leaf of the tree can confirm, it can make space for other branches. So let's say all nodes except the leaves is the limit. Meaning that for <code>n</code> leaves, there has to be space for <code>n + 1</code> txs in the mempool.</p>
<p>**: like OP_TXHASH, OP_CHECKTXHASHVERIFY, OP_TX, direct introspection opcodes (or CAT+CSFS)</p>

CC BY-SA 4.0
2023-10-02T15:33:56.953Z
Considering that you have the limit of 25 descendants in the mempool and that you have to broadcast log2(n) +1 txs when you unilaterally exit, shouldn't the max number of leaves be 2^24?
bordalix
CC BY-SA 4.0
2023-10-06T17:30:41.673Z
You'd think so. But nothing prevents others from broadcasting their leaves as well, and then some of the txs in your branch could be dropped. So to make sure your exit branch can't get dropped from the mempool, you need the entire tree to fit. This is with constructions where you can only add fees on the leaves. Using something like TXHASH, you can add fees to intermediate nodes and then it doesn't matter anymore.
Steven Roose
CC BY-SA 4.0
2023-09-28T15:25:21.570Z
2023-09-29T14:59:33.843Z
2023-09-29T14:59:33.843Z
Steven Roose
<p>It's the only boundary the taproot/MAST limitation of 128 levels of the tree, ie. 2^128?</p>

<taproot><mast><ark>
How many recipients can fit in a single Ark shared output?
Marco Argentieri
# How many recipients can fit in a single Ark shared output?

(Asked by: username_0 on 2023-09-28)

It's the only boundary the taproot/MAST limitation of 128 levels of the tree, ie. 2^128?

**Tags:** taproot, mast, ark


---

## 1 answers

### Answer by username_1 on 2023-09-28. Score: 3

MAST isn't really relevant here. As the Ark vtxo trees are just trees of sequential transactions. In theory they can be arbitrarily large.

Some things are to take into account though:

* More round participants means more interactivity. Since all participants in the round have to provide signatures for the round to be successful, more participants means higher likelihood a round will fail and will have to be restarted, so the longer a round will take, time-wise. Note that ASPs can limit the number of participants in a round if needed and even run multiple rounds in parallel.
* More vtxo tree leaves means a higher cost for unilateral exit. The number of transactions a user has to broadcast (and pay fees for) for a unilateral exit is `log2(n)` with `n` being the number of leaves in the vtxo tree. While this scales logarithmically, which is pretty great, it can still become a significant burden for users to participate.
* When broadcasting multiple transactions for a unilateral exit, probably using a fee strategy like [CPFP](https://bitcoinops.org/en/topics/cpfp/) (child pays for parent), mempool policy puts an effective limit on the size of the exit transaction package. Currently, Bitcoin Core has a [descendent limit](https://bitcoin.stackexchange.com/questions/118160/whats-the-governing-motivation-for-the-descendent-size-limit) of 25 transactions. Current work on [cluster mempool](https://bitcoinops.org/en/topics/cluster-mempool/) will probably change this limitation and replace it with a cluster size limit (IIRC of 100). The way either of these limits affect Ark exit transactions is subtle and depends on how many people are exiting from the same Ark tx at the same time.

Eventually, I think the latter consideration will be the realistic limiting factor on realistic Ark vtxo tree size.

For example, using pre-signed transactions (clArk, i.e. covenant-less Ark) or using [OP\_CTV](https://bitcoinops.org/en/topics/op_checktemplateverify/), this effectively limits the number of nodes in the entire tree\*. With a limit of 25, that would mean a tree with up to 24 leaves and with a cluster limit of 100, that would mean 99 leaves.

However, with more powerful introspection opcodes\*\*, the intermediate leaves could be fee-bumped so that this limit no longer holds.

---

\*: In fact if only one leaf of the tree can confirm, it can make space for other branches. So let's say all nodes except the leaves is the limit. Meaning that for `n` leaves, there has to be space for `n + 1` txs in the mempool.

\*\*: like OP\_TXHASH, OP\_CHECKTXHASHVERIFY, OP\_TX, direct introspection opcodes (or CAT+CSFS)

> **Comments:**
> **username_2**: Considering that you have the limit of 25 descendants in the mempool and that you have to broadcast log2(n) +1 txs when you unilaterally exit, shouldn't the max number of leaves be 2^24?  
> **username_1**: You'd think so. But nothing prevents others from broadcasting their leaves as well, and then some of the txs in your branch could be dropped. So to make sure your exit branch can't get dropped from the mempool, you need the entire tree to fit. This is with constructions where you can only add fees on the leaves. Using something like TXHASH, you can add fees to intermediate nodes and then it doesn't matter anymore.  

---

