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.

Building the staking transaction yourself

Coming soon...

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

Serializiing 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.