> 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/setup.md).

# Setup

Validators connect to Gravity through the [Gravity Connector](https://github.com/gravityblocks/gravity-connector), a lightweight sidecar running on the validator host. The Connector integrates with Agave or Jito-Solana through scheduler bindings, so no custom validator fork is required.

Support for Firedancer and Frankendancer is currently in development.

Onboarding has two steps:

1. Gravity authorises the validator identity.
2. The operator installs and configures the Connector alongside the existing validator.

### Request access <a href="#request-access" id="request-access"></a>

Access is tied to the validator identity. Send the Gravity team:

* Validator identity public key
* Validator client type and version
* Cluster and host region

Gravity will register the identity and provide the appropriate endpoints.

### **Endpoints**

<table><thead><tr><th width="156.578125">Region</th><th>Endpoint(s)</th></tr></thead><tbody><tr><td>Amsterdam</td><td><code>tcp://relay-ams.gravityblocks.xyz:12000</code> <br><code>tcp://relay-ams-2.gravityblocks.xyz:12000</code></td></tr><tr><td>London</td><td><code>tcp://relay-lon.gravityblocks.xyz:12000</code></td></tr><tr><td>Tokyo</td><td><code>tcp://relay-tyo.gravityblocks.xyz:12000</code></td></tr></tbody></table>

When adding endpoints to `relay_addrs` in the config, make sure to include all endpoints for a given region, as they may be used as fallbacks.

Additional  regions are being rolled out. Contact Gravity if your validator needs connectivity in a specific region.

### Prepare the host <a href="#prepare-the-host" id="prepare-the-host"></a>

Begin with a healthy, caught-up validator running a supported version of Agave or Jito-Solana.

The Connector requires:

* Scheduler bindings enabled on the validator
* Access to the validator ledger directory
* Access to the validator identity keypair
* One dedicated CPU core
* Outbound connectivity to Gravity

The Connector is latency-sensitive. Do not share its assigned cores with validator hot threads or other latency-sensitive workloads.

Supported versions, required validator flags, and current host recommendations are maintained in the [Connector README](https://github.com/gravityblocks/gravity-connector/blob/main/README.md).

### Configure the Connector <a href="#configure-the-connector" id="configure-the-connector"></a>

Create a configuration file from [the example config](https://github.com/gravityblocks/gravity-connector/blob/main/config.example.toml).

Verify that the following values match the validator host:

* Client type
* Ledger path
* Identity keypair path
* Endpoints
* CPU assignments

#### **Agave**

Agave connects directly to the Connector through scheduler bindings. Jito bundle support can be enabled separately when required.

#### **Jito-Solana**

Jito-Solana uses the Connector's local block-engine proxy while Gravity is active.

Follow the README configuration exactly. A direct connection to a public block engine must not compete with Gravity's external sequencing path.

### Start the Connector <a href="#start-the-connector" id="start-the-connector"></a>

Start the Connector under the process supervisor after confirming that the validator is healthy.

During startup, the Connector:

1. Verifies that its configured identity matches the validator.
2. Connects to an authorised Gravity.
3. Attaches to the validator's scheduler bindings.

The Connector only attaches after the identity and other checks succeed. Registration or connectivity failures during startup therefore leave the validator on its native scheduler.

### Verify the connection <a href="#verify-the-connection" id="verify-the-connection"></a>

The integration is ready when:

* The Connector reports active validator and relay connections.
* `GET /health` returns `200`.
* The validator completes a leader slot normally with Gravity active.

Keep the validator's existing monitoring in place and add the Connector's health and metrics endpoints to the same monitoring stack.

### Fallback behaviour <a href="#fallback-behaviour" id="fallback-behaviour"></a>

The Connector is designed to fail safely. If the external sequencing path becomes unavailable, it exits or removes itself from the scheduling path, allowing the validator to return to its native scheduler.

The README is the source of truth for installation commands, configuration fields, supported client versions, health checks, restart behaviour, fallback conditions, and troubleshooting.


---

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