Starknet’s $0.12 September fee model and Cairo 2.5 paymaster

Starknet achieves high throughput and low gas costs by using STARK proofs to verify transactions on Ethereum. I find the native Account Abstraction the most effective part of the stack because it integrates directly into the Starknet OS and sequencer. This design allows the account itself to decide if a paymaster can pay for a transaction during the fee transfer phase. The sequencer enforces this at the protocol level, which differs from the ERC-4337 model where a separate EntryPoint contract calls a paymaster.

The current fee calculation relies on several variables including L1 data, computation costs, and storage operations. The cost depends on the amount of data sent to L1, specifically state diff information and the number of L2 to L1 messages. Computation costs include the count of trace steps, L1 proof verification, and L2 computation costs. The formula for the fee uses the gas price, the number of messages, the bytes per message, and the gas per step.

The current fee structure uses ETH as the payment currency, though the development team plans to transition to STRK. You already know that gas fees often block mainstream adoption, so the protocol handles the fee conversion if the paymaster supports it. The sequencer deducts the fee directly from the paymaster’s fee token balance. If the paymaster lacks sufficient funds, the entire transaction reverts.

Cairo 2.5 and the Paymaster advantage

The Cairo 2.5 paymaster overhaul provides a tighter integration than the modular ERC-4337 approach. In the ERC-4337 model, the paymaster is a separate contract, and the account’s validateUserOp and the paymaster’s validatePaymasterUserOp function act as distinct, sequential steps. Starknet avoids this fragmentation by making paymaster logic an intrinsic part of the account contract’s validate entry point. This integration helps reduce the gas overhead that often plagues EVM-based account abstraction.

The technical differences between these models result in different trust assumptions and workflows.

While the native model simplifies development, it relies heavily on the sequencer to correctly invoke the fee transfer logic. If a malicious or buggy account contract fails to pay fees, the sequencer can reject the transaction before execution. I see this as a minor risk compared to the risk in ERC-4337, where a buggy paymaster can drain user funds or cause transaction failures. Does the reliance on a single sequencer limit the censorship resistance of these sponsored transactions?

Scaling the network and STRK utility

Starknet continues to iterate through version updates like 0.14.0 and 0.15 to improve efficiency. The version 0.15 update, scheduled for September 2026, includes decentralized validation of blocks and provides an additional 2x increase in throughput. The roadmap shows a move toward reducing L1 finality, with version 0.14.2 aiming for 3 hour finality and version 0.15 targeting 1.5 hours.

The STRK token plays several roles in the ecosystem, including paying transaction fees and enabling participation in governance. The token provides new business use cases on the network and facilitates decentralization through staking.

The price of STRK shows significant movement, with a current price of $0.0485 and a market capitalization of $356,331,000. In September 2025, the price reached a high of $0.196. Analysts have projected different paths for the asset, with some expecting a minimum price of $0.146 in 2026 and others forecasting much higher values. The network relies on these economic incentives to attract the builders necessary for long-term growth.