> ## Documentation Index
> Fetch the complete documentation index at: https://docs.canton.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Network Scalability

> Scaling characteristics and tuning guidance for Canton Network nodes

## Number of Parties per Validator

While the underlying Canton participant supports up to 1 million parties per node, limitations in the validator app currently mean that only up to 200 parties are supported when the validator app is involved. The limit of 200 parties is expected to be lifted in the future which should make those workarounds no longer required.

Concretely, the limit of 200 parties applies to:

1. Parties not using external signing that are onboarded through the validator APIs or any other party for which a `WalletAppInstall` contract has been created separately.
2. Parties using external signing for which the onboarding contracts have been set up through `/v0/admin/external-party/setup-proposal` or where a `ValidatorRight` contract with the `validator` party set to the validator operator party has been created manually.

It does not apply to:

1. Parties not using external signing that have been created through the Ledger API or Canton admin API and have not been onboarded through the validator APIs or have associated `WalletAppInstall` contracts.
2. Parties using external signing for which no corresponding `ValidatorRight` exists with the `validator` party set to the validator operator party. Note that `/v0/admin/external-party/setup-proposal` does set up such a `ValidatorRight` contract so this API must be avoided. Using the `ExternalPartySetupProposal` contract directly for setting preapprovals is possible but the `validator` party must be set to a different party than the validator operator party. This also implies that you need to write your own automation to renew the preapproval when it expires. Refer to [docs](/appdev/modules/m7-canton-coin-preapprovals) for more details.

### Bypassing the Limit

The preferred option of bypassing the limit is to set up an external party either directly through the [Canton APIs for external signing](/appdev/deep-dives/external-signing) or `/v0/admin/external-party/topology/{generate,submit}` on the validator API but *not* use the endpoints under `/v0/admin/external-party/setup-proposal`.

If you do not need preapprovals, this is sufficient.

If you do need to create preapprovals, you must ensure that you do not create `ValidatorRight` contract with the `validator` party set to the validator operator. The best option for this is to use `#splice-wallet:Splice.Wallet.TransferPreapproval:TransferPreapprovalProposal` to gather authorization from both the external party and the validator operator which creates the `TransferPreapproval` but does not create a `ValidatorRight` contract. As long as the `provider` on the resulting `TransferPreapproval` is the validator operator party, the renewal automation for transfer preapprovals in the validator will still continue functioning. If you set it to a different party, you need to build your own renewal automation.

### Implications of bypassing the Limit

Note that bypassing the validator limit does mean that the validator app does not process any contracts for that party. Most notably, this means that there is no reward minting automation running for that party including the fact that `ValidatorRewardCoupon` activity records generated for that party cannot be minted by the validator operator as this relies on the `ValidatorRight` contract. If reward minting is required, you have two options:

1. Use a [minting delegation](/global-synchronizer/splice-fundamentals/rewards-minting) to delegate reward collection to a validator
2. Build your own minting automation.

You also cannot use any of the validator endpoints under `/v0/admin/external-party/` for this party, e.g., to initiate a transfer. Instead, interact with the external party through the [token standard](/appdev/deep-dives/token-standard) over the ledger API.

## Topology Batching

By default, topology batching is disabled meaning that every single topology transaction gets submitted as its own message to the synchronizer. This is in particular required for bootstrapping where a batch that is too large could exceed the free traffic limit preventing the node from ever being able to even get to the point where it can purchase traffic and the only option is to purchase traffic for the new node from an existing node.

However, after bootstrapping is complete (the validator readiness probe reports as ready and you observe rewards collected), it can be useful to increase the batch size to increase the throughput of topology transactions that can be submitted by your node. This is in particular useful for nodes from wallets that host a lot of different end user parties.

To do so, add the following [environment variables](/global-synchronizer/deployment/configuration) to your participant configuration. You can experiment with the batch size but batch sizes above 20 are not recommended as batches that are too large can cause issues.

```
- name: ADDITIONAL_CONFIG_TOPOLOGY_BATCH_SIZE
  value: |
    canton.participants.participant.topology.broadcast-batch-size = 20
```