Starknet v0.14.2 Prerelease Notes
Testnet – 23 Mar 2026
Mainnet – 13 Apr 2026
In-protocol proof verification
Starknet v0.14.2 enables in-protocol S-Two proof verification by implementing SNIP-36. This foundational update supports privacy-focused and zk-thread applications by allowing transactions to reference offchain execution.
New optional fields are introduced in the Invoke V3 transaction structure: proof and proof_facts fields. To support this, a new version of the get_execution_info syscall (v3) is available for contracts to retrieve these facts. While verification is currently handled by Starknet consensus, this significantly reduces the cost and calldata constraints previously associated with submitting large proofs. See SNIP-36: In-protocol proof verification for more details.
Revisiting storage access costs
Following SNIP-37, this version significantly increases storage pricing while reducing the base L2 gas price to offset this change. The update aims to align storage costs more closely with the actual resources consumed by the sequencer and the network. These changes ensure that Starknet remains cost-effective for state-intensive applications while maintaining network sustainability. See SNIP-37: Revisit storage access cost for more details.
Changes to StarkGate token contracts
The StarkGate contracts will be upgraded to version v3.0.0.
Implementing SNIP-13, the standard ERC-20 contract events for Transfer and Approval are updated to include indexed parameters. This improvement allows off-chain indexers and frontend applications to query and filter token movements more efficiently by specific addresses (e.g., from, to, or owner), bringing StarkGate’s token standards in line with widely adopted ecosystem expectations.
Note this is a breaking change, and dapps using these events should prepare in advance.
In addition, several non-breaking changes will be applied to the StarkGate tokens:
- Changing the contract into a Scarb project, allowing for the verification of its code in Voyager.
- An L1 handler function lets Starknet L1 addresses call approve, enabling the release of tokens mistakenly sent to an active L1 address.
- The bridged StarkGate USDC contract symbol changes from USDC to USDC.e after Circle’s native USDC launches on Starknet.
Further transparent changes
Version 0.14.2 brings several changes that are 100% transparent to external users and don’t change the network behaviour, and are preparations for the decentralized validation phase (SNIP 33), which is planned to be completed later this year. Examples include: improved p2p protocol between nodes, weighted sampling of the next proposer, and the creation of the internal notion of “virtual proposer” as appears in SNIP 33.
v0.14.2 Breaking Changes
SNIP-13, SNIP-36, and SNIP-37 bring breaking changes. Full details are in the SNIPs, but key changes include:
- SNIP-36 changes the block-hash calculations
- Although SNIP-37 increases maximum transaction size, a transaction valid before SNIP-37 could become too large to execute after due to higher read/write L2gas.
- Indexers using non-SNIP-13-compliant ERC-20 events must update to be compatible. Many leading Starknet ERC-20s already meet the SNIP-13 standard, so this version unifies the token standard.