> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opengdp.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Transaction Lifecycle

The lifecycle of an OpenGDP transaction involves specialized validation and execution steps to support fee abstraction (paying gas in stablecoins) and dedicated blockspace.

## 1. Submission

Transactions are submitted via standard JSON-RPC methods. OpenGDP supports a wide range of transaction types to ensure compatibility while enabling new features:

* **Standard EVM**: Legacy (`0x00`), EIP-2930 (`0x01`), EIP-1559 (`0x02`), and EIP-7702 (`0x04`).
* **OpenGDP Specific**:
  * **AA Transaction (`0x76`)**: Enables native Account Abstraction features like batch calls and sponsored fees.
  * **Encrypted Transaction (`0x4a`)**: Allows for encrypted calldata, protecting transaction intent until inclusion.

<Note>EIP-4844 (Blob transactions) is explicitly rejected to maintain a streamlined state model focused on payments.</Note>

## 2. Mempool Validation

Before a transaction enters the mempool, it undergoes rigorous checks:

* **Value Check**: Native value transfer (`value != 0`) is rejected. All value transfers must happen via OGDP-20 tokens.
* **Fee Token**: The system verifies that the chosen fee token is a valid, unpaused, currency-denominated OGDP-20 token.
* **Solvency**: The fee payer must have a sufficient balance to cover the maximum possible gas cost.
* **Nonce**: Validity is checked against the 2D nonce system or the expiring nonce window (max 30s).

## 3. Dedicated Blockspace Action Classification

This is a critical step for the "Dedicated Blockspace" feature. The protocol inspects the destination address:

* **Dedicated Blockspace Action**: If the address starts with the OGDP-20 prefix (`0x20C0...`), the transaction is classified as a payment.
* **Non-Payment**: All other transactions.

<Note>For Account Abstraction (AA) transactions, every call in the batch must match this prefix to be classified as a payment.</Note>

## 4. Fee Token Resolution

Since users can pay in any supported stablecoin, the protocol must determine which token to charge. It resolves this in a deterministic order:

1. Explicit `feeToken` field (if provided).
2. Immediate `setUserToken` call (if the user is updating their preference in this tx).
3. Stored user preference (from on-chain state).
4. Inferred from the contract being called (e.g., a `transfer` call on USDC implies USDC fees).
5. Inferred from orderbook swap inputs.

## 5. Execution

Execution follows a "Pre-charge / Settlement" model:

* **Pre-charge**: The maximum possible fee is deducted from the user's balance.
* **Execution**: The transaction runs.
* **Settlement**: The actual gas cost is calculated. Unused gas is refunded. If the validator prefers a different token than the user paid, an atomic swap is executed via the Fee AMM.

## 6. Block Finalization

Finally, the block is sealed with a system transaction that aggregates signatures and metadata from all sub-blocks, ensuring the entire block is cryptographically verifiable.