Transaction policies define the rules that govern outgoing transactions from your wallets. Without a matching policy for a given asset, Wallet-as-a-Service (Palisade) blocks all outgoing transactions for that asset. As an owner or administrator, you design policies that balance operational flexibility with security controls.
When a user or API credential submits a transaction, the Palisade policy engine automatically evaluates it against the wallet's active policies. The engine checks:
- Does a policy exist for this asset?
- Does the transaction amount fall within the policy's limit?
- Is the destination permitted by the policy?
- Is the initiator permitted by the policy (if restricted)?
- Do any other policy matchers, such as transaction type, signing address, or chain ID, match the transaction?
If the transaction matches at least one policy and satisfies all its conditions, it passes the policy check. If no matching policy exists or the transaction violates all applicable policies, the platform blocks it.
- Open the wallet and go to the Policy tab.
- Select Add a new rule.
- Select the asset the policy applies to. The dropdown lists assets currently held in the wallet.
If the asset you need isn't listed, select switch to non-standard asset and enter the blockchain, contract address, and symbol manually.
- Select a rule type:
| Rule type | What it controls | Example |
|---|---|---|
| Per transaction | Maximum amount for any single transaction | No single transaction can exceed 10 ETH |
| Rolling | Maximum amount within a time window | No more than 100 ETH per 24 hours |
Max total value (API: CONSTANT) | Lifetime cap on total withdrawals | No more than 1,000 ETH can ever leave this wallet |
- Set the value limit.
- Under Apply this rule to, select the allowed destinations:
- All counterparties and wallets - the broadest option. Permits transactions to any registered address or internal wallet.
- Selected counterparties - permits transactions only to specific counterparties and all addresses on those counterparty records. In the API, use
COUNTERPARTY_IDinstead of the olderCOUNTERPARTYmatcher. - Selected addresses - permits transactions only to specific addresses from your address book.
- Selected wallets - permits transactions only to specific wallets within your organization.
- Add any other matchers that the policy needs:
| Matcher | API value | What it controls |
|---|---|---|
| Transaction type | TRANSACTION_TYPE | Applies the rule only to selected transaction types. |
| User | USER | Applies the rule only to transactions initiated by selected users. |
| API credential | API_CREDENTIAL | Applies the rule only to transactions initiated by selected API credentials. |
| Sign for | SIGN_FOR | Applies the rule only to transactions signed for selected addresses. |
| Counterparty | COUNTERPARTY_ID | Applies the rule only to selected counterparties and their registered addresses. |
| Address | ADDRESS_ID | Applies the rule only to selected address book entries. |
| Wallet | WALLET_ID | Applies the rule only to selected wallets in your organization. |
| Chain ID | CHAIN_ID | Applies the rule only to a selected EVM chain ID for cross-chain raw signing. |
For cross-chain raw signing to an EVM chain that Wallet-as-a-Service (Palisade) doesn't natively support, add a CHAIN_ID matcher for the target chain ID. Policies without a matching CHAIN_ID matcher don't authorize those transactions.
- Select Add a new rule.
The policy engine evaluates every outgoing transaction against active policies the moment you create them. Palisade blocks any transaction that exceeds the limits or targets an unpermitted destination.
You can create multiple policies for the same asset in a wallet. When a user or API credential submits a transaction, the platform finds the policy that matches the transaction details. The transaction needs only one matching policy to pass.
This lets you create layered policies. For example:
- A per transaction policy limiting individual sends to 10 ETH
- A rolling policy limiting total sends to 100 ETH per 24 hours
- A separate policy for a specific API credential with a lower limit
To modify an existing policy:
- Create a new policy for the same asset with the updated conditions.
- The new policy overrides the previous one when the conditions match.
- Open the wallet and go to the Policy tab.
- Find the policy in the table.
- Open the Actions menu and select Delete.
If you delete the only policy for an asset, the wallet can no longer send that asset until you create a new policy.
Consider these strategies when designing your policy structure:
- Layer multiple rule types — combine per-transaction limits with rolling limits and lifetime caps for defense in depth.
- Restrict destinations — use selected counterparties or addresses instead of "all" to limit where funds can go.
- Restrict initiators — assign specific policies to specific users or API credentials. This prevents unauthorized users from initiating high-value transactions.
- Start conservative — begin with low limits in sandbox, validate your operations, then adjust limits upward as needed.
- Pair with approval groups — policies control allowed actions; approval groups add human oversight. Use both together. See Configure approval flows.
- Policies overview — Conceptual overview
- Manage policies — Reference documentation
- Unlock outgoing transactions — Full walkthrough including policy setup