Skip to main content
The examples on this page assume you have an initialised client, as described in Choose an interface. Raw signing is performed through the Create transaction endpoint by setting operation to RAW, and it signs a message you supply rather than building a blockchain transaction for you. For the concepts, use cases and enablement steps, see Raw signing, and for complete worked examples see Raw signing code examples.
Raw signing is an insecure signing method because bad actors can trick someone into signing a valid transaction message and use it to steal funds. It is a premium feature that is not available in production workspaces by default, so you must contact your Customer Success Manager to enable it, although Sandbox workspaces have it enabled for testing. Policies reject all raw transactions by default, so after it is enabled you must add Policy rules that allow users to initiate, approve and sign raw transactions from specific vault accounts. See Raw signing for details.

Raw signing in vault accounts

In your vault accounts you can sign raw messages for either a natively supported asset or an unsupported asset. The signing key is derived from a BIP44-like derivation path, which you pass either implicitly by giving the vault account and asset or explicitly by giving the derivation path and algorithm. To avoid creating duplicate requests when you retry, set a unique externalTxId on every request, as described in Transaction idempotency.

Natively supported asset

For a natively supported asset you provide the assetId and the source vault account, and Fireblocks derives the signing key from them. The content is the message to sign in hexadecimal format, and you omit the message type because it applies only to typed messages. You can optionally add bip44AddressIndex and bip44change to a message to set the address index and change levels of the derivation path.

Unsupported asset

For an asset that Fireblocks does not natively support, you pass the derivationPath on each message and the signing algorithm on rawMessageData instead of an assetId. The algorithm is MPC_ECDSA_SECP256K1 or MPC_EDDSA_ED25519, and for testnet assets the coin_type in the derivation path is always 1.

Raw signing in Embedded Wallets

In Embedded Wallets you can also sign raw messages for a natively supported or unsupported asset. These requests use the NCW SDK rather than the SDK, API and CLI interfaces above, so the examples are plain code blocks and each call passes the walletId in its options. For a natively supported asset, provide the assetId and the wallet account as the source.
For an unsupported asset, provide the derivationPath and algorithm instead of an assetId.

About the rawMessageData object

For the fields you can set on each message, such as preHash, which is required only in Cold Wallet workspaces, see Raw signing objects. A single raw signing request can aggregate a maximum of 127 messages.
For all request and response schemas, see the Create transaction API reference.