> For the complete documentation index, see [llms.txt](https://docs.ethgas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ethgas.com/overview/institutional-blockspace.md). # Institutional Blockspace Institutional Blockspace is ETHGas's framework for delivering Ethereum blockspace that meets the compliance, transparency, and settlement-certainty requirements of regulated institutions - without sacrificing Ethereum's credible neutrality. It combines a configurable **Policy Engine**, **fair ordering** guarantees, and a network of **known, onshore, qualified validators** so that banks, asset managers, and protocol treasuries can transact onchain with the assurances their mandates require. ### Why this exists Most institutions cannot use Ethereum's default transaction pipeline as-is. Public mempools expose orders before they settle, block ordering is opaque, and there is no way to know which parties assembled a block or whether it complies with an institution's regulatory obligations. For a regulated desk, that is a non-starter. ETHGas closes that gap. By letting institutions **reserve blockspace in advance** and route it through a policy-governed, transparent build process, we turn Ethereum's public infrastructure into something an institution can actually underwrite: predictable inclusion, auditable ordering, and counterparties that are known rather than anonymous. ### The building blocks #### Policy Engine A configurable rules layer applied to blockspace an institution reserves. Institutions (or the validators serving them) can define policies — for example, screening against sanctions lists, restricting counterparties, or enforcing jurisdictional constraints — and have those policies enforced at build time rather than after settlement. #### Fair ordering Guarantees about how transactions inside reserved blockspace are sequenced, removing the opaque, MEV-driven reordering that institutions cannot audit or explain to a regulator. Ordering becomes a property the buyer can rely on and evidence. #### Known & onshore validators A curated set of validators that are identity-verified, operate in supported jurisdictions ("onshore"), and meet defined operational and compliance standards. Institutions can require that their blockspace is served only by validators in this qualified set. #### Settlement certainty Because blockspace is reserved ahead of time via ETHGas's Blockspace & Preconf Marketplace, institutions get advance assurance that their transactions will be included — turning "we hope this lands in a block" into a contracted commitment. ### How it fits together 1. An institution reserves blockspace (whole-block or preconfirmation) through the Blockspace & Preconf Marketplace. 2. The reserved blockspace is served by validators drawn from the **known & onshore** qualified set. 3. The **Policy Engine** enforces the institution's configured rules as the block is built. 4. **Fair ordering** guarantees govern how transactions are sequenced. 5. The institution receives an auditable record suitable for internal and regulatory review. ### Who this is for * Banks and regulated trading desks executing onchain * Asset managers and ETF/treasury operators * Protocol treasuries with compliance obligations * Custodians and infrastructure providers serving regulated clients --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.ethgas.com/overview/institutional-blockspace.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.