Your workspace Owner assigns workspace roles to both Fireblocks Console and API users during User Setup. Follow the steps in the user setup article (steps for both the Owner and new user) and adding new Console users (steps for article.
Your Owner assigns a role to users at the beginning of User Setup and they must verify that the setup process goes all the way through and is approved by your workspace's Admin Quorum.
For additional information about a specific role's capabilities, refer to the user role access table.
Learn more about best practices for choosing user roles.
Note
For added users in roles that will have transaction signing privileges (Admins and SIgners), an MPC Key share must be approved for their device during User Setup. Otherwise, transaction signing operations created by them may fail.
Owners or Admins can track the status of an Admin or Signer user's MPC key share approval by selecting Settings → Users in their Fireblocks Console. In the Status column, you can see which user setup step is the current status, including one step called Pending Owner MPC Key Approval.
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 purposes, 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
Non-Signing Admin
A Non-Signing Admin can approve transactions and perform administrative operations: approve new whitelisted addresses, new exchange accounts, and new Fireblocks Network connections, and can add 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 also initiate 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
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, request to add wallets, connect exchange accounts, create new vault addresses, and cancel transactions.
An Editor can also initiate 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
- 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
| Does this role... | Owner | Admin | Non-Signing Admin | Signer | Approver | Editor | Viewer |
| Provision MPC signing keys | Yes | No | No | No | No | No | No |
| Delete user | Yes | No | No | No | No | No | No |
| Reset 2FA | Yes | No | No | No | No | No | No |
| Freeze transactions | Yes | Yes | Yes | No | No | No | No |
| View all workspace settings | Yes | Yes | Yes | No | No | No | No |
| Add or manage workspace users | Yes | Yes | Yes | No | No | No | No |
| View all workspace users | Yes | Yes | Yes | No | No | No | No |
| Export transaction history | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Require the Fireblocks mobile app | Yes | Yes | Yes | Yes | Yes | No | No |
| Initiate transactions | Yes | Yes | Yes * | Yes | No | Yes * | No |
| Cancel transactions | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Approve transactions | Yes | Yes | Yes | Yes | Yes | No | No |
| Sign transactions | Yes | Yes | No | Yes | No | No | No |
| Create vault accounts | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Rename vault accounts | Yes | Yes | Yes | Yes | Yes | No | No |
| Add asset wallet to a vault account or whitelisted wallet | Yes | Yes | Yes | Yes | No | No | No |
| Add or approve a new ERC-20 asset | Yes | Yes | Yes | No | No | No | No |
| View or retrieve vault public keys via API | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Add/whitelist a new destination (Network, exchange, fiat whitelisted wallet) | Yes ** | Yes ** | Yes ** | Yes ** | Yes ** | Yes ** | No |
| Participate in the Admin Quorum | No | Yes ** | Yes ** | No | No | No | No |
| Re-enroll devices | Yes ** | Yes ** | Yes ** | No | No | No | No |
| Add Console/API users | Yes *** | Yes *** | Yes *** | No | No | No | No |
| Approve workspace policies, TAP changes | Yes *** | Yes *** | Yes *** | No | No | No | No |
| Enable one-time addresses | Yes *** | Yes *** | Yes *** | No | No | No | No |
| Change the Admin Quorum | Yes *** | Yes *** | Yes *** | No | No | No | No |
* = Only if you designate a signer for their transactions.
** = This action must be approved by the Admin Quorum.
*** = This action must be approved by both the Admin Quorum and the Owner.
**** = Editors can only add asset wallets that can be approved via your TAP. For example, Solana SPL token wallets require on-chain transactions and can't be approved via TAP, so they can't add them.