Skip to main content
The blockchain’s state is the complete snapshot of all accounts, balances, and smart contract data at a given block height. OpenGDP manages this state using the standard Ethereum account model (nonce, balance, code, storage) but extends the block header and introduces a reserved address space for protocol logic.

Header Extensions

To support the dual-layer fee market and sub-second finality, the OpenGDP block header includes three custom fields:
  • shared_gas_limit: The gas capacity strictly reserved for the dedicated blockspace. This ensures that a portion of every block is always available for mission-critical actions such as payments, tokenization, or trading, regardless of congestion in the general blockspace.
  • general_gas_limit: The hard cap for non-dedicated blockspace transactions (e.g., NFTs, Gaming).
  • timestamp_millis_part: A millisecond-precision timestamp field that allows for sub-second block times and more accurate time-based logic.

Precompile Address Space

OpenGDP implements core protocol logic such as the Fee Manager and Stablecoin Orderbook as “precompiles.” These are special smart contracts at fixed addresses that run native Rust code for maximum performance, rather than EVM bytecode.
NameAddressDescription
Fee Manager0xfeec...0000Manages fee token preferences and executes the logic for collecting fees in stablecoins.
Stablecoin Orderbook0xdec0...0000A native, high-performance orderbook for swapping assets, beginning with stablecoins.
path(currency)0x20C0...0000The default protocol fee token and the root for routing stablecoin swaps across currencies such as USD, EUR, and more.
Policy Registry0x403C...0000Enforces compliance policies (e.g., KYC/AML) for regulated tokens.
Token Factory0x20FC...0000A factory for deploying standardized OGDP-20 tokens.
Validator Config0xCCCC...0000Stores validator-specific settings and preferences.
Account Keychain0xAAAA...0000Manages multi-key authentication state for advanced account security.
Nonce Manager0x4E4F...0000Handles 2D nonces and expiring nonces for replay protection.

Protocol State

Beyond standard account storage, the protocol maintains specialized state trees for its unique features:
  • Fee State: Tracks which token each user wants to pay with, and which token each validator wants to receive. It also manages the “Fee AMM” pools that automatically swap between these tokens.
  • Orderbook State: Stores the onchain order books (keyed by pair hash) and internal user balances for high-frequency trading on the native orderbook.
  • System State: Manages the “End-of-Block” system transaction. Every block must contain exactly one system transaction (targeting Address::ZERO) that seals the block and aggregates metadata from all sub-blocks.