Overview

Your workspace Owner assigns workspace roles to both Fireblocks Console and API users during user setup and they must verify that the setup process is completed and is approved by your workspace's Admin Quorum.

Follow the steps in the adding new Console users article (steps for only workspace Owners or Admins) and user setup article (steps for both the Owner and new user).

• Console user: The Console user can access and operate the Fireblocks Console according to the privileges of the assigned user role.
• API user: The API user can utilize the Fireblocks platform by using the API endpoint according to the privileges of the assigned user role. In addition, the API user is used in the API Co-Signer feature.

Note that when adding users with roles that can sign transactions, an MPC Key share must be approved for their device during user setup. Otherwise, the transactions they attempt to sign will fail.

Owners and Admins can track the status of a user's MPC key share approval in the Fireblocks Console by going to Settings > Users. In the Status column, you can see the current status, including a step called Pending Owner MPC Key Approval.

What permissions does each role have?

Refer to the user role access table for each role's capabilities.

Best practices for choosing roles

Learn more about best practices here. This best practices article also covers:

• The difference between the Admin Quorum and TAP. Who can alter each of them?
• The Owner role in the workspace and the best way to use the privileges of the Owner, Admin, and Signer user roles.
• A decision diagram to help you determine appropriate user roles based on a user’s part in the business flow. 

Owner

The Owner is an Admin user who approves multi-party computation (MPC) signing devices, new users, and TAP (Transaction Authorization Policy) changes. Every workspace requires one (and only one) Owner to set up the Vault.

For security, the Owner role must be assigned to the respective user by Fireblocks Support. When the Owner wants to change their role, migrate to a new mobile device, or unfreeze the workspace, they must first verify their identity with Fireblocks Support by scheduling a short video call.

Recommended responsibilities

• Approving new signing devices and MPC key shares
• Approving new workspace users
• Approving new external connections
• Creating API keys
• Deleting workspace users
• Enabling advanced workspace features
• Creating, editing, and approving workspace policies
• Approving changes to the TAP, together with the Admin Quorum
• Resetting Two-Factor Authentication (2FA)
• Emergency operations like freezing the workspace, creating a backup kit, and recovery

Admin

An Admin has all signer role permissions, can expand the network, approve new whitelisted addresses, edit all workspace settings, add new workspace users, and manually confirm and credit inbound transactions by marking inbound transactions as complete.

Recommended responsibilities

• Independent initiation and signing of some transactions, as defined by the TAP
• Approving transactions initiated and signed by other users
• Part of the Admin Quorum for approving workspace changes
• Part of the Admin Quorum for approving TAP changes (Owner approval also required)
• Ideal for smaller companies in which a small number of users are responsible for multiple operations
• Emergency operations like freezing the workspace

Non-Signing Admin

A Non-Signing Admin can approve transactions and perform administrative operations, such as approving new whitelisted addresses, exchange accounts, and Fireblocks Network connections; and adding new workspace users.

A Non-Signing Admin does not hold an MPC key share and cannot sign transactions. However, you can define them as the second authorizer in the TAP.

A Non-Signing Admin can initiate certain transactions if the TAP defines another user capable of signing as a designated signer for that transaction type.

Recommended responsibilities

• Approving transactions before another user signs them
• Typically uses the Fireblocks Console, but can also use the Fireblocks mobile app to approve requests
• Part of the Admin Quorum for approving workspace changes
• Ideal for separating users with signing capabilities and users with approval capabilities in your TAP
• Used as an API user for approving workspace configurations on mainnet workspace Co-Signers or on testnet workspaces using the Fireblocks Communal API Co-Signer
• Emergency operations like freezing the workspace

Signer

A Signer can initiate transactions, sign and approve transactions, and request to add whitelisted addresses and other new connections.

Recommended responsibilities

• Signing transactions using the Console and the Fireblocks mobile app
• Signing transactions using an API Co-Signer and a Callback Handler

Approver

An Approver can approve new transactions and request to add whitelisted addresses and other new connections.

An Approver does not hold an MPC key share and cannot submit or sign transactions. However, you can define them as the second authorizer in the TAP.

Recommended responsibilities

• Approving transactions before another user signs them
• General account management

Editor

An Editor can perform view-only queries, add wallets (except for wallets associated with SPL and ASA tokens), connect exchange accounts, create new vault addresses, and cancel transactions.

An Editor can also initiate certain transactions if the TAP defines another user capable of signing as a designated signer for that transaction type.

Recommended responsibilities

• Initiating transactions using the API (can initiate all transactions except internal exchange transfers)
• Vault management using the API
• Submitting new connection requests using the API

Viewer

A Viewer has view-only privileges for all workspace activity. They cannot access settings, submit new transactions, or submit connections for approval.

Recommended responsibilities

• Read-only access to all workspace elements that are not Admin-only using the Console or the API
• Auditing workspace activity

User role access table

* = Only if you designate a signer for their transactions. Non-Signing Admins and Editors can initiate all transactions except internal exchange transfers.
** = This action must be approved by the Admin Quorum.
*** = This action must be approved by both the Admin Quorum and the Owner.
**** = These roles cannot create Algorand wallets or wallets for tokens on the Ripple, Solana, and Stellar blockchains.

User roles in Developer Sandboxes

Sandbox workspaces are freely available to sign up for. These workspaces are geared towards quick development and experimentation. Here are some of the highlights of Sandbox environments:

• When creating API users, the CSR certificate required to generate the private key is automatically created in the browser.
• Access to the Developer Area API Monitoring feature that displays the workspace's API calls and errors over 24-hour and 7-day time periods.
• No mobile signing devices are needed. With all transactions being auto-approved, this reduces the complexity of trying out the Fireblocks API.

Differences in Sandbox user roles

When creating new Console or API users in Developer Sandbox workspaces, there are only three workspace roles available:

• Non-Signing Admin
• Editor
• Viewer

In Sandbox workspaces, the Owner role is taken up by a backend service that manages auto-approvals to make experimentation and development easier. Therefore, the Non-Signing Admin replaces this role type and has the highest level of permissions, which are not present in Mainnet/Testnet workspaces, such as:

• Creating and deleting users
• Resetting 2FA for workspace users
• Signing transactions (despite the "non-signing" in the role's name)