Country compliance modules for asset jurisdiction control

Configure DALP country allow-list and block-list compliance modules so an asset accepts holders only from approved jurisdictions or rejects sanctioned ones.

DALP ships two country-restriction compliance modules. The allow-list module accepts holders whose OnchainID jurisdiction claim matches a configured allow-list. The block-list module rejects holders whose claim matches a block-list. Both modules read the same jurisdiction claim from the identity registry and apply the rule before every regulated operation.

For the architecture reference, see Country restrictions.

When to pick allow-list vs block-list

Pick	When
Allow-list	The instrument is restricted to a specific set of jurisdictions (Reg D, Reg S, MiCA, jurisdiction-specific stablecoin authorisation). Holders outside the list cannot hold.
Block-list	The instrument is generally open but must exclude sanctioned countries or jurisdictions that the operating model cannot serve. Holders inside the block-list cannot hold.
Both	A combined posture where the asset accepts holders from any allowed jurisdiction except an additional block-list. Configure both modules together.

Prerequisites

The asset already exists (configure during creation) or you have the Asset administrator role on the deployed asset (configure post-deployment).
Every prospective holder has a registered identity with a jurisdiction claim from a trusted issuer.
The list of allowed or blocked country codes is approved by your operating team. DALP submits country codes as ISO 3166-1 numeric.

Configure during asset creation

Open the Asset Designer, pick a template, fill the asset basics, and reach the compliance step. Pick the country allow-list module, the country block-list module, or both. For each:

Add the country codes that apply.
For the allow-list, an empty list rejects all transfers, so populate the list before the asset goes live.
For the block-list, an empty list passes all transfers, which is the correct default before sanctions are in effect.

Continue to initial roles and deploy.

Configure on an existing asset

From the asset detail workspace, open the compliance tab and add the country module to the asset's policy. Enter the country codes and save. The platform queues an on-chain transaction to update the module. Wait for the transaction to confirm before treating the new policy as active.

Operating considerations

The module reads the holder's jurisdiction claim from the identity registry. If a holder's jurisdiction changes, the issuer or compliance operator must re-issue the claim with the new value. The module re-evaluates on the next operation.
Compliance-policy changes apply forward. Existing holders whose jurisdiction becomes blocked do not lose their holdings automatically; coordinate forced transfer or escheatment through the operating runbook.
Country codes use ISO 3166-1 numeric values. The Asset Designer accepts country selection through a picker that maps to the numeric code; the API accepts the numeric directly.

What stays external

DALP enforces the configured list. Sanctions-screening process, regulatory licence treatment, and the jurisdiction-eligibility decision for new holders stay with your compliance team.

Troubleshooting

What you see	What to check
Allow-list set but every transfer rejected	The allow-list is non-empty but does not include the holder's country code. Confirm the holder's jurisdiction claim and the configured list.
Block-list set but transfers still pass for a target country	Confirm the block-list module is enabled on the asset, the country code is correct, and the holder's jurisdiction claim points at that country.
Module update transaction stuck	Read the asset detail workspace's transaction view for the failure reason; common causes are missing operator role or a paused asset.

Country restrictions