> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Run a node

> Node operation is not open. The validator set is invitation-only through mainnet — what the roles are, and how to ask about joining.

<Warning>
  **Node operation is not open.** The validator set is run by Intention Labs and invited partners, and joining is by approval rather than by registration. There is no public join flow, no permissionless entry, and no validator binary published for general download.
</Warning>

If you want to operate infrastructure on Intention, the path is to ask. Everything below is context for that conversation.

## Asking about node operation

Email `contact@intention.xyz` with **Node operator** in the subject line.

What to include, because it is what the first reply would otherwise ask for:

|                    |                                                                         |
| ------------------ | ----------------------------------------------------------------------- |
| **Who you are**    | Organization, and any networks you already validate on                  |
| **Which role**     | Validator, or a full node for your own read traffic                     |
| **Infrastructure** | Where you would run it, and whether it is bare metal or cloud           |
| **Why**            | What you need from the network that a public endpoint does not give you |

The last one matters more than the others. A large share of the reasons people want to run a node — reliable reads, historical queries, not trusting someone else's indexer — are better solved another way, and the answer may be an endpoint rather than a machine.

## The roles that exist

Understanding which one you actually want is worth doing before the email.

| Role                    | What it does                                                                                                                                     |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Validator**           | Participates in [IntentionBFT](/protocol/architecture/intention-bft) consensus, sequences trading actions, and certifies in-block oracle quorums |
| **Validator full node** | Follows and executes committed blocks without voting. Sits between validators and the public internet to absorb read traffic                     |
| **Public full node**    | Serves reads and state sync. Does not vote and holds no consensus responsibility                                                                 |

Only the first is a consensus role. The other two are infrastructure, and they are where most integration needs actually land — a full node answers historical queries and lets you verify the chain's answers yourself without any consensus responsibility at all.

## Why it is closed

A validator on Intention does more than order transactions. Matching, clearing, liquidation, and funding all execute inside block execution, so a validator is running the exchange, not running a chain that an exchange sits on top of.

That raises the cost of a misbehaving or under-provisioned operator from "slower blocks" to "degraded execution for everyone trading." Until the network has run under sustained real load through mainnet, the set stays small and known.

The hardware profile is also closer to a low-latency trading box than a typical chain node, and the specifics are still being fixed by load testing. Publishing requirements that are about to move would send operators to buy the wrong machines.

## What does not exist yet

**Staking, delegation, and rewards.** The validator role is a technical operator role today. There is no native token economic model behind it, and nothing on this site should be read as describing one.

**A permissionless join flow.** Validator participation opens in stages alongside public testnet and mainnet. When there is a process, it is announced in the [protocol changelog](/protocol/roadmap/changelog).

## If you just need the data

Most reasons for running a node are read-access reasons, and those are already served:

<CardGroup cols={2}>
  <Card title="Developers" href="/developers/overview">
    REST and WebSocket APIs, and the published specification.
  </Card>

  <Card title="Indexer" href="/protocol/architecture/indexer">
    How historical queries are served, and when to verify against the chain instead.
  </Card>

  <Card title="The network today" href="/protocol/architecture/network-status">
    Live endpoints, and how to check what you are connected to.
  </Card>

  <Card title="Network topology" href="/protocol/architecture/intention-bft#network-topology">
    Where each node role sits in the network.
  </Card>
</CardGroup>
