Unsigned transaction formats from our API

When creating validators using POST /ethereum/validators (API Reference), Figment returns an object that contains three different formats of the same underlying transaction:

Each format exists because a different type of signer expects a different input. This page explains what each field is, why it exists, and which one you should use.

Which field should I use?

Why there are three formats

Every Ethereum transaction goes through the same lifecycle: it gets built, serialized, hashed, then signed. The three fields are snapshots of that lifecycle.

contract_call_data: the instruction to the smart contract

This is RLP-encoded data describing your call to the deposit function on Figment's batch staking smart contract. It includes all details the EVM needs to execute the smart contract portion of the transaction.

Use this if: you sign through a custodian with a dedicated "smart contract" or "DeFi" signing flow. These custodians take calldata directly, build the rest of the transaction themselves, and sign it. Fireblocks and Copper both work this way:

• Signing contract calldata with Fireblocks
• Signing contract calldata with Copper

unsigned_transaction_serialized: the full transaction

This is the RLP-encoded version of the complete transaction object, contract calldata included, plus everything else Ethereum needs to execute it (nonce, gas, value, recipient). With this field, you can fully simulate the transaction to verify exactly how it will update Ethereum's state before anyone signs.

Use this if: your signing setup wants to inspect or simulate the whole transaction first, or if you're building your own signing pipeline rather than relying on a custodian's pre-built calldata flow. This field is also required for broadcasting regardless of which field you signed.

unsigned_transaction_hashed: what actually gets signed

unsigned_transaction_hashed is the keccak hash of unsigned_transaction_serialized: a fixed 32-byte fingerprint of the full transaction. Your private key signs this fingerprint rather than the full serialized bytes, because the signing algorithm requires a fixed-length input regardless of transaction size.

When you broadcast, nodes receive unsigned_transaction_serialized and your signature. They compute the hash from the serialized transaction themselves, then check that your signature is valid against it. Any tampering in transit would produce a different hash, and the signature check would fail.

Use this if: your signer is a raw key, a wallet library, or an HSM that expects a digest to sign. This is the lowest-level option and the one you'll use if nothing upstream of you is doing transaction construction on your behalf.

Getting back to a signed transaction

Regardless of which field you signed, broadcasting requires two things combined into a signed_transaction:

1. unsigned_transaction_serialized, which tells the network what the transaction does and how it changes state.
2. The signature, your private key's signature over unsigned_transaction_hashed, which proves you consented to that exact transaction.

Those two combined form the signed_transaction for the Broadcast endpoint.

If your custodian only gives you back a bare signature, pass it alongsideunsigned_transaction_serialized to the broadcast endpoint as two separate fields and Figment will assemble them.

Frequently Asked Questions