Unsigned transaction formats from our API

When creating validators using POST /ethereum/validators (API Ref) you will get the following object:

What you will sign depends on your signing implementation.

Signing the contract calldata

contract_call_data is RLP-encoded data representing your call to the deposit function on our batch staking smart contract. It includes all details the EVM needs to execute the smart contract portion of the transaction.

Custodians have API endpoints that will accept this field and sign it.

Signing the full serialized transaction

unsigned_transaction_serialized is the RLP-encoded version of the full transaction object with all the details (including the contract calldata) to fully simulate the transaction and understand how the transaction will update Ethereum's global state.

Signing the hashed transaction

unsigned_transaction_hashed is the keccak hash of unsigned_transaction_serialized, and is the actual payload signed by your private key to allow RPC nodes to verify that you consent to your transaction.

What to pass back for broadcasting

Broadcasting an Ethereum transaction requires two pieces of data to be serialized together:

unsigned_transaction_serialized, so Ethereum knows what code to execute and how to update state.
signature, which is your private key's signature of unsigned_transaction_hash , which is what validators verify to prove your consent of the transaction detailed in unsigned_transaction_serialized

Serializing these above is what we accept as signed_transaction in our Broadcast Endpoint. If your custodian or signing service only returns a signature, then pass the signature and unsigned_transaction_serialized separately to the endpoint instead.

Frequently Asked Questions

Does signing require a BLS private key on the BLS12-381 curve?

No. Figment manages the BLS signing key for consensus-layer validator operations (attestations, block proposals). What you sign is a standard ECDSA secp256k1 Ethereum execution-layer transaction — the same signing you do for any ETH transfer or smart-contract call. Your regular Ethereum wallet key handles this.

What are the exact objects to sign and broadcast?

There are two primary ways to sign:

Hash Signing

Sign unsigned_transaction_hashed with your private key. Combine the resulting signature with unsigned_transaction_serialized to create a signed_transaction for broadcast. Alternatively, pass signature and unsigned_transaction_serialized separately to the Broadcast endpoint.

Contract-Call Signing

Pass contract_call_data to your custodian or wallet to construct and sign the transaction. This is the standard approach for custodians like Fireblocks and Copper.

Direct On-Chain Deposit (Optional)

Extract deposit_data from the API response and call the on-chain deposit contract directly, bypassing the Figment broadcast endpoint. Use this if you manage your own transaction construction.

Do I need to sign each staking/unstaking transaction, or only once during validator creation?

Every transaction that moves ETH requires a signature. This includes the initial deposit (funding the validator), compound top-ups, partial withdrawals, consolidation transactions, and execution-layer exits. Each one is a separate on-chain transaction that needs to be signed.