Policy concepts

Transaction policies are the security rules that control what funds can leave your wallets. Every wallet in Wallet-as-a-Service (Palisade) is deposit-only by default. You must create at least one policy for an asset before you can send that asset from the wallet.

Think of policies as programmable spending limits. They automatically evaluate every outgoing transaction and block any that would exceed your configured limits. This protects your assets even if someone gains unauthorized access to your API credentials or user accounts.

Policies answer these questions:

• How much can leave in a single transaction?
• How much can leave over a period of time?
• What is the maximum that can ever leave?
• Who can initiate transactions, and to where?

This page explains the core concepts you need to understand before creating and managing policies.

Policies operate at the wallet level only. Each policy applies to a single wallet and controls transactions for a specific asset within that wallet.

Wallet-as-a-Service (Palisade) supports three limit types:

• Per transaction (PER_TX) – Maximum amount for any single transaction
• Rolling duration (ROLLING_DURATION) – Maximum cumulative amount within a sliding time window
• Max total value (CONSTANT) – Lifetime cap on total withdrawals

You can combine multiple limit types on the same wallet for layered protection.

See Policy reference for complete limit type documentation, duration values, and examples.

Each policy must be unique within its wallet. The system identifies a policy by four attributes:

You can create multiple policies with the same limit type and symbol if they have different matchers. For example:

• PER_TX + ETH + no matchers → Applies to all ETH transactions
• PER_TX + ETH + TRANSACTION_TYPE: WITHDRAWAL → Applies only to ETH withdrawals

Both policies can coexist because their matcher configurations differ.

Policies are immutable. You can't edit an existing policy's limit amount, duration, or matchers.

To modify a policy:

1. Delete the existing policy (see Manage policies).
2. Create a new policy with the updated values.

Every policy moves through a series of states from creation to deletion.

Policies move through five statuses: pending approval, enabled, rejected, pending deletion, and deleted. A policy in LIMIT_DELETION_APPROVAL_PENDING status continues to enforce transactions until approvers approve the deletion—this prevents gaps in protection.

See Policy reference for the complete status reference.

Whether a policy requires approval depends on your organization's approval group configuration.

If your organization has an approval group for Policy rules, new policies enter LIMIT_CREATION_APPROVAL_PENDING status. Designated approvers must authorize the policy before it takes effect.

The policy activates after the required number of approvers authorize it (for example, 2 of 3 approvers). If the approval threshold becomes mathematically impossible to reach (for example, too many approvers skip), the policy moves to LIMIT_REJECTED.

If no approval group exists for Policy rules, the policy automatically activates immediately after creation. It transitions directly to LIMIT_ENABLED with active: true.

See Approvals to configure approval groups for your organization.

When you submit a transaction, the policy engine evaluates it against all active policies for that wallet and asset. Policy checks are one stage in the full transaction pipeline.

Policy evaluation is the first check after a user or API credential creates a transaction. The full pipeline is:

1. Policy check – The engine evaluates the transaction against all matching policies. If any policy rejects it, Palisade rejects the transaction immediately and never sends it to approvers.
2. Approval check – If your organization configures approval groups for transactions, designated approvers must authorize the transaction.
3. MPC signing – The wallet's MPC quorum signs the transaction.
4. Blockchain submission – Palisade publishes the signed transaction to the network.

See Signing & approvals overview for details on approvals and MPC quorums.

1. The engine finds all LIMIT_ENABLED policies that match the transaction's wallet, asset, and attributes.
2. For each matching policy, the engine checks whether the transaction would exceed the limit.
3. If any policy rejects the transaction, the entire transaction fails.
4. If all matching policies pass, the transaction proceeds to the next stage (approvals or signing).

Palisade checks policy limits against the transaction amount only and excludes network fees (gas on EVM chains, transaction fees on XRP Ledger) from the limit calculation. For example, if you have a PER_TX limit of 10 ETH and send exactly 10 ETH, the policy check passes — the gas cost doesn't push the transaction over the limit.

Policy checks don't cover all outgoing fund movements. Asset sweeping bypasses policies entirely. A wallet doesn't need any policies in place before Palisade can sweep it, and Palisade doesn't evaluate sweep transactions against existing policies.

This means policies alone don't prevent all fund movement from a wallet. If you need to restrict sweeping, manage sweep configurations separately through Settings > Workflows. Only owners and administrators can configure sweeping operations.

See Asset sweeping for details on sweep configuration.

Matchers filter which transactions a policy applies to. A transaction must match all matchers on a policy for that policy to apply. If a policy has no matchers, it applies to all transactions for that asset.

Active matcher types include: TRANSACTION_TYPE, USER, API_CREDENTIAL, SIGN_FOR, COUNTERPARTY_ID, ADDRESS_ID, WALLET_ID, and CHAIN_ID. Use COUNTERPARTY_ID for new policies; reserve the older COUNTERPARTY matcher for backward compatibility.

See Policy reference for detailed matcher documentation and examples.

If you have webhooks configured for the TRANSACTION domain, you receive notifications as transactions move through the policy check stage. The relevant statuses are:

These webhooks allow you to build automated monitoring for policy enforcement — for example, alerting on rejected transactions or tracking policy check latency.

See Webhooks overview for setup instructions and payload format.

• Policy reference – Complete reference for all limit types, matchers, and configuration options
• Manage policies – Step-by-step guide to create, modify, and delete policies
• Policy best practices – Recommended patterns and common configurations