Overview#
The Policy Engine is the core of transaction risk control for your Team. Before a transaction enters the signing stage, it must pass policy validation; transactions that fail are neither signed nor broadcast.Your Team configures its own policies to define which transactions are released directly, which require approval, and which should be blocked.Policies can only be edited in the Web Console. The app can display the policy list and policy details, with a notice at the top directing you to the Web Console to make changes.Before you begin#
You are in the correct Team;
You hold the Manage policies permission;
You understand your Team's Decision Mode — policy changes take effect only after Admin approval;
Any whitelist entries or Approval Nodes you intend to reference already exist and are active.
How policies are evaluated#
Configuring policies correctly depends on understanding these two rules.Deny by default. A transaction that matches no policy is blocked. Any transaction your Team needs to allow must be covered by a policy — which means the list needs at least one catch-all policy covering routine scenarios, or your Team will be unable to transfer at all.Evaluated in priority order. When several policies match, they are evaluated in the order shown in the list, lowest number first. Stricter policies should therefore sit near the top and the catch-all policy at the bottom.The top of the list shows when the current policy set took effect and who last edited it.What a policy contains#
A policy has matching conditions and limit conditions. Matching conditions decide which transactions the policy applies to; limit conditions decide what happens to them.Matching conditions#
Initiator — either unrestricted, or specific parties.Unrestricted means any API Key or Team member holding the initiate-transactions permission can initiate. When specifying, you can select API Keys and Team members separately, and must choose at least one of the two. Each can be set to "all" or "custom" — choosing all covers objects added in future that hold the initiate-transactions permission, so you do not need to revisit the policy after adding a member or API Key.Source account (From) — either unrestricted, or specific Team Wallets.The same all-or-custom choice applies, and choosing all wallets includes wallets created in future. A single policy can reference up to 100 wallets; split into several policies if you need to cover more.Destination account (To) — unrestricted, specific destinations, or unknown addresses.When specifying destinations, you can choose from Team Wallets and whitelist entries, selecting at least one category. The whitelist can be referenced by individual address or by group — referencing a group means addresses added to that group in future are covered automatically, which is the key to keeping policy maintenance manageable.An unknown address is any address that is neither in the whitelist nor one of your Team Wallets — that is, any address not generated or configured within DeepSafe.Token — either unrestricted, or specific tokens by network.When specifying, choose the network first and then tokens on that network, again with an all-or-custom option. A single policy can reference up to 100 tokens.Limit conditions and actions#
Limits are calculated by value in US dollars. At least one of the following two must be configured.Per-transaction value limit evaluates the US dollar value of a single transaction. Define a numeric range and assign an action to it. Multiple ranges can be added, each with its own treatment — small amounts released directly, medium amounts requiring one approval, large amounts requiring several, for example.Daily limit evaluates the Team's cumulative activity for the day, by either cumulative value or cumulative count.Two characteristics of daily limits deserve attention: they are calculated on Beijing time (UTC+8) and reset automatically at 00:00; and all Team transactions count toward them, subject to the use and limits of all policies, not only the transactions this particular policy matches.Require approval — the transaction is routed to the specified Approval Node. When selecting a node, you can see each node's name, approval threshold, and approver scope.Block — the transaction cannot be submitted.Managing policies#
Adding, editing, reordering, disabling, and deleting policies all happen in edit mode. Multiple changes can be submitted together rather than one approval at a time.Edit mode offers four actions: add a policy, reorder, discard changes, and submit for approval. When there are unsubmitted changes, the "Change" column in the list marks what happened to each policy — edited, moved in priority, and so on.Discarding changes reverts everything done in the current edit session and restores the policy set currently in effect.Submitting and approving#
Once your changes are complete, submit them for approval and the policy set enters a pending state. The top of the list then shows the current status as pending approval, and the pending policy content can be reviewed.The approval screen presents the before and after side by side — priority, policy name, each matching condition, each limit condition, and the change made to every policy. Approvers should focus on the change column.Policy approval requires both clients: in the Web Console, choose to approve and a QR code is generated, which an Admin then scans using the app to complete approval. The QR code is intended for the designated approver only — do not share it.Approval follows your Team's Decision Mode and requires the corresponding number of Admins to agree. Until approval completes, transactions continue to follow the previous policy set. Once approved, the new set takes effect and the effective time at the top of the list updates.Things to note#
Changing priority changes outcomes. Priority determines which policy governs when several match. After reordering, review each policy's coverage to confirm nothing is unexpectedly released or blocked.Deleting or disabling a policy can block transactions. Because the Policy Engine denies by default, transactions previously covered by a removed policy will fail validation unless another policy picks them up. Confirm that coverage before deleting.Changes to referenced objects affect policies. Deleting a whitelist address, adjusting a whitelist group, or editing an Approval Node's approvers or threshold all change how a policy behaves in practice. Those changes require their own approval, but that approval does not necessarily flag the effect on policies — check proactively before making them.Daily limits are Team-level. They count all Team transactions, not only those matched by one policy. When several policies each configure a daily limit, remember they are drawing on the same pool.Match approval thresholds to available approvers. If a policy references an Approval Node whose threshold exceeds the number of members actually holding the Approve transactions permission, matching transactions cannot collect enough approvals. Review this whenever you adjust member permissions.Modified at 2026-08-26 02:51:05
