> 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 the **trust layer between regulated finance and public Ethereum**. It lets regulated participants access fully compliant, atomic instances of Ethereum on demand: preserving Ethereum settlement while adding the controls a bank, asset manager, or custodian needs before they can move from exploration to production.

It does this by moving three things upstream, **sanctions screening, transaction ordering, and validator accountability,** so they happen *before* block inclusion rather than being discovered after settlement.

### The institutional adoption gap

Public chains are powerful because they are open, neutral, and composable. The same properties create risk questions TradFi cannot ignore. Before institutions adopt, **risk must be controlled, trust must be institutional rather than implicit, and proof must be auditable.** Today, three gaps stand in the way:

**1. Sanctions exposure.** Permissionless activity makes OFAC and counterparty controls hard to evidence *before* settlement. Compliance issues are often discovered only after a transaction has already settled.

**2. Execution uncertainty.** MEV can introduce adverse ordering, information leakage, and execution-quality concerns. For an institution, that isn't a "crypto tax", it's market-integrity risk.

**3. Operator opacity.** Validators, builders, and relays may be pseudonymous, offshore, or otherwise hard to diligence, so there is no familiar accountability surface.

### The solution: institutionalized block construction

Institutional Blockspace creates a controlled blockspace pathway with three controls, each mapped directly to one of the gaps above.

**Control 1: Sanctions-aware inclusion**

OFAC and counterparty controls move upstream. Institutional flows are screened and evidenced **before** block inclusion, enforced by the Policy Engine, rather than reconciled after settlement.\
*Outcome: a sanctions-control perimeter designed for public-chain settlement.*

**Control 2: MEV-protected execution**

For institutions, MEV is a market-integrity risk: adverse ordering and information leakage. Institutional Blockspace applies ordering rules that reduce harmful extraction and improve predictability.\
*Outcome: fairer, more predictable execution institutions can evidence.*

**Control 3: Known or onshore validators**

Qualified, onshore operators give institutions a familiar diligence surface: identity, jurisdiction, controls, and enforceability.\
*Outcome: public-chain settlement with a bank-grade operator model.*

### The thesis

Institutional Blockspace becomes the **trust layer between regulated finance and public Ethereum**:

* Compliance-sensitive flows can be **screened and evidenced before inclusion** (sanctions exposure → controlled).
* **Fair ordering** reduces harmful extraction and improves execution confidence (execution uncertainty → managed).
* **Known operators** create a diligence and enforcement surface institutions recognize (operator opacity → resolved).

The result is a trusted pathway for institutions to move from exploration and pilots into production on public blockchain rails.

### Who this is for

* Banks and regulated trading desks executing onchain
* Asset managers and ETF / treasury operators
* Custodians and infrastructure providers serving regulated clients
* Protocol treasuries with compliance obligations

> See also: [Blockspace & Preconf Marketplace](/overview/blockspace-and-preconf-marketplace.md) 


---

# 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=<question>&goal=<endgoal>
```

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