Skip to main content
When using the Sign & Broadcast or Generate Signature endpoints, you may encounter “blocked by policy” errors. This guide explains why and how to resolve it.

​
Why signatures get flagged

The Dfns Policy Engine evaluates all signing requests. Some policy rules—like TransactionAmountLimit or TransactionRecipientWhitelist—need to extract values (amounts, recipients) from the request. Dfns does not decode serialized transactions. When you send encoded transaction data, the policy engine cannot extract these values. To stay on the safe side, it flags the transaction—triggering a Block or RequestApproval action depending on your policy configuration.
This “fail closed” behavior is a security best practice: when values can’t be determined, the policy triggers rather than letting a potentially risky transaction through unevaluated.

​
Solution: Use JSON payloads

When possible, use JSON payloads with separate fields instead of serialized transaction data. This allows the policy engine to evaluate values like the to address. 
{
  "kind": "Transaction",
  "transaction": {
    "to": "0x00fb58432ef9d418bf6688bcf0a226d2fcaa18e2",
    "value": "1000000000000000000",
    "data": "0x..."
  }
}
With the JSON format, you can use recipient whitelisting: 
{
  "name": "Whitelist approved addresses",
  "activityKind": "Wallets:Sign",
  "rule": {
    "kind": "TransactionRecipientWhitelist",
    "configuration": {
      "addresses": [
        "0x00fb58432ef9d418bf6688bcf0a226d2fcaa18e2",
        "0xa238b6008bc2fbd9e386a5d4784511980ce504cd"
      ]
    }
  },
  "action": {
    "kind": "Block"
  }
}
Address comparison is case sensitive. For EVM addresses, use the canonical all-lowercase format in your policy configuration, not the mixed-case checksum format.

​
When JSON payloads aren’t possible

Some signature types—like EIP-712 typed data or complex multi-chain formats—don’t have a JSON equivalent with extractable fields. In these cases, use wallet filters to scope your policies.

​
Using wallet tags

Tag wallets based on their policy requirements: 
# Tag wallets that need strict policy controls
curl -X PUT "https://api.dfns.io/wallets/{walletId}/tags" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"tags": ["policy:strict"]}'
Then scope policies to only apply to tagged wallets: 
{
  "name": "Require approval for large transfers",
  "activityKind": "Wallets:Sign",
  "rule": {
    "kind": "TransactionAmountLimit",
    "configuration": {
      "limit": 10000,
      "currency": "USD"
    }
  },
  "action": {
    "kind": "RequestApproval",
    "approvalGroups": [{ "quorum": 1, "approvers": {} }]
  },
  "filters": {
    "walletTags": {
      "hasAny": ["policy:strict"]
    }
  }
}
Wallets without the policy:strict tag won’t trigger this policy.

​
Using wallet IDs

For simpler setups, filter by specific wallet IDs: 
{
  "filters": {
    "walletId": {
      "in": ["wa-treasury-xxx", "wa-operations-xxx"]
    }
  }
}

​
Security considerations

When excluding wallets from policies:
  • Fund with limited amounts - Only keep what’s needed for operations
  • Use separate wallets - Don’t mix automated signing wallets with treasury
  • Monitor with webhooks - Track signing activity
  • Audit regularly - Review which wallets are excluded from policies

Policy Engine

Learn how the Policy Engine works

Wallet tags

Organize wallets with tags

Sign & Broadcast

Transaction broadcast API reference

Generate Signature

Signature generation API reference