This article is for Administrators only.
For step-by-step instructions on how to edit the admin rule, see Edit the admin rule.
Admin rule is the name given to the number of approvals required from all Administrators to authorize sensitive actions in your workspace (for example: creating an account, revoking a user...). It's the minimum number of approvals that must be collected before a request is effective.
To properly operate in your workspace, the admin rule must be set up in such way that there is always:
- at least three Administrators registered and a maximum of 20.
- a minimum of two approvals to ensure responsibility is shared among Administrators and a maximum of n-1 out of n.
Editing the admin rule is a critical action and should be thought through beforehand. All pending requests will fail if they're not processed before editing the admin rule as a new number of approvals will have to be collected.
Revoking an Administrator potentially decreases the required number of approvals required to authorize sensitive tasks. You'll be prevented from revoking an Administrator if this results in having less than three Administrators registered in your workspace.
You'll be prevented from editing the admin rule if any of the following requests are pending approval in your workspace:
- Invite Administrator
- Revoke Administrator
- Edit admin rule
For step-by-step instructions on how to create an account, see Create an account.
You can create an unlimited number of accounts in your workspace, each corresponding to a single crypto asset.
The Ledger Vault currently supports the following crypto assets.
Due to a hard fork, Komodo is currently not supported.
|Bitcoin Cash (BCH)||Litecoin (LTC)|
|Bitcoin Gold (BTG)||PIVX (PIVX)|
|Dash (DASH)||Vertcoin (VTC)|
|Digibyte (DGB)||Viacoin (VIA)|
|Dogecoin (DOGE)||Ripple (XRP)|
Over 1,000 ERC20 tokens
You can ensure transaction requests are submitted to designated approvers before they're sent to the blockchain network using transaction rules.
Build simple workflows with a single approval step, or complex workflows using up to four rules each containing different conditions on approval steps, amount ranges, and whitelists.
Transaction rules conditions
Transaction rules allow setting up conditions to require specific approvals if the conditions are met.
Selected Operators can create transactions in the account.
You can select up to 20 Operators or a single group.
|Amount range (optional)||
Allows defining the minimum and maximum amounts that can be spent per transaction.
If not provided, Operators can send any amount.
Allows restraining the list of recipients to which funds can be sent to.
If not provided, Operators can send funds to any address.
|Approval workflow (optional)||
Allows defining request approvers and up to three different rounds of approval before a transaction is broadcasted to the network.
You create the HeyBitcoin account with two rules.
- Rule 1 for transactions between BTC 0 and BTC 20 Operators of the APAC Ops group are allowed to send funds to any addresses and you apply a 3-step approval workflow where a total of 5 Operators are required to approve.
- Rule 2 for transactions between BTC 20 and BTC 50, you allow Operators to send funds to addresses listed in the APAC Ops whitelist only, and you apply a 2 step approval workflow where a total of 5 Operators are required to approve.
Transaction rules are applied sequentially. In other words, you must arrange them in the order you want them to be executed. This is particularly important as the first matching rule will always be selected. If the first rule isn't applicable, the next rules are checked until the first valid rule is found.
In cases where the amount range overlaps between two rules the first valid rule will always be selected. For example, an overlap on BTC 100:
- Rule 1: BTC 0 to BTC 100.
- Rule 2: BTC 100 to BTC 200, the transaction rule selected and applied will always be rule 1.
Drag and drop tabs to order rules when creating the account.
Rules are applied automatically depending on the amount and recipient address entered by the Operator when creating the transaction.
Example (part 2)
Operators can't create and approve the same request...
This ensures responsibility is shared among Operators. If an Operator has been selected in the approval workflow and in the Creators conditions they'll only be able to perform one action: create the transaction request or approve it.
A group can't be selected more than twice...
The same group can be selected once in the Creator condition and once in the Approval workflow. However, the Operator who created the request won't be able to approve it. As a result, you will never be able to have all Operators in the group to approve the request as the Operator who created it will be counted out.
The same group can't be selected twice as an approver in the Approval workflow condition. The same goes for individual users.
ERC20 token accounts created in your workspace must all be connected to an Ethereum account — the parent. This parent Ethereum account is used to pay gas fees when Operators create transactions, and should therefore always be credited.
When creating a token account you have two options:
- Connect it to an existing Ethereum account: To allow the ERC20 account to use this Ethereum account to pay for gas fees. This is possible only if that account hasn't been connected to another occurrence of that same token.
- Create a new one: To automatically create a new Ethereum account if none exist in your workspace or if the existing ones are already linked to an occurrence of the ERC20 token. This account will be view-only until you activate it by providing transaction rules.
View-only is the status given to accounts for which transaction rules haven't been defined yet. This status can be given to two types of accounts:
- Ethereum accounts created while Creating ERC20 accounts.
- ERC20 tokens that have been airdropped into your Ethereum account.
To activate view-only accounts, you must provide their transaction rules. This can be done from the account's dashboard. Until you do so, the account will have the View-only status and Operators won't be able to create transactions. However, if the Ethereum account is credited, it can be used to pay gas fees when creating transactions in children ERC20 accounts.
For more information, see Activate a view-only account.
Account permission limitation
Operators who have access to ERC20 token accounts, but not the parent Ethereum account won't be able to access the Ethereum account dashboard. This won't prevent them from creating transaction in the ERC20 token accounts.
You can generate a public address from the account's dashboard each time you need to share it or transfer funds to yourself from any hardware wallet or exchange platform.
To provide the best level of security, verify the address after you copy and paste it. Malware on your computer might replace addresses in your clipboard.
If the account you create uses whitelists only, make sure you either add the address index 0 of that account to one the whitelists or create a separate rule for this address. This is to ensure Operators can consolidate UTXOs in the account.
Groups are particularly useful if you'd like to gather users who hold a similar approval level or who belong to the same company. A group can contain up to 20 members. If an Operator is revoked from your workspace, they'll also be automatically removed from any group they belong to.
A whitelist is a collection of addresses that can be linked to accounts. It allows ensuring Operators send funds to a specific set of addresses only. This is particularly useful if you create whitelists for specific customers or if you want to save time by gathering your most used addresses.
You can save up to 25 addresses in a whitelist, and for ease of identification, each must be named. It can contain any crypto asset addresses. However, when creating an account, only whitelists containing at least one address in the currency of the account can be linked.
It's not currently possible to whitelist ERC20 token addresses. To bypass this limitation, saving the parent Ethereum address in a whitelist will automatically include all children ERC20 token addresses.
It's not currently possible to delete whitelists.