You can get the latest updates delivered to your inbox by subscribing to the Starknet Devs Newsletter.
Starknet v0.14.1 (TBD)
Starknet v0.14.1 is scheduled to arrive on Testnet in Oct 27’thThis version includes the following changes:
- Prover optimization: compiled class hashes will now be computed with the Blake hash function rather than Poseidon. With Stwo, blake2s is roughly 8x more efficient to prove compared to large field Poseidon.
Given that compiled class hashes are the heaviest hash consumer during the OS execution, it is our first step in the process of migration to a Stwo-friendly hash.
- Declare transactions will now expect
compiled_class_hashto be computed with the new hash function, and will be rejected otherwise - Gradually, existing classes in the state commitment will migrate to the new computation.
For every successful (i.e. non-reverted) transaction, the classes used throughout the transaction will be updated in the
class_hash→compiled_class_hashtrie. - The changes in compiled class hashes will be applied at the end of the block. Note that the execution environment is unaware of compiled class hashes (system calls only specify class hash, never compiled class hash), thus these changes will not affect execution, only the resulting state root.
- The feeder gateway will add such classes whose compiled class hash was updated to the
get_state_updateresponse, under a new field calledmigrated_compiled_classes
- Declare transactions will now expect
- Starknet JSON-RPC v0.10.0: you can find the first release candidate along with a summary of changes in the starknet-specs repository.
Starknet v0.14.0 (September 1, '25)
Starknet v0.14.0 is live on Testnet and scheduled to be live on Mainnet on September 1st.This version includes the following changes:
- Block time is shorten from ~30 seconds to ~6 seconds
- Decentralized sequencing is introduced, with three sequencers, each with its own mempool, taking turns building blocks and reaching consensus using the Tendermint protocol (the interfaces for submitting transactions to the gateway and syncing from the feeder gateway remain unchanged)
- v0, v1, v2 and non-RPC v0.8 compatible v3 transactions are no longer supported, and a new
meta_tx_v0syscall is introduced to enable calling old accounts (i.e., ones without__validate__) via v3 transactions - RPC v0.9 is introduced, removing the
REJECTEDtransaction status, changing the behavior of theRECEIVEDtransaction status, adding newCANDIDATEandPRE_CONFIRMEDtransaction statuses, and introducing thePRE_CONFIRMEDblock - The feeder gateway URL is now
feeder.{chain_name}.starknet.io/feeder_gateway(while the gateway URL remains{chain_name}.starknet.io/gateway), adding a newget_preconfirmed_blockendpoint, deprecating theget_oldest_transaction_ageandget_number_of_transactions_in_backlogendpoints, and changing the behavior of theget_transaction_statusendpoint - L1 handlers execution resources are bounded and failed L1 handlers are included as
REVERTEDin blocks - A fee market on the
l2_gasresource is introduced, following Ethereum’s EIP 1559 - Sequencers now maintain a mempool, decoupling the transaction order of arrival from the transaction ordering in blocks
- The Starknet OS (SNOS) has been modified to receive multiple blocks as inputs, amortizing costs over a larger number of blocks
- Transactions with internal calls to an entry point called
__execute__are now reverted
Starknet v0.13.6 (July 8, '25)
Starknet v0.13.6 is live on Mainnet.This version is a configuration change done to support integration by the S-Two prover, including:Additional resources:
- Introducing builtin tracking and temporarily disabling Cairo Native: The Starknet OS now tracks individual builtins usages, capping the number of builtins that may fit inside each block. Since Cairo Native does currently not support this kind of tracking, its usage is temporarily disabled and will be enabled again once this capability is supported.
- Reducing maximum block size: The amount of L2 gas that a block can contain is decreased from 5B to 4B L2 gas.
Cairo Native hasn’t yet been enabled on Mainnet, and disabling it only affects Sepolia.
Starknet v0.13.4 and v0.13.5 (March 24, '25)
Starknet v0.13.4 and v0.13.5 are live on Mainnet. All the big improvements came in v0.13.4, and the v0.13.5 upgrade rolled out immediately after, bringing minor adjustments to help the ecosystem gear up for Starknet’s next upgrade.Starknet v0.13.4 includes the following changes:
- Cairo Native Execution: Contracts compiled with Sierra ≥ 1.7.0 can run faster by being executed natively (without the Cairo VM)
- L2 Gas Introduced: New fee type for L2-specific resources (computation, calldata, events)
- Triple Gas Model: Transactions now support (and eventually require) bounds for L1 gas, L2 gas, and blob gas
- Improved Error Handling: Contract panics no longer abort execution and instead return control to the caller
- Stateful Compression: Smaller L1 blobs via smart key indexing to reduce data availability costs
- New Wallet<>Dapp API: Decouples dApps from specific Starknet.js versions using a new
WalletAccountclass - JSON-RPC v0.8.0: Adds WebSocket support, better fee/resource tracking, and new endpoints
- New Compiler (Cairo v2.10.0): Enables
redeposit_gas, reduces worst-case fees, adds new syscalls - Updated Pricing: Builtins priced by trace complexity, often cheaper for users
Starknet v0.13.3 (November 20, '24)
Blob gas on Starknet is now 5x cheaper (!) using:
- Squashing discount factor: Users pay for the expected marginal contribution of their transaction to the blobs sent to L1
- State diff compression: Starknet submits compressed state diffs to L1. To better lends itself to the new compression scheme as well as allow its construction to be based on the state diff alone, the uncompressed encoding of contract diff headers changes to: new_nonce (if changed) | n_updates | n_updates_len | flag
- The semantics of
flagis unchanged (i.e., it indicates whether or not the class was replaced) n_updates_lenis 0 if the number of updates is less than 256 (and therefore can fit in 8 bits), and 1 otherwisen_updatescan spread over 8 or 64 bits, depending onn_updates_len- If the nonce of the contract is unchanged, the value of
new_nonceis zero (and not the unchanged nonce)
Starknet v0.13.2 (August 28, '24)
New features and enhancements:
- Optimistic parallelization in the sequencer.
- Applicative recursion (“blockpacking”): pack a contiguous sequence of blocks into a single L1 state update, instead of just one block. This change also affects the Starknet core contract on L1 and the structure of data availability.
- New block hash definition: see the reference implementation here.
- Feeder gateway: All objects containing the block hash will use the new block hash computation. Receipts will contain a new property
total_gas_consumed, only for transactions after v0.13.2. Three new builtins can appear in thebuiltin_instance_counterproperty ofexecution_resourcesin the transaction receipts:add_mod,mul_modandrange_check96. End support for the endpointsget_block_tracesandget_transaction_trace. - JSON RPC: No changes in v0.13.2. The new JSON RPC version v0.8.0 will be released alongside Starknet v0.13.3.
Starknet v0.13.1.1 (April 15, '24)
In response to community feedback, Starknet 0.13.1.1 reduces class declaration fees and increases the calldata limit:Fee reductions:
- CASM bytecode: 28 gas/felt → 1 gas/felt
- Sierra bytecode: 28 gas/felt → 1 gas/felt
- ABI: 0.875 gas/character → 0.032 gas/character
- Calldata length: 4,000 felts → 5,000 felts
Starknet v0.13.1 (March 13, '24)
New features and enhancements:
- Cheaper data availability (DA): Starknet uses EIP-4844. State diffs are now blobs, rather than calldata, requiring the addition of
data_gasto the Starknet block header. - Time-related syscalls when called from an account contract’s
__validate__,__validate_deploy__,__validate_declare__, orconstructorfunction:block_timestampreturns the hour, rounded down.block_numberreturns the block number, rounded down to the nearest multiple of 100. - Optimization: Load into memory only the functions in a contract that are actually used when generating the proof.
l1_da_mode, l1_data_gas_price, and l1_gas_price.API: JSON RPC:
Starknet 0.13.1 is backward compatible with starknet_api_openrpc.json v0.6.0. A new version 0.7.0 accommodates the changes introduced by Starknet using EIP-4844.Pricing changes:- Computation: A Cairo step now costs 0.0025 gas/step, a 50% reduction. All builtins costs are accordingly reduced by 50%.
- Calldata and signatures: Each felt in the calldata and signature arrays of all transaction types now costs 0.128 gas/felt.
- Class declaration: Each felt of a sierra_program and bytecode now costs 28 gas/felt. Each character in the ABI costs 0.875 gas.
- Events: An additional felt to the data array costs 0.128 gas/felt. An additional felt to the keys array costs 0.256 gas/felt.
Starknet v0.13.0 (January 10, '24)
Starknet v0.13.0 is live on Mainnet.Starknet 0.13.0 includes the following changes:
- v3 transactions, including fee payment in STRK and reserved fields for future features, such as Volition and payment master
get_blockAPI: Thegas_pricefield is replaced by theeth_l1_gas_priceandstrk_l1_gas_pricefields. This change applies also to existing blocks. For more information on the new fields, see the JSON RPC API Spec on GitHub- Sierra v1.4.0. This new version of Sierra is part of Crate v2.4.0, in the Cairo 2.4.0 package. For more information, see Cairo v2.4.0 is out! on the Community forum.
- Improved performance of
secp256k1_mulandsecp256r1_mulsyscalls - Computation cost is reduced by approximately 50% as a result of reduced Cairo steps and increased use of builtins. L1 data availability cost is reduced by approximately 10%-25%. For an ERC-20 transfer, the DA fee reduction is 25%.
Starknet v0.12.3 (November 19, '23)
Starknet v0.12.3 is live on Mainnet.This release partially removes support for the Starknet feeder gateway. For details, see Feeder Gateway Deprecation in Development Proposals on the Starknet community forum.Additionally, this version includes the following changes:
- Performance optimizations in the gateway, the computation of the Patricia storage root, and block hash
- Support for
secp256r1syscalls in the Starknet OS. - Restriction for
__validate__and the constructor ofDeployAccounttransactions: Restrict access tosequencer_addressin theget_execution_infosyscall by returning0’s for the address. Restrict access to the following syscalls: Cairo contracts:get_block_hash, Cairo 0 contracts:get_sequencer_address
Starknet v0.12.2 (September 04, '23)
Starknet v0.12.2 is live on Mainnet.This version includes the following changes:
- Enabling P2P Authentication: An additional endpoint in the sequencer gateway to provide a signature on the state diff commitment and block hash.
- Resolving Mismatches in Queries: An extension to the
get_state_updateendpoint in the sequencer gateway that returns both the pending state diff and the pending block together. - Increased maximum Cairo steps per transaction from 1 million to 3 million.
Starknet v0.12.1 (August 21, '23)
Starknet v0.12.1 is live on Mainnet.This version includes the following changes:
- Mempool Validation.
- Inclusion of Failed Transactions.
- Keccak builtin.
Starknet v0.12.0 (July 12, '23)
Starknet v0.12.0 is live on Mainnet.This version contains the following changes:
- Use the rust blockifier and LambdaClass’s Cairo VM to accelerate the sequencer’s time to handle transactions.
- Support version 2.0.0 of the Cairo compiler.
- Replace the
PENDINGstatus of transactions toACCEPTED_ON_L2- once a transaction is in that status it means that it will be included in a block, this applies to transactions - blocks still have thePENDINGstatus. - Add an experimental
get_block_hashsyscall. - Change HTTP error code from 500 to 400 on API errors.
Starknet v0.11.2 (May 31, '23)
Starknet v0.11.2 is live on Mainnet.This version contains the following changes:
- Upgrade Cairo 1.0 version to v1.0.0-rc0 (Cairo 1.0 activated on Starknet!)
Starknet v0.11.1 (May 23, '23)
Starknet v0.11.1 is live on Mainnet.This version contains the following changes:
- Upgrade Cairo 1.0 version to v1.0.0-rc0.
- Charged transaction fee is now based on an average Ethereum gas price instead of a single sample (estimation API is unaffected).
- API changes: Remove the state root in
get_state_updatefor pending blocks to allow faster responses in future versions. - Testing framework: Allow declaring (and interacting with) Cairo 1.0 contracts. Split
deploy()to two phases declare and deploy:deprecated_declare()(for Cairo 0 contract) ordeclare()(for Cairo 1.0 contracts) anddeploy()(for both). - Add current block hash to the Starknet Core Contract (currently not verified by the Starknet OS): Breaking change: The
LogStateUpdateevent’s data is changed to include blockHash.
Starknet v0.11.0 (March 29, '23)
Starknet v0.11.0 is live on Mainnet.In Starknet v0.11.0, you can declare, deploy and run Cairo 1.0 smart contracts. We also introduce a new system call that allows a smooth transitioning of existing contracts to a Cairo 1.0 implementation.Historically, contract classes have been defined in terms of Cairo assembly, or Casm for short (the class definition also included more information needed for execution, e.g., hint data). The novelty of Cairo 1.0 is the introduction of Sierra (Safe Intermediate Representation), an intermediate layer between Cairo 1.0 and Casm.The introduction of Cairo 1.0 and Sierra has several effects on the system. Below we list the effects on each component; of particular note are:
- A new version of the
declaretransaction, which allows sending the new class structure - The state commitment will now include contract classes
- Changes to the onchain data format
- New system call -
replace_class
Starknet v0.10.3 (December 12, '22)
The
deploy transaction is no longer supported on this version.- Performance - Separate the state commitment computation from the execution of the transactions
- Add
starknet-class-hashcommand to compute the class hash of a compiled Starknet contract
- Autoformatter: Automatically break lines inside expressions
Starknet v0.10.2 (November 29, '22)
- This version introduces sequencer parallelization! This is the first step in our roadmap of performance upgrades. Details about the specific mechanism of parallelization and the roadmap in general are described in this medium post.
- A new endpoint,
estimate_fee_bulk, is added to the feeder gateway. This will allow estimating the fee of several transactions at once, where each transaction is executed relative to the resulting state from applying the previous one. - Sequencing performance improvements
- Builtin ratio changes, which affects builtin costs
- Add
estimate_fee_bulkAPI that computes the fee of multiple transactions that will be executed consecutively
Starknet v0.10.1 (October 25, '22)
This version contains the following changes:Starknet:
- Add
DeployAccounttransaction (which will replace the Deploy transaction for deploying account contracts). To use it, you should first add enough funds to your account address to pay the transaction fee, and then you can invoke DeployAccount - Split the
starknet deploy_accountCLI command intostarknet new_accountandstarknet deploy_account - Account contracts that are expected to be deployed this way should implement the
__validate_deploy__()entry point, which should check the signature of theDeployAccounttransaction - Improve L1 fee computation: the fee is computed according to the diff of the storage state
- API: Remove
entry_point_typefield from transaction information
- Add
uint256_mul_div_modtouint256.cairo
Starknet v0.10.0 (September 05, '22)
This version introduces the next step in Starknet’s account abstraction design, specifically the validate/execute separation. See here for more information.This version contains the following changes:Starknet:
- Contract (breaking changes): @external and @view functions should be imported directly by the main compiled file. Otherwise, they will not be usable as external functions. Forbid using the same storage variable name in two modules
- New transaction version (version 1) for
invokeanddeclaretransactions: Transactions of version 0 are deprecated and will not be supported in Starknet from the next version (v0.11.0). Please update your systems to use the new version
In order to use transactions of version 1 you will need to upgrade your account contracts
- Add nonce field to the transactions. Nonce validation is now part of the Starknet protocol and is enforced to be executed sequentially
Invoke: Split__execute__to two functions:__validate__(only validates the transaction) and__execute__(only executes the transaction). Remove the selector (which is now always__execute__) field, following the above change.- Declare:
declaretransaction should now be sent from an account (and is validated using__validate_declare__in the account contract) - Support fee for sending L1 messages. At this point, it’s not mandatory and messages with no fee will still be handled. Starting from the next version it will become mandatory.
-i flag to apply the changes to the files. End statements with ;. Use { … } for code blocks (instead of : and end). Add () around the condition of if statements. Remove the member keyword in structs. Change comment to use // instead of #. Use ..., ap++ instead of ...; ap++ in low level Cairo code. Support return types that are not tuples. Return statement accepts expressions, rather than only tuples. Support using functions as expressions. Fix a bug in the secp signature verification code. Add Cairo code for the recursive STARK verifier.Technical changes:- Move from python3.7 to python3.9
Starknet v0.9.1 (July 20, '22)
This version contains the following changes:Starknet:API changes:
- Add
get_block_tracesAPI - returns all the transaction traces of a given block - Add a list of declared contracts in
get_state_update - Add a 0x prefix for class hash in the API
- Add
starknet_versionfield for blocks (only applies to new blocks)
- Change the default block number to pending
- Using a wallet is the default,
--no_walletmust be specified explicitly to override this - Deploying contracts: Add
deploy_contractfunction to the account contract created bystarknet deploy_account. Use this function to deploy contract (unless using--no_wallet). In particular,deployshould be used after declaring the contract (it expects the contract class hash) - Support
--dry_runto get the transaction information without signing or sending it - Support
deploy_from_zeroin thedeploysyscall to deploy a contract to an address that does not depend on the deployer
- Support and in if statements (
if x == y and z == w).
At the moment other boolean combinations are not supported
Starknet v0.9.0 (June 06, '22)
This version introduces the contract class/instance paradigm into Starknet. See here for more information.This version contains the following changes:Starknet:
- Enforce fees -
max_feemust not be set to zero, and selector must be__execute__ - Split the concepts of contract class and contract instance.
- Add
declaretransaction type - New API and CLI commands:
declare- Declares a contract class.get_class_by_hash- Returns the contract class given its hash.get_class_hash_at- Returns the class hash for a given contract instance address - Rename
delegate_calltolibrary_call, and change the contract address argument to class hash. - Add a
deploysystem call. - Rename
ContractDefinitiontoContractClass - Reduce the compiled contract file’s size by removing unnecessary identifiers (this optimization can be disabled using
--dont_filter_identifiers)
- Initial support for the
EC-opbuiltin (scalar multiplication over the STARK curve). Not supported in Starknet yet. - Add additional helper methods to
blake2s.cairo, including big-endian support
- Change function’s
returntype from a struct to a named tuple. In particular,foo.Return.SIZEis no longer supported.