> For the complete documentation index, see [llms.txt](https://docs.gravityblocks.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gravityblocks.xyz/marketplace/block-builders.md).

# Block builders

## Why builders exist <a href="#why-builders-exist" id="why-builders-exist"></a>

Sequencing is a complex, latency-sensitive packing problem. Builders must account for compute limits, account conflicts, transaction dependencies, execution state, and the value of competing transactions and bundles — all within a short decision window.

Solving this effectively requires dedicated infrastructure and substantial engineering effort. Specialized builders provide several benefits:

**Better allocation**

Builders take a holistic view of the block by evaluating all eligible flow and running multiple scheduling algorithms to find the strongest executable sequence.

This makes better use of available blockspace than existing market approaches based on transaction relays and speed bumps.

**Greater efficiency**

Builders move much of the simulation and sequencing work outside the validator’s critical path.

Existing block engines may simulate bundles against state that is outdated by the time they reach the validator, causing them to revert during execution. Through Gravity, builders follow the block as it is constructed and simulate against the latest execution state.

This reduces wasted validator work while leaving final verification and execution with the validator.

**Consistent sequencing**

Multiple builders may use different strategies, but traders interact with a common market rather than a fragmented set of validator schedulers.

Builders compete under the same selection rule, so priority is expressed consistently through transaction value. All else equal, a higher tip results in better ordering.

This makes execution outcomes more predictable without requiring traders to understand how each validator schedules transactions.

**Continuous competition**

Each builder uses its own infrastructure, algorithms, and allocation strategy, then competes in Gravity’s auctions to produce the best rewards for the validator.

Builders can outperform one another by:

* finding better transaction combinations
* using available capacity more effectively
* responding faster to new flow
* supporting new transaction ordering features

This creates continuous competitive pressure to improve sequencing and validator rewards.

**Faster innovation**

Because the sequencing market operates outside the protocol, builders can iterate independently of core developers’ release schedules and engineering bandwidth.

They can introduce new scheduling algorithms, execution guarantees, and application-specific features without requiring a protocol or validator-client release.

**Fault tolerance**

Multiple independent builders provide redundancy. Auctions can continue when an individual builder is slow, unavailable, or unable to produce a valid block.

## Neutrality and builder access <a href="#neutrality-and-builder-access" id="neutrality-and-builder-access"></a>

Gravity applies the same auction and selection rules to every participating builder. Blocks are evaluated on their validity and the value they produce for the validator, without preferential treatment. Gravity does not trade or search onchain, thus reducing conflicts of interest.

Builder access is currently permissioned as participants receive sensitive transaction and bundle flow. Gravity reviews builders before granting access to reduce the risk of leakage, front-running, and other abusive practices.


---

# 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.gravityblocks.xyz/marketplace/block-builders.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.