Skip to main content
A Policy acts as a “gate” for a given activity in Dfns system, which enforces a set of rules before the activity is executed. If triggered, a policy can either block the activity or launch an approval process before finalizing the activity.
Default behavior: If no policies are configured, all transactions are allowed. Policies add restrictions on top of the default “allow all” behavior - they are not a whitelist.
Delegated wallets bypass policies. Policies only apply to organization-managed wallets. Delegated wallets (owned by EndUsers) bypass the policy engine entirely - this is by design for non-custodial use cases where end users have full control.
All policies are evaluated: When an activity occurs, every matching policy is evaluated. Policies cannot bypass or override each other - if any policy triggers a Block action, the activity is blocked. If multiple policies trigger RequestApproval, approvals from all triggered policies are required before the activity proceeds.
Policies are used as part of risk management, information security, or other compliance functions. The policy Engine allows you to create a policy, specifying the conditions that will result in an approval being triggered, as well as the approval groups whose approval will be required. For example: As a compliance officer, you have to implement these new processes:
  1. For payments over $100,000, request approval from a Vice President.
  2. For payments over $250,000, request approval from both a Vice President and a Managing Director.
To do that you will have to create two Policies:
  • Large Payment:
    • Rule: TransactionAmountLimit with amount value of $100,000.
    • Approval scoped to VicePresidents.
  • Very Large Payment:
    • Rule: TransactionAmountLimit with amount value of $250,000.
    • Approval scoped to ManagingDirectors.
When a policy is triggered, it generates an approval request, which must be either approved or rejected by members of the corresponding approval group. Here’s a schematic of the Policy Engine entity model: Policy Engine Schematic

​
Available rules

RuleWhen it triggers
AlwaysTriggerEvery signature request requires approval (or is blocked)
TransactionAmountLimitTransactions above a USD threshold require approval
TransactionAmountVelocityTotal value transferred from a wallet exceeds a limit within a time window
TransactionCountVelocityNumber of transactions from a wallet exceeds a limit within a time window
TransactionRecipientWhitelistTransactions to addresses not on your approved list
ChainalysisTransactionPrescreeningOutbound transactions flagged by Chainalysis KYT
ChainalysisTransactionScreeningIncoming transactions flagged by Chainalysis KYT
TravelRuleTransactionPrescreeningTransfers requiring travel rule compliance (via Notabene)
When triggered, policies can either block the transaction or request approval from designated users.

​
Approval process

When a policy triggers with the RequestApproval action, the transaction is held until enough approvers sign off. This is configured using approval groups and quorums:
  • Approval group: A set of users who can approve. You can specify exact user IDs, or allow anyone in the organization.
  • Quorum: The minimum number of approvals needed from that group. For example, “2 out of 5 admins must approve.”
You can require multiple approval groups - for instance, requiring approval from both a compliance team (1 of 3) AND a finance team (2 of 4). The transaction only proceeds when all groups reach their quorum. If any approver rejects, the transaction is cancelled. You can also set an auto-reject timeout so pending approvals don’t hang indefinitely.
By default, the person who initiated the transaction cannot approve it themselves. Set initiatorCanApprove: true if you need to allow this.
See the API reference for configuration details.

​
Automating with Service Accounts

When automating transactions with Service Accounts, you may need certain wallets to bypass approval workflows (e.g., automated payouts, scheduled transfers).

​
Using wallet tags

Use wallet tags to scope policies to specific wallets. Tag the wallets that need approval workflows, leaving automated wallets untagged:
  1. Tag wallets that need approval: Add a tag like requires-approval to wallets managed by humans
  2. Create policies with filters: Target policies only at tagged wallets
{
  "name": "Large Payment Approval",
  "activityKind": "Wallets:Sign",
  "rule": {
    "kind": "TransactionAmountLimit",
    "configuration": {
      "limit": "100000",
      "currency": "USD"
    }
  },
  "action": {
    "kind": "RequestApproval",
    "approvalGroups": [...]
  },
  "filters": {
    "walletTags": {
      "hasAny": ["requires-approval"]
    }
  }
}
This policy requires approval for large transactions but only applies to wallets tagged with requires-approval. Automated wallets without this tag won’t trigger the policy.
You can also use the walletId filter to target specific wallets, but wallet tags are more flexible for managing multiple wallets.

​
Get started

Creating policies

Step-by-step guide to create policies in the dashboard

Policies API reference

All rules, actions, and filters explained

Policies for signing

Configure policies for raw signatures and EIP-712

Approving requests

How to approve policy-triggered requests