# Transaction types

Starknet supports the following types of transactions:

• invoke transaction

• declare transaction

• deploy_account transaction

This topic describes the available fields for these transaction types and how each transaction hash is calculated.

 The deploy transaction has now been removed in the current release of Starknet. To deploy new contract instances, you can use the deploy syscall.

## Transaction versioning

Starknet supports the transaction versions described here.

When the fields that comprise a transaction change, either with the addition of a new field or the removal of an existing field, then the transaction version increases.

 Do not submit a transaction that uses an unsupported transaction type, because it cannot be included in a proof, and so cannot become part of a Starknet block.

### Deploy transaction hash calculation

In order to calculate the transaction hash, we first need to obtain the deployed contract address. The Deploy transaction’s hash is calculated as follows:

\begin{aligned} \text{deploy_tx_hash} = h( & \text{"deploy"}, \text{version}, \text{ contract_address}, \text{sn_keccak}(\text{"constructor"}), \\ & h(\text{constructor_calldata}), 0, \text{chain_id}) \end{aligned}

Where:

• The placeholder zero is used to align the hash computation for the different types of transactions.

• “deploy” and “constructor” are constant strings encoded in ASCII.

• $$h$$ is the Pedersen hash and $$sn\_keccak$$ is Starknet Keccak.

• chain_id is a constant value that specifies the network to which this transaction is sent. See Chain-Id.

• contract_address is calculated as described here.

## Invoke Transaction

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

 Invoke transaction version 0 is deprecated and will be removed in a future release of Starknet.

### Invoke v1

Table 1. Transaction fields
Name Type Description

sender_address

FieldElement

The address of the sender of this transaction.

calldata

List<FieldElement>

The arguments that are passed to the validate and execute functions.

signature

List<FieldElement>

Additional information given by the sender, used to validate the transaction.

max_fee

FieldElement

The maximum fee that the sender is willing to pay for the transaction

nonce

FieldElement

The transaction nonce.

version

FieldElement

The transaction’s version. The value is 1.
When the fields that comprise a transaction change, either with the addition of a new field or the removal of an existing field, then the transaction version increases.

### v1 hash calculation

The invoke v1 transaction hash is calculated as a hash over the given transaction elements, specifically:

\begin{aligned} \text{invoke_v1_tx_hash} = h( & \text{invoke"}, \text{version}, \text{sender_address}, 0, h(\text{calldata}), \\ & \text{max_fee}, \text{chain_id}, \text{nonce}) \end{aligned}

Where:

• $$\text{invoke}$$ is a constant prefix string, encoded in ASCII.

• The placeholder zero is used to align the hash computation for the different types of transactions.

• $$\text{chain_id}$$ is a constant value that specifies the network to which this transaction is sent. See Chain-Id.

• $$h$$ is the Pedersen hash

### Deprecated features

#### v0 hash calculation

The hash of a v0 invoke transaction is computed as follows:

\begin{aligned} \text{invoke_v0_tx_hash} = h( & \text{"invoke"}, \text{version}, \text{contract_address}, \text{entry_point_selector}, \\ & h(\text{calldata}), \text{max_fee}, \text{chain_id}) \end{aligned}

Where:

• $$\text{invoke}$$ is a constant prefix string, encoded in (ASCII).

• $$\text{chain_id}$$ is a constant value that specifies the network to which this transaction is sent. See Chain-Id.

• $$h$$ is the Pedersen hash

## Declare transaction

The declare transaction is used to introduce new classes into the state of Starknet, enabling other contracts to deploy instances of those classes or using them in a library call. For more information, see contract classes.

 Declare v0 is no longer supported. v1 used to declare Cairo 0 classes are deprecated and will be removed in a future Starknet version. New Cairo 1.0 classes can only be declared via the declare v2 transaction.

### Declare v2

Table 2. Transaction fields
Name Type Description

contract_class

ContractClass

The (Cairo 1.0) class.

compiled_class_hash

FieldElement

sender_address

FieldElement

The address of the account initiating the transaction.

max_fee

FieldElement

The maximum fee that the sender is willing to pay for the transaction.

signature

List<FieldElement>

Additional information given by the sender, used to validate the transaction.

nonce

FieldElement

The transaction nonce.

version

FieldElement

The transaction’s version. The value is 1.
When the fields that comprise a transaction change, either with the addition of a new field or the removal of an existing field, then the transaction version increases. Transaction version 0 is deprecated and will be removed in a future version of Starknet.

### v2 hash calculation

The hash of a v2 declare transaction is computed as follows:

\begin{aligned} \text{declare_v2_tx_hash} = h( & \text{"declare"}, \text{version}, \text{sender_address}, 0, \text{class_hash}, \text{max_fee}, \text{chain_id}, \\ & \text{nonce}, \text{compiled_class_hash}) \end{aligned}

Where:

• $$h$$ is the Poseidon hash function

• class_hash is the hash of the contract class. See Class Hash for details about how the hash is computed

• compiled_class_hash is the hash of the compiled class generated by the Sierra→Casm compiler which is currently used in Starknet

### Deprecated features

#### Declare v1

 These old versions used to declare Cairo 0 classes are deprecated and will be removed in a future Starknet version.
Table 3. Transaction fields
Name Type Description

contract_class

ContractClass

The class object.

sender_address

FieldElement

The address of the account initiating the transaction.

max_fee

FieldElement

The maximum fee that the sender is willing to pay for the transaction.

signature

List<FieldElement>

Additional information given by the sender, used to validate the transaction.

nonce

FieldElement

The transaction nonce.

version

FieldElement

The transaction’s version. Possible values are 1 or 0.
When the fields that comprise a transaction change, either with the addition of a new field or the removal of an existing field, then the transaction version increases. Transaction version 0 is deprecated and will be removed in a future version of Starknet.

#### v1 hash calculation

The hash of a v1 declare transaction is computed as follows:

\begin{aligned} \text{declare_v1_tx_hash} = h( & \text{"declare"}, \text{version}, \text{sender_address}, 0, \text{class_hash}, \text{max_fee}, \\ & \text{chain_id}, \text{nonce}) \end{aligned}

Where:

• $$\text{declare}$$ is a constant prefix string, encoded in ASCII.

• $$\text{class_hash}$$ is the hash of the contract class. See Class Hash for details about how the hash is computed.

• The placeholder zero is used to align the hash computation for the different types of transactions.

• $$\text{chain_id}$$ is a constant value that specifies the network to which this transaction is sent. See Chain-Id.

• $$h$$ is the Pedersen hash

#### v0 hash calculation

The hash of a v0 declare transaction is computed as follows:

\begin{aligned} \text{declare_v0_tx_hash} = h( & \text{"declare"}, \text{version}, \text{sender_address}, 0, 0, \text{max_fee}, \\ & \text{chain_id}, \text{class_hash}) \end{aligned}

Where:

• $$\text{declare}$$ is a constant prefix string, encoded in ASCII.

• The placeholder zeros are used to align the hash computation for the different types of transactions.

• $$\text{class_hash}$$ is the hash of the contract class. See Class Hash for details about how the hash is computed.

• $$\text{chain_id}$$ is a constant value that specifies the network to which this transaction is sent. See Chain-Id.

• $$h$$ is the Pedersen hash

## Deploy account transaction

Since StarkNet v0.10.1 the deploy_account transaction replaces the deploy transaction for deploying account contracts.

To use it, you should first pre-fund your would-be account address so that you could pay the transaction fee (see here for more details) . You can then send the deploy_account transaction.

A deploy_account transaction has the following fields:

Table 4. Deploy account fields
Name Type Description

class_hash

FieldElement

The hash of the desired account class.

constructor_calldata

List<FieldElement>

The arguments to the account constructor.

contract_address_salt

FieldElement

A random salt that determines the account address.

signature

List<FieldElement>

Additional information given by the sender, used to validate the transaction.

max_fee

FieldElement

The maximum fee that the sender is willing to pay for the transaction

nonce

FieldElement

The transaction nonce.

version

FieldElement

The transaction’s version. The value is 1.

### Deploy account hash calculation

The hash of a deploy_account transaction is computed as follows:

\begin{aligned} \text{deploy_account_tx_hash} = h( & \text{"deploy_account"}, \text{version}, \text{contract_address}, 0, \\ & h(\text{constructor_calldata}, \text{class_hash}, \text{contract_address_salt}), \\ & \text{max_fee}, \text{chain_id}, \text{nonce}) \end{aligned}

## Signature

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 generator used in the ECDSA algorithm is $$G=\left(g_x, g_y\right)$$ where:

$$g_x=874739451078007766457464989774322083649278607533249481151382481072868806602$$ $$g_y=152666792071518830868575557812948353041420400780739481342941381225525861407$$

## Chain-Id

Starknet currently supports three chain IDs. Chain IDs are given as numbers, representing the ASCII encoding of specific constant strings, as illustrated by the following Python snippet:

chain_id = int.from_bytes(value, byteorder="big", signed=False)

Three constants are currently used:

• SN_MAIN for Starknet’s main network.

• SN_GOERLI for Starknet’s public testnet.

• SN_GOERLI2 for Starknet developers.