Investor count limit

The investor-count module counts unique OnchainIDs holding a non-zero balance and rejects any transfer that would introduce a new identity beyond a configured ceiling. Use the module for private-placement caps such as the Reg D 99-investor limit, Reg S investor restrictions, jurisdictional sub-limits, or any rule that bounds the size of the investor base.

You can cap the investor base three ways, alone or in combination: a single global maximum, per-country sub-limits, and an issuer-wide tracker shared across every asset that runs the same module instance.

For the architecture reference, see Supply and investor limits.

Prerequisites

• The asset already exists (configure during creation) or you have the Asset administrator role on the deployed asset.
• The maximum holder count, any per-country sub-limits, and the issuer-wide decision are approved by your operating team and reflect the regulatory or corporate-action rule.
• Holders have registered OnchainIDs. The module counts unique identities, so wallet count is irrelevant. Per-country sub-limits also require a country code on the holder's registered identity.

Configure during asset creation

In the Asset Designer compliance step, pick the investor-count module and set the controls you need.

1. Enter Maximum investors for the global cap. For a private placement limited to 99 investors, enter 99. Leave it at 0 when you only want per-country sub-limits and no overall ceiling.
2. Add Per-country limits for any jurisdiction that has its own cap. Select the country and enter its limit. A per-country sub-limit is enforced within the global cap: with a global maximum of 1000 and a 500 limit on one country, that country can never exceed 500 even though the asset has room up to 1000.
3. Enable Global (issuer-wide) when one investor tracker should be shared across every asset that uses this module instance, so the cap applies to the whole programme rather than a single asset.

Set the global maximum, the per-country sub-limits, or both. At least one cap must be present for the module to enable.

Configure on an existing asset

From the asset detail workspace, open the compliance tab and update the global maximum. The platform queues an on-chain transaction. The new global limit applies forward. The platform does not retroactively block existing holders if the new limit is below the current count, but new transfers to fresh holders are blocked until burn or transfer reduces the count.

Set per-country sub-limits at asset creation. After a country's limit is first applied, the stored value is authoritative for that country, so treat per-country sub-limits as fixed for the life of the configuration rather than a routine later edit. When a jurisdictional cap genuinely changes, plan the change with your operating team rather than expecting an in-place edit to take effect like the global maximum does.

Per-country sub-limits

Per-country sub-limits cap holders from a specific jurisdiction independently of the global cap.

• The module reads each holder's country from their registered identity and counts them against that country's sub-limit.
• A transfer to a new holder must pass the country sub-limit first and then the global maximum. Both apply when both are configured.
• A holder whose identity carries no country code counts toward the global maximum but not toward any per-country sub-limit.
• Each country appears once. The configuration rejects duplicate country entries and rejects a sub-limit of zero, so remove a country entirely rather than setting its limit to zero.

Issuer-wide tracking

By default the count is specific to the asset. Enable Global (issuer-wide) to share one investor tracker across every asset that uses the same module instance.

• Issuer-wide tracking suits a programme where the same investor base must stay within one cap across several assets, such as a multi-series offering under a single investor ceiling.
• Use the default asset-specific behaviour when each asset must hold its own isolated count.
• Decide issuer-wide tracking before the module starts counting. Keep it consistent across the assets that should share the tracker.

Choosing the module version

The Asset Designer offers two investor-count versions.

• The standard investor-count module supports the global maximum, per-country sub-limits, and issuer-wide tracking together. It releases count capacity when a holder's balance returns to zero, so the count reflects current active holders. Choose it when your policy needs jurisdictional sub-limits, a shared issuer-wide cap, or active-holder counting.
• The per-token version enforces a single global maximum with strict per-asset isolation and no per-country sub-limits or issuer-wide toggle. Its count is all-time: an identity that ever held the asset stays counted even after its balance returns to zero, so a burn or full exit does not free a slot for a replacement investor. Choose it when each asset must keep its own count, you need nothing beyond one overall ceiling, and all-time counting fits the policy.

Operating considerations

• The count is per unique OnchainID, not per wallet. A holder with multiple wallets under the same identity counts once.
• In the standard module, the count increases when a new identity acquires a non-zero balance and decreases when an identity's balance returns to zero. Forced transfers and burns release count capacity. The per-token version counts all-time identities and never releases capacity on zero balance.
• Transfers that move balance between two existing holders do not change the count. Transfers that introduce a new holder are checked against the per-country sub-limit and the global maximum.
• Set each value at the regulatory limit, not below. Manually tracking an off-by-one buffer creates operational risk; the module enforces the value exactly.

What stays external

The choice of cap values and the audit trail justifying any update stay with your operating team. That covers the global maximum, the per-country sub-limits, and the issuer-wide scope.

Troubleshooting

Read next

• Compliance overview
• Supply and investor limits architecture
• Identity allow-list for explicit holder approval alongside the count cap.