Skip to main content
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.
EIP-4844 (Blob transactions) is explicitly rejected to maintain a streamlined state model focused on payments.

​
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.
For Account Abstraction (AA) transactions, every call in the batch must match this prefix to be classified as a payment.

​
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.