Restriction controls help an institution apply a defined policy to eligible balances or activity. Useful design begins by naming the subject, scope, authority, review, and release path; using a generic word such as “freeze” without those details can obscure very different operational effects.
The supported model distinguishes a partial amount hold, a full restriction, a restriction on account or wallet activity, and a pause affecting applicable transfer operations. These are not interchangeable. The institution defines its lawful and operational policy, while the selected network configuration determines which control paths apply.
Choose the control scope
Begin with the object that policy addresses: an institution-mapped account, a network wallet, a selected amount, or an operation type. An account-level decision may depend on an internal mapping between customer records and network addresses; private customer details do not need to be placed on chain merely to define that relationship.
Write a control statement in operational terms. Identify which activity becomes unavailable, what remains eligible, who can request the action, who approves it, and how a reviewer confirms the result. Validate the mapping and behavior in the agreed environment, especially where one institutional account corresponds to more than one wallet or where multiple workflows share an address.
Different controls act on different scopes
Partial holds and full restrictions
A partial balance hold restricts a selected amount and leaves the unheld amount available for eligible activity under the configured rules. Operations teams need a clear view of held and available portions, plus a process for changing or releasing a hold when authorized. The policy should state how overlapping holds and subsequent balance changes are handled.
A full restriction has broader effect within its configured scope, but it is not identical to pausing all applicable transfers. It can concern an eligible balance or account activity, while an operation-wide pause changes whether a class of transfer can proceed. Name the scope precisely in procedures, operator screens, reconciliation, and any customer-facing communication.
Pause, restore, and release
A pause applies to eligible transfer operations according to the configured policy. It is a network or operation control, not simply another label for restricting one wallet or holding part of a balance. Specify which transfers are affected, which related operations remain possible, and how teams will detect and communicate a pause during an incident or planned change.
Restoring eligible operations and releasing restricted amounts are separate decisions and actions. Define who may propose each transition, required approvals, evidence to retain, and a review of its impact on downstream systems. An emergency procedure, where agreed, must still have explicit authority and follow-up review; broad unrestricted access should not be inferred from the existence of a control.
A controlled restriction follows an authorized lifecycle
- Policy triggerInstitutional process identifies a case and intended scope.
- Authorized requestAn assigned operator records the proposed control and rationale.
- Required approvalConfigured governance or multi-approval rules are applied.
- Execute and reviewEligible action is recorded, reconciled, and reviewed.
- Restore or releaseA separately authorized decision ends or changes the restriction.
Test effects and assign accountability
Build test cases for the expected allow and deny outcomes, including partial availability, full restriction, operation pause, restoration, and release. Include concurrent or repeated requests where relevant, and reconcile the resulting network state with approved institutional records. The goal is to confirm configured behavior and identify workflow dependencies, not to assume every policy edge case is covered automatically.
Document control authority, approval path, operator identity, evidence, customer-support coordination, and escalation. Ensure interfaces clearly differentiate held from available amounts and wallet-specific restrictions from network pauses. Production scope, integrations, support, and any emergency service are agreed with the institution; no universal procedure or legal conclusion is implied by the technical capability.