Policies Overview

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.

A Policy is defined by:

an Activity kind: the type of activity that this policy should gate.
a Rule: defines the rule being evaluated to know whether the policy should "activate" (aka "trigger") or not for a given activity happening in the system.
an Action: after rule was evaluated, if the policy is triggered, the action defines what action is taken as a consequence.
optional Filters: these can be used to reduce the scope upon which the policy applies.

Once evaluated for a given activity, a policy is either Skipped if the rule did not apply or is triggered executing the associated action. If the action is RequestApproval, an Approval process is initiated.

Activities

"Activity" is a generic term describing some activity in the Dfns system. Supported activity kinds are: Wallets:Sign, Permissions:Assign, Permissions:Modify , Policies:Modify.

`Wallets:Sign` activity

A "Wallets:Sign" activity represents any activity which involves signing with a wallet. Currently, in our API, these can be:

a Transfer Request (created using the endpoint Transfer Asset from Wallet)
a Transaction Request (created using the endpoint Broadcast Transaction from Wallet)
a Signature Request (created using the endpoint Generate Signature from Wallet)

`Permissions:Modify` activity

A "Permissions:Modify" activity represents any activity which involves updating or archiving a permission. These activities are Permission change requests, created as a result of calling either:

the endpoint Update Permission
the endpoint Archive Permission

`Permissions:Assign` activity

A "Permissions:Assign" activity represents any activity which involves assigning a permission (or revoking it, aka "deleting a permission assignment"). These activities are Assignment change requests, created as a result of calling either:

the endpoint Assign Permission
the endpoint Revoke Permission

`Policies:Modify` activity

A "Policies:Modify" activity represents any activity which involves updating or archiving a policy. These activities are Policy change requests, created as a result of calling either:

the endpoint Update Policy
the endpoint Archive Policy

Every policy requires a rule to be specified. Upon policy evaluation, the configuration specified in the rule will be used to determine whether the policy should trigger or not for a given activity.

By exposing controls on permissions and policies, Dfns enables the specification of an admin quorum to approve sensitive actions which could change system governance. Note Dfns does not expose a separate "admin quorum" concept like some of our competitors - we simply enable this use case as another configuration of the policy engine itself. This was chosen to promote flexibility as not every customer will have the same requirements around creating and managing admin quorums.

Policy Rules

The policy rule is what gets evaluated to determine whether a given activity will "activate" (aka "trigger") the policy, therefore applying the policy "Action", or whether it will skip it.

Supported Policy Rule kinds are:AlwaysTrigger, TransactionAmountLimit, TransactionAmountVelocity, TransactionCountVelocity, TransactionRecipientWhitelist .

`AlwaysTrigger` policy rule

This rule can be used on a policy of any activityKind. It will always be triggered, meaning that if this rule is defined on a policy, the policy will always trigger the policy action, regardless of the activity details.

{
  "rule": {
    "kind": "AlwaysTrigger",
  }
}

`TransactionAmountLimit` policy rule

This rule can be used on a policy of activityKind = Wallets:Sign. It will trigger if the wallet activity detected is transferring some value which amount is greater than a given limit.

If the fiat amount of the wallet activity cannot be evaluated for any reason (eg. market prices are not available, or eg. the amount cannot be inferred from a wallet signature request, etc.), by default the rule will trigger the policy (this is called "failing closed" and is generally considered a security best practice).

{
  "rule": {
    "kind": "TransactionAmountLimit",
    "configuration": {
      "limit": 1000,
      "currency": "EUR",
    },
  }
}

Configuration

Property Type Description

Property	Type	Description
`limit`*	Positive Integer	Amount limit in `currency`
`currency`*	String	Fiat currency, either `EUR` or `USD`

limit*

Positive Integer

Amount limit in currency

currency*

String

Fiat currency, either EUR or USD

`TransactionAmountVelocity` policy rule

This rule can be used on a policy of activityKind = Wallets:Sign. It will trigger if the cumulative amount transferred from a given wallet within a given timeframe is greater than a specified limit. The aggregate amount evaluated is based only on the wallet that triggered the policy.

If the fiat amount of any wallet activity in the given timeframe cannot be evaluated for any reason (eg. market prices are not available, or eg. the amount cannot be inferred from a wallet signature request, etc.), by default the rule will trigger the policy (ie. will fail closed).

{
  "rule": {
    "kind": "TransactionAmountVelocity",
    "configuration": {
      "limit": 1000,
      "currency": "EUR",
      "timeframe": 60,
    },
  },
}

Configuration

Property Type Description

Property	Type	Description
`limit`*	Positive Integer	Amount limit in `currency`
`currency`*	String	Fiat currency, either `EUR` or `USD`
`timeframe`*	Positive Integer	Time period in minutes. Minimum 1, Maximum 43,200.

limit*

Positive Integer

Amount limit in currency

currency*

String

Fiat currency, either EUR or USD

timeframe*

Positive Integer

Time period in minutes. Minimum 1, Maximum 43,200.

`TransactionCountVelocity` policy rule

This rule can be used on a policy of activityKind = Wallets:Sign. It will trigger if the number of wallet activities for a given wallet within a given timeframe, is greater than a specified limit. The aggregate number of transactions evaluated is based only on the wallet that triggered the policy.

{
  "rule": {
    "kind": "TransactionCountVelocity",
    "configuration": {
      "limit": 5,
      "timeframe": 60,
    },
  },
}

Configuration

Property Type Description

Property	Type	Description
`limit`*	Positive Integer	Amount limit in `currency`
`timeframe`*	Positive Integer	Time period in minutes. Minimum 1, Maximum 43,200.

limit*

Positive Integer

Amount limit in currency

timeframe*

Positive Integer

Time period in minutes. Minimum 1, Maximum 43,200.

`TransactionRecipientWhitelist` policy rule

This rule can be used on a policy of activityKind = Wallets:Sign. It will trigger if the wallet activity transfers some value to a recipient and the destination address is NOT whitelisted.

If the wallet activity is not a value transfer, or the transaction recipient cannot be inferred from the wallet activity (eg if you use Generate Signature), by default the rule will trigger the policy (ie. fail closed).

If the specified whitelisted address list is empty, it basically means "no addresses are whitelisted", so the rule will trigger for any wallet activities.

{
  "rule": {
    "kind": "TransactionRecipientWhitelist",
    "configuration": {
      "addresses": ["0x...1", "0x...2"],
    },
  }
}

Configuration

Property Type Description

Property	Type	Description
`addresses`*	List of Positive Integer	Whitelisted recipient addresses

addresses*

List of Positive Integer

Whitelisted recipient addresses

Policy Action

An action specifies what should happen if a policy rule is triggered. Supported action kinds are: BlockandRequestApproval.

`Block` policy action

This action means that the activity will be blocked if the policy is triggered.

{
  "action": {
    "kind": "Block"
  }
}

`RequestApproval` policy action

This action means that activity will first require an Approval process to be completed before it can be executed (or be aborted if someone rejects it during the approval process).

One or several groups of approvers need to be specified. These groups define who is allowed to approve / reject an activity.

The activity will only be executed if all approver groups reach their "quorum" of approvals. Otherwise, if any one user within any approver group rejects, then the activity is aborted and the call is not executed.

The example below shows a RequestApproval action, configured with one approval group requiring 2 approvals amongst three specific users.

{
  "action": {
    "kind": "RequestApproval",
    "autoRejectTimeout": 60, // minutes
    "approvalGroups": [
      {
        "name": "Admins",
        "quorum": 2, // only 2 approvers required in that group 
        "approvers": {
          "userId": {
            "in": ["us-...1", "us-...2", "us-...3"],
          }
        }
      }
    ],

  }
}

property Type Description

property	Type	Description
`approvalGroups`*	List of Object	List of approval groups. If multiple groups are defined, the approval is complete only when all groups have approved
`approvalGroups[*]` `.name`	(Optional) String	Optional name of this group.
`approvalGroups[]` `.quorum`	Positive Integer	The quorum is the number of approvals required in this group to reach group consensus. The activity is executed only if all groups reached their approval quorum.
`approvalGroups[]` `.approvers`	Object	Defines all users that are allowed to approve in the group. If set to an empty object `{}`, it means that anyone within your organisation can be an approver. Otherwise, you can specify an exact list of allowed approvers, by adding their user IDs in this object: `{ userId: { in: [...] }}`
`autoRejectTimeout`	(Optional) Positive Integer	Number of minutes after which, if the approval has not reach global consensus (all groups reached their consensus), the activity is automatically rejected. If not specified, the activity will never be rejected automatically (the approval process doesn't "expire" / "times out").

approvalGroups*

List of Object

List of approval groups. If multiple groups are defined, the approval is complete only when all groups have approved

approvalGroups[*]

.name

(Optional) String

Optional name of this group.

approvalGroups[*]

.quorum*

Positive Integer

The quorum is the number of approvals required in this group to reach group consensus. The activity is executed only if all groups reached their approval quorum.

approvalGroups[*]

.approvers*

Object

Defines all users that are allowed to approve in the group. If set to an empty object {}, it means that anyone within your organisation can be an approver. Otherwise, you can specify an exact list of allowed approvers, by adding their user IDs in this object: { userId: { in: [...] }}

autoRejectTimeout

(Optional) Positive Integer

Number of minutes after which, if the approval has not reach global consensus (all groups reached their consensus), the activity is automatically rejected. If not specified, the activity will never be rejected automatically (the approval process doesn't "expire" / "times out").

Policy Filters

Policy filters can reduce the scope on which the policy applies. If no filters are specifies, the policy applies to all activities happening in your organisation (all activities of the kind defined by the policy activityKind).

For example, you can use filters to setup a policy for activities happening on specific wallets or on groups of wallets. Some examples include:

"All activities from wallets tagged 'group:treasury' must first be approved by the CEO
"All transfers from wallet ID 1 larger than $1k must first be approved by the CEO & the CFO"
"All transfers from wallets tagged 'accounting:freeze' must be blocked"

The filters that you can specify depend on the activityKind of your policy (activityKind)

Filters for `"Wallets:Sign"` activity

key evaluator Value

key	evaluator	Value
`walletId`	`in`	List of wallet IDs. If the activity is from a wallet within one of these IDs, the policy applies to this wallet.
`walletTags`	`hasAny`	List of tags. If the activity is from a wallet that has any of these tags, the policy will apply to this wallet.
`walletTags`	`hasAll`	List of tags. If the activity is from a wallet that has all of these tags, the policy will apply to this wallet.

walletId

in

List of wallet IDs. If the activity is from a wallet within one of these IDs, the policy applies to this wallet.

walletTags

hasAny

List of tags. If the activity is from a wallet that has any of these tags, the policy will apply to this wallet.

walletTags

hasAll

List of tags. If the activity is from a wallet that has all of these tags, the policy will apply to this wallet.

Some examples:

The policy is scoped only to wallets with IDs wa-1 or wa-2:

{
  "filters": {
    "walletId": {
      "in": ["wa-1", "wa-2"]
    }
  }
}

The policy is scoped only to wallets tagged either "domain:accounting" or "sensitive":

{
  "filters": {
    "walletTags": {
      "hasAny": ["domain:accounting", "sensitive"]
    }
  }
}

The policy is scoped only to wallets tagged with both "domain:accounting" and "sensitive":

{
  "filters": {
    "walletTags": {
      "hasAll": ["domain:accounting", "sensitive"]
    }
  }
}

The policy is scoped only to wallets containing all these tags ("domain:accounting", "zone:asia") AND at least one of these tags ("security:high", "security:medium"):

{
  "filters": {
    "walletTags": {
      "hasAll": ["domain:accounting", "zone:asia"],
      "hasAny": ["security:high", "security:medium"]
    }
  }
}

Note the relationship between inclusion operators is always AND, not OR.

Filters for `"Policies:Modify"` activity

filter key evaluator Value

filter key	evaluator	Value
`policyId`	`in`	List of policy IDs. If the policy being modified is one of these IDs, the policy applies.

policyId

in

List of policy IDs. If the policy being modified is one of these IDs, the policy applies.

Some examples:

The policy is scoped only to policies with IDs plc-1 or plc-2

{
  "filters": {
    "policyId": {
      "in": ["plc-1", "plc-2"]
    }
  }
}

Filters for `"Permissions:Modify"` activity

filter key evaluator Value

filter key	evaluator	Value
`permissionId`	`in`	List of permission IDs. If the permission being modified is one of these IDs, the policy applies.

permissionId

in

List of permission IDs. If the permission being modified is one of these IDs, the policy applies.

Some examples:

The policy is scoped only to permissions with IDs pm-1 or pm-2

{
  "filters": {
    "permissionId": {
      "in": ["pm-1", "pm-2"]
    }
  }
}

Filters for `"Permissions:Assign"` activity

filter key evaluator Value

filter key	evaluator	Value
`permissionId`	`in`	List of permission IDs. If the permission being assigned/revoked is one of these IDs, the policy applies.

permissionId

in

List of permission IDs. If the permission being assigned/revoked is one of these IDs, the policy applies.

Some examples:

The policy is scoped only to permissions with IDs pm-1 or pm-2

{
  "filters": {
    "permissionId": {
      "in": ["pm-1", "pm-2"]
    }
  }
}

Approval

When a policy is triggered and the action defined is RequestApproval, an Approval object is created containing:

details about the activity that triggered this approval flow
details on the different policy evaluations that happened for that activity and their result
details about the decisions given by each approvers

When a new Approval object is created and an approval process is required, a webhook event is emitted (event kind "policy.approval.pending"). You can subscribe to it to react to this event, eg. send notifications to the users that need to give their approval.

The Approval object can be queried using the approvalId returned from the endpoint that triggered the approval process, using the Get Approval / List Approvals endpoints.

Users can then call the Create Approval Decision endpoint to either approve / reject this activity. Of course this can also be done via the Dfns dashboard.

A user can only give his approval / rejection if he is defined inside one of the approval groups defined on the policies that triggered.

A given user can only approve or reject once. If multiple approval groups exist, a decision from a single user will count as a decision for any of the groups this user belongs to.

A rejection from any user of any groups immediately rejects an activity.

The initiator is not allowed to approve their activity, but can deny it if they need to cancel it.

Here's an Approval object example

{
  "id":"ap-...",
  "initiatorId":"us-...",
  "status":"Pending",
  "expirationDate":"2023-12-22T21:16:16.659Z",
  "dateCreated":"2023-12-22T20:56:16.662Z",
  "dateUpdated":"2023-12-22T20:56:16.662Z",
  "activity":{
    "kind": "Wallets:Sign",
    "transferRequest": { // the transfer request object from transfer endpoint
      "id": "xfr-...",
      ...
    },
  },
  "evaluatedPolicies":[
    {
      "policyId":"plc-...",
      "triggerStatus":"Triggered",
      "reason":"Number of transactions (2) is above limit (2)."
    },
    {
      "policyId":"plc-...",
      "triggerStatus":"Triggered",
      "reason":"Cumulative transfer amount (EUR 20) is above limit (EUR 2)."
    }
  ],
  "decisions":[
    {
      "userId":"us-...",
      "dateActioned":"2023-12-22T20:56:16.662Z",
      "value":"Approved"
    }
  ],
}

Last updated 5 days ago

Activities

Wallets:Sign activity

Permissions:Modify activity

Permissions:Assign activity

Policies:Modify activity

Policy Rules

AlwaysTrigger policy rule

TransactionAmountLimit policy rule

TransactionAmountVelocity policy rule

TransactionCountVelocity policy rule

TransactionRecipientWhitelist policy rule

Policy Action

Block policy action

RequestApproval policy action

Policy Filters

Filters for "Wallets:Sign" activity

Filters for "Policies:Modify" activity

Filters for "Permissions:Modify" activity

Filters for "Permissions:Assign" activity

Approval

`Wallets:Sign` activity

`Permissions:Modify` activity

`Permissions:Assign` activity

`Policies:Modify` activity

`AlwaysTrigger` policy rule

`TransactionAmountLimit` policy rule

`TransactionAmountVelocity` policy rule

`TransactionCountVelocity` policy rule

`TransactionRecipientWhitelist` policy rule

`Block` policy action

`RequestApproval` policy action

Filters for `"Wallets:Sign"` activity

Filters for `"Policies:Modify"` activity

Filters for `"Permissions:Modify"` activity

Filters for `"Permissions:Assign"` activity