Signing Staking Transactions
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 ofunsigned_transaction_hash
, which is what validators verify to prove your consent of the transaction detailed inunsigned_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.
Updated 8 months ago