Skip to main content
For the former, it is important to understand the permission level of an administrator and the influence they will have with any changes made to the workspace. Please review this article for more information. For day-to-day operations, consider three key roles in the transaction process when assigning responsibilities:
  • Who will initiate transactions?
  • Who will approve transactions?
  • Who will sign off on transactions?
Once you have defined these responsibilities, review the following use cases to help you segregate duties properly: Manual Process: Typically used for operations involving a large amount of assets. This involves 100% human intervention. A transaction will be initiated via the Fireblocks console UI, approved manually by certain people (user or group) on their mobile devices, and signed by either the same people or someone else. Note that approvers are not required to have an MPC key to approve transactions. Semi-Automated Process: Used for operations that are not large in value but still significant enough to require human verification. Transactions can be initiated by a person via the UI or an API user and signed by either one of them. Fully Automated Process: Commonly used for internal transactions (between Fireblocks VA) or withdrawals of small amounts. API users initiating transactions must have the relevant permissions. If the same user is linked with the API-cosigner machine, ensure they are assigned a signer permission role.

​
Which API roles can initiate vs. sign transactions

Signing is a distinct step from initiating a transaction. A Non-Signing Admin or Editor API user can still call POST /transactions to create a transaction, provided the Transaction Authorization Policy (TAP) permits it. An Approver cannot initiate transactions, only approve them. A separate Signing API user (typically paired with an API Co-signer) then signs the initiated request based on the TAP rule. This lets you split responsibilities across API users. For example, an application server can use an Editor API key to initiate a transaction, while an API Co-signer paired with a Signer API user handles the actual signing. The TAP rule that matches the transaction ultimately controls whether a specific initiator, source, destination, and signer combination is allowed. Confirm your TAP rules include the initiator you intend to use.