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.
You cannot create a policy that applies to multiple wallets simultaneously. If you need the same limit across ten wallets, you must create ten separate policies—one for each wallet.
If your organization uses separate wallets for different EVM chains (for example, one Ethereum wallet and one Arbitrum wallet), policies on one wallet do not apply to the other—even if both wallets hold the same asset (ETH). You must create policies independently on each 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.
When you attempt a transaction, the system calculates how much has already left the wallet within the current window. If your new transaction would push the total over the limit, the system rejects it immediately. As older transactions "roll off" the window, capacity becomes available again.
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:
| Attribute | Description |
|---|---|
| Wallet ID | The wallet the policy belongs to |
| Limit type | PER_TX, ROLLING_DURATION, or CONSTANT |
| Symbol | The asset symbol (for example, ETH, BTC, USDC) |
| Matchers | Optional filters that narrow when the policy applies |
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 transactionsPER_TX+ETH+TRANSACTION_TYPE: WITHDRAWAL→ Applies only to ETH withdrawals
Both policies can coexist because their matcher configurations differ.
If you try to create a policy that matches an existing policy's wallet, limit type, symbol, and matchers, the API returns error PAL006.023: limit policy already exists.
Policies are immutable. You cannot edit an existing policy's limit amount, duration, or matchers.
To modify a policy:
- Delete the existing policy (see Manage policies).
- Create a new policy with the updated values.
Immutability provides a clear audit trail. Every policy change creates a new record with its own approval history, making it easy to track who authorized what and when.
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 the deletion is approved—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.
Without approval groups, anyone with API credentials that include keylimit:create scope can instantly enable policies. Consider configuring approval groups to add human oversight.
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 transaction is created. The full pipeline is:
- Policy check – The engine evaluates the transaction against all matching policies. If any policy rejects, the transaction is rejected immediately and never reaches approvers.
- Approval check – If approval groups are configured for transactions, designated approvers must authorize the transaction.
- MPC signing – The transaction is signed by the wallet's MPC quorum.
- Blockchain submission – The signed transaction is published to the network.
See Signing & approvals overview for details on approvals and MPC quorums.
- The engine finds all
LIMIT_ENABLEDpolicies that match the transaction's wallet, asset, and attributes. - For each matching policy, the engine checks whether the transaction would exceed the limit.
- If any policy rejects the transaction, the entire transaction fails.
- If all matching policies pass, the transaction proceeds to the next stage (approvals or signing).
Policy limits are checked against the transaction amount only. Network fees (gas on EVM chains, transaction fees on XRP Ledger) are not included in 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 does not push the transaction over the limit.
Not all outgoing fund movements are subject to policy checks. Asset sweeping bypasses policies entirely. A wallet does not need any policies in place to be swept, and sweep transactions are not evaluated against existing policies.
This means policies alone do not 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.
Transaction freeze controls apply to inbound transactions only (holding incoming funds for compliance review). Policies apply to outbound transactions only. These two controls operate on different transaction directions and do not interact with each other.
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.
Matcher types include: TRANSACTION_TYPE, USER, API_CREDENTIAL, ADDRESS_ID, COUNTERPARTY_ID, WALLET_ID, and SIGN_FOR.
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:
| Status | Description |
|---|---|
POLICY_CHECK_PENDING | Transaction is being evaluated against policies |
POLICY_CHECK_PASSED | Transaction passed all policy checks |
REJECTED | Transaction was rejected (by policy or approval) |
These webhooks allow you to build automated monitoring for policy enforcement — for example, alerting on rejected transactions or tracking policy check latency.
Webhook notifications cover transaction status changes only. There are no webhook events for policy creation, approval, or deletion. To track policy lifecycle changes, use the Approval domain webhooks, which notify when approval requests for policy rules are created or resolved.
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