Transaction Structure and Hash

Page content:

  • Deploy Transaction – Go
  • Invoke Function – Go
  • Transaction Status – Go
  • Signature – Go

StarkNet, in its Alpha version, supports two types of transactions: a Deploy transaction and an Invoke Function transaction. We describe the available fields for both of these transaction types, and how the transaction hash is calculated in both cases.

Deploy Transaction

A deploy transaction is a transaction type used to deploy contracts to StarkNet1.

A deploy transaction has the following fields:

Name Type Description
salt 256-bit number A random number used to distinguish between different instances of the contract
contract_code List of Field Element The definition of the contract itself, its byte code.
constructor_calldata List of Field Element The arguments passed to the constructor during deployment
caller_address Field Element Who invoked the deployment. Set to 0 (future: the deploying account contract).

Transaction Hash

In order to calculate the transaction hash we first need to obtain the deployed contract address.

The deploy transaction’s hash is calculated as a Pedersen hash on the relevant elements.


deploy_txn_hash := pedersen(


  1. “deploy” and “constructor” constants prefixes, encoded in bytes (ASCII), with big endian.
  2. The sn_keccak function is a keccak function, with the result masked to 250 bits.
  3. The pedersen is a pedersen hash function, applied as a hash chain on a list of elements.
  4. The chain_id is a constant value specifying the network this transaction is sent.
  5. Contract address (contract_address) is calculated as described above.


Invoke Function

The invoke function transaction is the main transaction type used to invoke contract functions in StarkNet.

An invoke function transaction has the following fields:

Name Type Description
contract_address Field Element The address of the contract invoked by this transaction.
entry_point_selector Field Element The encoding of the selector for the function invoked (the entry point in the contract)
calldata List of Field Elements The arguments passed to the invoked function.
signature List of integers Additional information given by the caller, representing the signature2 of the transaction.

Transaction Hash

The invoke function transaction hash is calculated as a hash over the given transaction elements.


invoke_txn_hash := pedersen(


  1. The pedersen is a pedersen hash function, applied as a hash chain on a list of elements.
  2. “invoke” is a constant prefix, encoded in bytes (ascii), with big endian.
  3. The chain_id is a constant value specifying the network this transaction is sent.


Transaction Receipt

The transaction receipt contains basic transaction details (containing block, transaction index within the block), summary of the execution resources used by the transaction, and list of messages sent to L1. The following is an example of a receipt:

  "execution_resources": {​​
    "builtin_instance_counter": {​​
      "pedersen_builtin": 0,
      "range_check_builtin": 0,
      "bitwise_builtin": 0,
      "output_builtin": 0,
      "ecdsa_builtin": 0,
      "ec_op_builtin": 0
    "n_steps": 178,
    "n_memory_holes": 0
  "block_number": 6807,
  "transaction_index": 0,
  "transaction_hash": "0x3f187b7522320f1c87271772fedd6ad119f62595e2d9208824367463df94a5d",
  "status": "PENDING",
  "block_hash": "0x23173d4e2d5c0ecc1376b8dbe345c028aa424048c67f68812a9a83873a2d87f",
  "l2_to_l1_messages": [],
  "events": [
      "data": [
      "from_address": "0x14acf3b7e92f97adee4d5359a7de3d673582f0ce03d33879cdbdbf03ec7fa5d",
      "keys": [


Transaction Status – Transaction Lifecycle


    • Transaction is not yet received (i.e., not written to storage.)


    • Transaction was received by the sequencer.
    • Transaction will now either execute successfully or be rejected.


    • Transaction executed successfully and entered the ‘pending’ block. 


    • Transaction executed unsuccessfully and thus was skipped (applies both to a pending and an actual created block).
    • Possible reasons for transaction rejection:
      • An assertion failed during the execution of the transaction (in StarkNet, unlike in Ethereum, transaction executions do not always succeed).
      • The block may be rejected on L1, thus changing the transaction status to REJECTED


    • Transaction passed validation and entered an actual created block on L2.


    • Transaction was accepted on-chain.



While StarkNet does not have a specific signature scheme built into the protocol, the Cairo language in which smart contracts are written does have an efficient implementation for ECDSA signature with respect to a STARK-friendly curve.

The STARK-friendly curve lives in F2p  with p=2251 + 17 · 2192 + 1 , and is defined by: 

y2= x3 + α · x + β


α= 1


And the generator used in the ECDSA algorithm is G=gx, gy where:


For more details see our repo.

1 Note, this type of transaction may be deprecated as StarkNet matures, effectively incorporating this into an invoke function transaction over an account contract which will implement the deployment as part of its functionality.

2 Or some other witness to the validity of the transaction – dependent on the implementing account contract.

<< Block Structure and Hash | Contracts >>