Overview

A transaction restriction is a rule that says: "If a transaction matches these criteria, then these approvers must sign off." Each restriction has:

• Filters - the conditions that decide whether a restriction applies (asset, amount, source account, destination, etc.)
• Action - who must approve when the filters match, or whether to block the transaction

Transaction restrictions cover anything that signs or broadcasts a transaction: transfers, contract calls, contract deploys, raw signing, staking, sponsored transactions, and allocations.

Evaluation Semantics

Transaction restrictions are additive. When a transaction arrives:

1. Every transaction restriction is checked against the transaction.
2. For each restriction whose filters match, its approval requirements are added.
3. The transaction is allowed when all the accumulated approval requirements are satisfied.
4. If no restriction matches, the transaction is allowed without approvals.

This means the policy engine is allow-by-default: to block something, you must write a restriction that matches it and sets Action to Block.

Filter Values

Filters in the UI use these patterns:

• Any - matches everything for that field
• Only: A, B, C - matches only the listed values
• All except: A, B, C - matches everything except the listed values

Amount filters use a numeric threshold with a currency. 0 USD is treated as "any amount" (the filter is effectively disabled).

Action

The Action column in the UI says what happens when the filters match:

• N of <group> - requires N approvals from members of that group (e.g. 2 of owner)
• N of <group A>, M of <group B> - requires both approval sets (additive within a single restriction)
• Block - denies the transaction; no approver set can satisfy it

Confirmation and approval

When a transaction requires approvals and has an initiator, the initiator must confirm it first. Confirmation is the initiator's signed attestation to the intent shown in the Approver App. After confirmation, the wallet collects any remaining approvals from the configured approver groups.

The initiator acts as confirmer during that first step. Whether confirmation also counts as an approval depends on group membership:

• If the initiator belongs to a group from which approvals are required, their confirmation counts as one approval from that group.
• If the initiator does not belong to a required group, confirmation does not count toward that group's quota. The full number of group approvals is still required.

Example: a restriction requires 2 of owner.

Confirmation is skipped when no approvals are required, or when the operation has no initiator (for example some API-initiated flows).

UI Columns

Each row in the Transaction tab is one restriction. When you add or edit a restriction, the form groups Action (Block or Approvals), Group(s) and No. Required, Source (and source accounts when narrowed), Amount (USD), and an Advanced section for Destination, Symbol, and Function (for example Mint, Burn, Clawback).

Scenarios

All restrictions are added independently; their effects accumulate.

---

Scenario 1: Two-of-N owner approval for any transaction

The simplest baseline: every transaction needs two approvals from the owner group. This is what the new-tenant setup creates by default.

Result: any transfer, contract call, deploy, raw sign, etc. requires 2 owner approvals. If the initiator is in owner, they confirm first and that confirmation counts as one of the two; otherwise the initiator confirms and two separate owner approvals are still required.

---

Scenario 2: Higher bar for large transfers

Keep the baseline rule, and require an additional compliance approval whenever the transaction value is at or above 100,000 USD.

Result:

• A 50,000 USD transfer matches only the baseline rule and needs 2 owner approvals.
• A 250,000 USD transfer matches both rules and needs 2 owner approvals plus 1 compliance approval.

The pricing service converts native asset amounts (ETH, BTC, etc.) to USD for the comparison, so the rule applies regardless of which asset is being sent.

---

Scenario 3: Allowlist for external destinations

Block transfers to anywhere except a known set of audited counterparty addresses. Internal transfers between vault accounts are unaffected.

Result:

• A transfer to one of the listed counterparties does not match this rule, so only the baseline rule applies.
• A transfer to any other external address matches this rule and is denied.

---

Scenario 4: Restricted minting authority

Mint operations on tokens should only be initiated from the conversionWallet source account, and only with elevated approvals depending on size.

Result:

• Any Mint attempted from a source other than conversionWallet is blocked.
• A Mint from conversionWallet under 1,000,000 USD requires 1 approval from operationsMint.
• A Mint from conversionWallet at or above 1,000,000 USD matches both Mint rules and requires 2 approvals from operationsMint (the higher requirement absorbs the lower).

API reference

Programmatic access uses the CWP routes on the wallet (same contract as the UI):

• Get transaction restrictions - GET /api/cwp/restrictions/transaction
• Start update transaction restriction - POST /api/cwp/operations/start/updateTransactionRestriction