Policy Structure
Every policy is made up of four parameters that define where, when and how rules are applied. These elements work together to automate security and approval workflows.
Scope: what the policy covers and where it applies (All wallets, Multiple wallets, Single wallet, By wallet type, Go account, All link accounts, One or more link account)
Trigger: when the policy is applied or the event that triggers the policy (e.g., a withdrawal, settlement, or staking related transaction)
Condition: criteria that must be met to help you tailor policies to match your risk tolerance (e.g., transaction size, destinations, or asset types)
Action: determines what needs to happen when a policy is triggered (e.g., additional approvals or rejecting a transaction)
Scope | Trigger | Condition | Action |
|---|
Wallet type
Policy will apply to all new and existing wallets, you can select multiple types
EXCLUDES Go Accounts | Withdrawal Unstaking Claim rewards Staking Switch validator | Destination Spending Velocity Initiated by Transfer webhook Transfer asset Not initiated by Whitelist cooldown duration Staking transaction spending limit | Auto reject Require approval from wallet admins Require approval from set of users |
All wallets
Policy will apply to all new and existing wallets automatically,
EXCLUDES Go Accounts | Withdrawal Unstaking Claim rewards Staking Switch validator
| Destination Spending Velocity Initiated by Transfer webhook Transfer asset Not initiated by Whitelist cooldown duration Staking transaction spending limit | Auto reject Require approval from wallet admins Require approval from set of users |
Single wallet
Policy will only apply to the select wallet | Withdrawal Unstaking Claim rewards Staking Switch validator
| Destination Spending Velocity Initiated by Transfer webhook Transfer asset Not initiated by Whitelist cooldown duration Staking transaction spending limit | Auto reject Require approval from wallet admins Require approval from set of users |
Multiple wallets
Policy will apply to any selected wallet(s), provides ability to group wallets | Withdrawal Unstaking Claim rewards Staking Switch validator
| Destination Spending Velocity Initiated by Transfer webhook Transfer asset Not initiated by Whitelist cooldown duration Staking transaction spending limit | Auto reject Require approval from wallet admins Require approval from set of users |
Go Account
Policy will ONLY apply to Go Accounts | Withdrawal Settlement initiated Settlement approved New counterparty connection request Connection creation Allocation/deallocation | Destination Spending Velocity Initiated by Transfer webhook Transfer asset Not initiated by Whitelist cooldown duration Settlement gross amount Settlement net amount | Auto reject Require approval from wallet admins Require approval from set of users |
More on Conditions
Conditions are optional and you can combine as many conditions as you like in a single policy. Once you’ve added more than one condition, you can choose whether you want:
At least one of the conditions to evaluate to true (conditions combined with OR)
All of the conditions evaluate to true (conditions combined with AND)
For more information on what each Condition means, refer to the definitions below.
Type | Details |
|---|
Spending limits | Policy triggers if a withdrawal or a staking transaction meets a specified threshold on a per-transaction basis |
Velocity limit | Policy triggers if a withdrawal exceeds a specified limit within a period of time The calculation is done on a rolling basis from the point of transaction initiation. Pending transfers are included in the calculation. Failed, rejected, and confirmed transactions aren’t included in the calculation. If the calculation can’t be performed for any reason, the associated actions of the policy are required, ensuring that BitGo takes the most cautious approach. Toggle for per asset / across all assets Per asset = only include transactions of the transacted asset in the spend calculation (e.g., on LINK tx’s, only consider other LINK tx’s) Across all assets = include transactions of any asset in the spend calculation
Toggle for per wallet / across all wallets This is only available if the scope includes more than 1 wallet - ‘All Wallets’, ‘Wallets by type’, ‘Multiple wallets’ Per wallet = calculates the spending for that specific wallet Across all wallets = calculates the spending across all wallets in the enterprise
Available assets depends on the scope of the policy All Wallets = can only specify in USD Wallets by type = can only specify in USD Single wallet = can specify in any asset that is supported by that wallet
|
Destination | Policy triggers if the withdrawal destination matches a specified type, there are 4 destination types: Whitelisted Non-whitelisted Within this enterprise Outside this enterprise
It is most common to manage the whitelist at the individual wallet level. If an enterprise whitelist is in use for the asset being transferred, the address must be whitelisted on both the enterprise level and wallet level. The Address Book is not related to whitelists Every time a new whitelist is created for a self-managed wallet, a corresponding rule is created that dictates the behavior. For example: Scope: [Newly created wallet] Touchpoint: Withdrawals Condition: To a non-whitelisted address Action: requires approval
In order to change the behavior (e.g., change the associated action to ”deny”), you have 2 options: Unlock the policy that was automatically created and change the action to “requires approval”. Unlock the policy to archive, and then create a more global policy:
The reason the automatically created rule needs to be deleted is because any time aggregated actions include a ”deny”, the result is a denial.
|
Initiated by | Policy triggers if a specified user initiates a withdrawal or a staking transaction |
Not initiated by | Policy triggers if a withdrawal or a staking transaction is not initiated by the specified user |
Transfer webhook | Policy triggers if a webhook for the specific URL returns anything other than 200 OK success status This type of condition is useful if there is additional verification that you want to build on your side outside of the Policy Engine. For example, platforms who want to perform a second level of verification on withdrawals to unknown addresses. There’s also an optional asset condition so that only withdrawals of that asset will send the webhook.
|
Transfer asset | Policy triggers if a withdrawal initiates for the specified assets |
Whitelist cooldown duration | Policy triggers if a withdrawal is to an address that was whitelisted within the specified cooldown time window |
More on Actions
For more information on what each Action means, refer to the definitions below.
You can also combine multiple actions and require that either:
Only one of the actions must be completed
All of the actions must be completed
Note: the automatically reject action overrides all other actions
Type | Details |
|---|
Require approval from wallet admins | This action requires approvals from the admins of the initiating wallet at the time of transaction. If there aren’t enough wallet admins to satisfy the rule, the withdrawal or staking transaction is automatically rejected. Additionally, a wallet admin can’t approve their own transaction. Therefore, if a wallet admin plans to initiate the withdrawal or staking transaction, there needs to be n+1 wallet admins, where n = the number of admin approvals required.
|
Require final approval from wallet users | This action requires 1 final approval from a list of users that hold a role on the wallet (admin, spender, or viewer). The approval occurs after the wallet admin approval and the approval from a group of users. The sequential nature of this action is useful for ensuring certain approvals take place before others. Only available for the scope of a single wallet, because the final approver needs to be a member on the initiating wallet. The default behavior is that the transaction initiator can provide their own final approval, but you can toggle this on or off.
|
Require approval from a set of users | Enables you to request approvals from any users in the enterprise, regardless of whether or not they are a user on a specific wallet. This can enhance your overall security by segregating duties among team members.
|
Automatically reject | The withdrawal or staking transaction is automatically rejected with no exceptions allowed. |
Require approval from members of a user role | Enables you to request approval from a user role.
User roles are managed by Organization Admins within the Admin Console (see Managing Users: Admin Console). Add/remove users from the role instead of on the individual policy for fewer updates and more consistent approval workflows
|