# Validator Setup

Run the Toby-Solana Client to participate in OpenMEV, earn MEV tips, and receive optimized stake delegation from the Validator Optimizer.

## Prerequisites

* An existing Solana validator setup (or capacity to provision one)
* Firedancer compatible hardware. Standard Solana validator specs apply.
* Familiarity with Solana validator operations (key management, monitoring, upgrades)

## Installation

The Toby-Solana Client is a modified validator client that adds OpenMEV capabilities to your existing setup. It handles MEV bundle processing, tip collection, and performance reporting to the Validator Optimizer.

### Compatibility

* **Firedancer:** Fully supported (recommended)
* **Agave:** Deprecated. Toby-Solana Client targets Firedancer exclusively.

### Setup Process

1. **Download the Toby-Solana Client** from the official repository:

   ```bash
   git clone https://github.com/toby-solana/toby-solana-client.git
   cd toby-solana-client
   cargo build --release
   ```
2. **Configure OpenMEV settings** in your validator config. Add the Toby block to your `validator.toml`:

   ```toml
   [toby]
   enabled = true
   block_chef_endpoint = "https://blockchef.toby.so/v1/relay"
   tip_wallet = "<YOUR_TIP_COLLECTION_WALLET>"
   reporting = true
   ```
3. **Enable MEV bundle processing** so your validator can receive and include winning bundles from Block Chef during block production:

   ```bash
   toby-solana config set --enable-mev-bundles
   ```
4. **Restart your validator** with the new client binary, replacing your existing Firedancer startup command.
5. **Verify OpenMEV connectivity.** Confirm your validator is connected to Block Chef and reporting to the Validator Optimizer:

   ```bash
   toby-solana status --check-openmev
   ```

   Expected output:

   ```
   OpenMEV Status: CONNECTED
   Block Chef:     https://blockchef.toby.so/v1/relay ✓
   Tip Wallet:     <your-wallet-address>
   Reporting:      ACTIVE (last report: 2s ago)
   Client Version: 0.1.0-devnet
   ```

> **⚠️ Devnet Only:** The repository, endpoints, and configuration shown above are for the **devnet environment**. Mainnet URLs and migration scripts will be published at mainnet launch. Join [Discord](https://discord.gg/toby) for devnet access and support.

## How MEV Tips Flow

Once your validator is running the Toby-Solana Client:

1. **Searchers submit bundles and tipped transactions** to Block Chef.
2. **Head Chef receives, inspects, and tags** each bundle against OpenMEV's guidelines. Non-compliant bundles (sandwiches, front-runs) are rejected.
3. **Sous Chef takes approved bundles**, auctions them based on tip value, and assembles partial block proposals.
4. **Your validator receives the assembled proposal** when you're the current block leader and includes it in the block alongside regular transactions.
5. **The MEV tip attached to the bundle is distributed:**
   * 5% protocol fee to the Toby network (funds development + buyback)
   * Remainder distributed to ecosystem participants (validators, stakers, searchers)
6. **Tips accumulate in your tip wallet** and can be claimed or auto-compounded.

The more blocks you produce, the more bundles you process, and the more tips you earn. The Validator Optimizer turns this into a flywheel.

## Validator Optimizer Scoring

The Validator Optimizer autonomously delegates staked assets to the highest-performing validators. Your validator is scored on three factors:

### 1. Good MEV Capture Rate

How effectively your validator processes beneficial MEV bundles (arbitrage and liquidation opportunities). Higher throughput and lower rejection rates improve this score.

### 2. Toby-Solana Client Adoption

Running the latest version of the Toby-Solana Client earns a scoring bonus. The client improves transaction throughput, reduces latency, and keeps you compatible with the latest Block Chef features. Validators on outdated versions see reduced scores.

### 3. OpenMEV Compliance

Your validator must not engage in harmful MEV patterns. The Validator Optimizer monitors for sandwich attacks, front-running, and other extractive behavior. Compliant validators keep their score. Violators lose delegation.

**The flywheel:** Higher scores = more delegated stake from the Optimizer = more block production = more MEV tips = higher revenue. This loop reinforces itself, rewarding validators who invest in performance and compliance.

## Monitoring

Track your validator's OpenMEV performance across these metrics:

* **Bundle processing rate:** Number of Block Chef bundles processed per epoch
* **Tip earnings:** Total MEV tips earned, broken down by strategy type
* **Optimizer score:** Your current composite score and rank among Toby validators
* **Client version status:** Whether you're running the latest Toby-Solana Client

Use the CLI for local monitoring:

```bash
toby-solana metrics --epoch current
```

Example output:

```
Epoch 542 | Toby-Solana Client v0.1.0-devnet
─────────────────────────────────────────────
Bundles Processed:    1,247
Tips Earned:          18.43 SOL
  ├─ Arbitrage:       12.81 SOL (694 bundles)
  ├─ Liquidation:      4.22 SOL (312 bundles)
  └─ Backrun:          1.40 SOL (241 bundles)
Optimizer Score:      847 / 1000 (rank #23)
Client Status:        UP TO DATE
```

A web-based dashboard at `validator.toby.so` is planned for mainnet.

> **⚠️ Devnet Only:** CLI metrics are available on the devnet environment. Mainnet monitoring tools will be published at launch.

***

**Related:**

* [Validator Optimizer](/products-and-infrastructure/validator-optimizer.md): Scoring methodology and delegation mechanics
* [For Validators](/use-cases/for-validators.md): Business case and yield analysis
* [Getting Started](/builders/getting-started.md): Architecture overview and integration paths


---

# Agent Instructions: 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:

```
GET https://learn.toby.foundation/builders/validator-setup.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.