# Proposing Evolutionary Changes in Starknet Transaction Structure: A Comprehensive Overview

By [Argon](https://paragraph.com/@argonstark) · 2023-11-23

---

**Introduction**
----------------

Starknet, in its pursuit of continuous improvement, is proposing a significant shift in its transaction structure through Starknet Improvement Proposal (SNIP). The primary objective is to accommodate future API and protocol changes seamlessly, laying the foundation for the integration of a fee market, Volition, Paymaster, and Nonce generalization.

**Motivation**
--------------

The driving force behind SNIP lies in the ambition to minimize disruptive alterations to the Starknet transaction structure. This proposal introduces a new transaction version capable of supporting upcoming API and protocol modifications, with a focus on five major changes anticipated in the near future:

1.  **Fee Market:** Implementing a mechanism to enable users to utilize the network efficiently, even during congestion.
    
2.  **Volition:** Introducing a hybris state design that allows users to choose their preferred data availability mode.
    
3.  **Paymaster:** Enriching the protocol with fee abstraction, allowing entities other than the transaction sender to cover transaction fees.
    
4.  **Nonce Generalization:** Supporting semi-nonce abstraction, providing users with flexibility in specifying channels for transactions, fostering parallelism.
    
5.  **Account Deployment in First Transaction:** Introducing an account deployment data field in Invoke and Declare transactions, eliminating the need for a separate transaction to deploy an account.
    

**Specification:** The proposal outlines three new transaction structures along with their corresponding fields, categorized into common, fee-related, Volition-related, Paymaster-related, and specific fields for Invoke, Declare, and DeployAccount transactions. The comprehensive specifications include API changes, common fields, and a detailed breakdown of specific fields for each transaction type.

**Protocol Changes:** Defining common transaction fields and their hash calculation methods, the proposal ensures compatibility and smooth evolution of Starknet. The introduction of a constant chain\_id and specific transaction hash calculation methods for Invoke, Declare, and DeployAccount transactions enhances clarity and consistency.

**System Calls Changes:** The update to the `get_execution_info` syscall ensures compatibility with both old and new transaction versions. It introduces a new struct, `TxInfo`, containing essential information for v3 transactions, maintaining backward compatibility by preserving existing fields.

**Backward Compatibility:** Acknowledging the importance of continuity, Starknet commits to providing support for older transaction versions during a transition phase. However, it emphasizes that the older version will not access new features like the Fee market, Volition, and Paymaster once implemented on Starknet.

**Conclusion**
--------------

In proposing these evolutionary changes, Starknet aims to usher in a new era of flexibility, efficiency, and compatibility. By carefully considering future developments and addressing the need for minimal disruption, this SNIP lays the groundwork for a robust and adaptable Starknet ecosystem.

---

*Originally published on [Argon](https://paragraph.com/@argonstark/proposing-evolutionary-changes-in-starknet-transaction-structure-a-comprehensive-overview)*