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

# Dedicated Blockspace

Dedicated Blockspace is a protocol-level mechanism that guarantees mission-critical actions such as payments, tokenization, or trading always have dedicated blockspace, regardless of network congestion from NFTs, gaming, or other compute-heavy workloads.

## How Classification Works

A transaction is classified as a "Dedicated Blockspace Action" when its destination address begins with the 12-byte OGDP-20 prefix:

`Prefix: 0x20C000000000000000000000`

<Note>For standard transactions, the `to` address is checked. For AA transactions (`0x76`), every call in the batch must target an address with this prefix. If any call does not match, the entire transaction is classified as non-payment.</Note>

## Gas Budget Isolation

Each block maintains two independent gas budgets:

| Budget        | Capacity            | Purpose                                             |
| ------------- | ------------------- | --------------------------------------------------- |
| Block Total   | `block_gas_limit`   | Hard cap for all transactions.                      |
| General Space | `general_gas_limit` | Cap for non-dedicated blockspace transactions only. |

The shared space capacity (`block_gas_limit / 10`) is always available to dedicated blockspace transactions. When the general space fills up, the block builder skips non-dedicated blockspace transactions but continues including payments, tokenization, or trading.

## Use Case: Guaranteed Payments Under Load

Consider a scenario where a popular NFT mint saturates the general lane:

1. Block builder receives 500 pending transactions: 480 mint calls + 20 OGDP-20 transfers.
2. The 480 mint calls exhaust the `general_gas_limit` (30M gas).
3. The 20 payment transfers are still included using the shared lane budget.
4. Payment senders pay the base fee (20 Gwei) with no priority fee bidding required.

This means a merchant receiving stablecoin payments will never experience delays or fee spikes caused by unrelated network activity.