User types describe how identities authenticate, not a permission Role. Put users in groups, then use Config Restrictions and Transaction Restrictions to control who can initiate and who must approve.

Human users: authenticate through your identity provider to use the UI and ApproverApp.

API Users: authenticate with an API key for programmatic access. See API User.

The institutional wallet is available in Demo Sandbox, Self-installed Sandbox, or Self-installed Production environments, as outlined below.

Demo Sandbox:
Our team uses this environment to demonstrate the product and allows users to experience and evaluate the wallet without any local installation.

Self-installed sandbox:
A replica of the production environment that allows users to go through the full process of setting up and maintaining the wallet. The self-installed sandbox environment provides comprehensive functionality in a scaled-down version of the production environment.

This allows your organization to experience the full feature set and configuration process and evaluate product security.

Self-installed production environment:
An advanced, complete version of the sandbox environment. The production environment replicates the configuration process, capabilities, and features of the “live” Institutional Vault.

API Keys are created and removed from the settings menu of the Institutional Vault account.

1. Sign in to your Institutional Vault account, click Settings in the menu on the left of the page.
2. On the settings page, click the API Keys tab, then click Create API Key.
3. Set the key's Name and select the User it should be associated with.
4. Click Create to confirm.

You should now see a new API Key entry in the list.

To remove an API Key, click the 3 dots to the right of the entry, then click Delete.

For more details, please see here.

When you sign in to your wallet account you will be taken to the Transactions page, which you can also access from the menu on the left of every page.

By default, this page lists all transactions and their details in chronological order, starting with the most recent transaction. At the top of the page you’ll see the following options to filter or customize your transaction data:

Live Updates: When enabled, the list of transactions and their statuses will update automatically. When disabled you will need to use the Refresh button on the right of the page.

Set Columns: Click this drop-down menu to choose which transaction details to display in the table. You can also see the details of any transaction by clicking the round icon to the far right of each transaction.

Filter: Allows you to filter the transaction list by criteria such as date range, source, or destination. Click “Advanced filters” to see more criteria options or click “Reset filter” to remove all filter criteria.

Export: Click here to save the transaction history as a .CSV file. This file is generated based on the views and filters that have been configured <need confirmation> so make sure to check these settings before exporting.

Administrative policy
These are the high-level rules that regulate all wallet operations. This covers user management, group management, and transfer policy.

This policy is only modifiable by users in groups that satisfy the policy restrictions.

Transfer policy
This policy governs transactions and the rules and restrictions under which the transactions are executed. The transfer policy can only be modified through Administrative policy.

Staking policy
This policy governs the staking process works in the Institutional Vault.

It is not possible to re-add themselves. They cannot register again until an Administrator resets their account status to Pending Onboarding. After the reset, they can re-register.
For more details, please see here.

User: Refers to an individual accessing the Institutional Vault. A user can create an account associated with specific permissions within the wallet. They can perform various actions within their assigned account(s) based on their permissions.

Account: A functionality within the Institutional Vault that segregates different wallet addresses. Each account is associated with a unique address for balance-based chains like Ethereum. For UTXO-based chains like Bitcoin, an account can contain multiple addresses. Accounts can be further restricted by policies. It securely stores and manages digital assets, sends and receives digital assets, tracks balances, and views transaction history.

In most cases, an account can hold one wallet address per protocol, except for Bitcoin, where multiple Bitcoin addresses can be created per account.

In summary, a user can access the Institutional Vault and specific permissions. At the same time, an account is a functionality within the wallet that allows for managing and segregating different wallet addresses.

Assign users to groups, then use Config Restrictions for configuration-change approvals and Transaction Restrictions (including Block and When initiated by) to deny or require approvals on signing operations.

By default, if no configuration is specified, Bitcoin addresses are of the P2PKH (legacy) type. However, we also support P2SH-P2WPKH addresses for Bitcoin.