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

# Orchestrator Operator Terms

> Terminology and concept definitions for Livepeer orchestrators - deployment axes, node modes, staking terms, and key operator concepts.

export const CustomDivider = ({color = "var(--lp-color-border-default)", middleText = "", spacing = "default", style = {}, className = "", ...rest}) => {
  const spacingPresets = {
    default: {
      margin: "24px 0"
    },
    overlap: {
      margin: "-1rem 0 -1rem 0"
    },
    tight: {
      margin: "0 0 -1rem 0"
    },
    section: {
      margin: "0 0 -2rem 0"
    },
    sectionOverlap: {
      margin: "-1rem 0 -2rem 0"
    },
    deepOverlap: {
      margin: "-1rem 0 -1.5rem 0"
    }
  };
  const spacingStyle = spacingPresets[spacing] || spacingPresets.default;
  return <div role="separator" aria-orientation="horizontal" className={className} style={{
    display: "flex",
    alignItems: "center",
    ...spacingStyle,
    fontSize: style?.fontSize || "16px",
    height: "fit-content",
    ...style
  }} {...rest}>
      <span style={{
    marginRight: "var(--lp-spacing-px-8)",
    opacity: 0.2
  }}>
        <Icon icon="/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg" />
      </span>
      <div style={{
    flex: 1,
    height: "1px",
    background: "var(--lp-color-border-default)",
    opacity: 0.4
  }}></div>
      {middleText && <>
          <Icon icon="circle" size={2} />
          <span style={{
    margin: "0 8px",
    fontWeight: "bold",
    color: color,
    opacity: 0.7
  }}>
            {middleText}
          </span>
          <Icon icon="circle" size={2} />
        </>}
      <div style={{
    flex: 1,
    height: "1px",
    background: "var(--lp-color-border-default)",
    opacity: 0.4
  }}></div>
      <span style={{
    marginLeft: "var(--lp-spacing-px-8)",
    opacity: 0.2
  }}>
        <span style={{
    display: "inline-block",
    transform: "scaleX(-1)"
  }}>
          <Icon icon="/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg" />
        </span>
      </span>
    </div>;
};

export const TableCell = ({children, align = "left", header = false, style = {}, className = "", ...rest}) => {
  const Component = header ? "th" : "td";
  return <Component className={className} style={{
    padding: "0.75rem 1rem",
    textAlign: align,
    border: header ? "none" : "1px solid var(--lp-color-border-default)",
    ...style
  }} {...rest}>
      {children}
    </Component>;
};

export const TableRow = ({children, header = false, hover = false, style = {}, className = "", ...rest}) => {
  const rowId = `table-row-${Math.random().toString(36).substr(2, 9)}`;
  return <>
      {hover && <style>{`
          #${rowId}:hover {
            background-color: var(--lp-color-bg-card);
          }
        `}</style>}
      <tr id={rowId} className={className} style={{
    ...header && ({
      backgroundColor: "var(--lp-color-accent-strong)",
      color: "var(--lp-color-on-accent)",
      fontWeight: "bold"
    }),
    ...style
  }} {...rest}>
        {children}
      </tr>
    </>;
};

export const StyledTable = ({children, variant = "default", style = {}, className = "", ...rest}) => {
  const wrapperVariants = {
    default: {
      border: "1px solid var(--lp-color-border-default)",
      backgroundColor: "var(--lp-color-bg-card)",
      overflow: "hidden"
    },
    bordered: {
      border: "2px solid var(--lp-color-accent)",
      backgroundColor: "var(--lp-color-bg-page)",
      overflow: "hidden"
    },
    minimal: {
      border: "none",
      backgroundColor: "transparent",
      overflow: "visible"
    }
  };
  return <div data-docs-styled-table-shell className={className} style={{
    width: "100%",
    padding: 0,
    margin: 0,
    ...wrapperVariants[variant],
    ...style
  }} {...rest}>
      <table data-docs-styled-table style={{
    width: "100%",
    borderCollapse: "collapse",
    borderSpacing: 0,
    margin: 0,
    backgroundColor: "transparent"
  }}>
        {children}
      </table>
    </div>;
};

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Deployment

A **deployment** is the complete configuration of a Livepeer Orchestrator, defined by three independent choices: node mode, deployment type, and scale. These axes are orthogonal - each can be selected independently of the others.

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header>Axis</TableCell>
      <TableCell header>Options</TableCell>
      <TableCell header>What it decides</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell>**Node mode**</TableCell>
      <TableCell>Video / AI / Dual</TableCell>
      <TableCell>What workloads the Orchestrator processes</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Deployment type**</TableCell>
      <TableCell>Solo / Pool node / Pool operator / O-T split / Siphon</TableCell>
      <TableCell>How the infrastructure is organised and who manages what</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Scale**</TableCell>
      <TableCell>Single GPU / Multi-GPU / Fleet</TableCell>
      <TableCell>Hardware scope and operational complexity</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Node Mode

The node mode determines what workloads the Orchestrator accepts and processes. This is a configuration choice, not a protocol distinction - the same go-livepeer binary supports all three modes.

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header>Node mode</TableCell>
      <TableCell header>Workloads</TableCell>
      <TableCell header>Key flags</TableCell>
      <TableCell header>GPU requirement</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell><Badge color="blue">Video</Badge></TableCell>
      <TableCell>Video transcoding only - receives segments, re-encodes to requested output profiles via NVENC/NVDEC</TableCell>
      <TableCell>`-orchestrator`, `-transcoder`</TableCell>
      <TableCell>Any NVIDIA GPU with NVENC support. CPU transcoding possible at lower throughput.</TableCell>
    </TableRow>

    <TableRow>
      <TableCell><Badge color="purple">AI</Badge></TableCell>
      <TableCell>AI inference only - processes inference jobs (text-to-image, LLM, audio, etc.) via AI Runner containers</TableCell>
      <TableCell>`-orchestrator`, `-transcoder`, `-aiWorker`, `-aiModels`</TableCell>
      <TableCell>NVIDIA GPU with sufficient VRAM for target models (8-80 GB depending on pipeline)</TableCell>
    </TableRow>

    <TableRow>
      <TableCell><Badge color="green">Dual</Badge></TableCell>
      <TableCell>Both video transcoding and AI inference from a single Orchestrator process</TableCell>
      <TableCell>`-orchestrator`, `-transcoder`, `-aiWorker`, `-aiModels`, plus video flags</TableCell>
      <TableCell>NVIDIA GPU with NVENC + sufficient VRAM for AI models</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

### Dual Mode

<Badge color="green">Dual</Badge> mode is a dual-workload configuration where a single Orchestrator process handles both video transcoding and AI inference. This is the most common production configuration for operators with capable hardware (24 GB+ VRAM GPUs).

Dual mode is not a separate protocol mode - it is the same Orchestrator process with both video and AI capabilities enabled. The Orchestrator advertises both capability types and accepts jobs of either kind.

<Note>
  **Previous terminology**: Dual mode has been referred to by several names in earlier documentation and community discussion:

  * **"Combined mode"** - used in v1 docs and setup-options.mdx to describe running Orchestrator + transcoder in a single process. This term conflates two different concepts: (1) combined O+T process (vs O-T split) and (2) combined video+AI workloads. Dual mode refers specifically to the workload combination, not the process architecture.
  * **"Hybrid"** - used in community discussions and the L0 product exercise. Accurate but informal. Dual mode is the canonical term matching the Gateway glossary's <Badge color="green">Dual</Badge> node type.
  * **"O-T model"** - sometimes confused with dual mode, but O-T split refers to the **deployment type** (separating Orchestrator and transcoder processes), not the **node mode** (which workloads are processed). An O-T split can run in any node mode, including dual.

  The canonical terminology is **dual mode** in headings and labels, and **dual-workload configuration** in explanatory prose where the fuller description aids clarity.
</Note>

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Deployment Type

The deployment type determines how the Orchestrator infrastructure is organised.

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header>Deployment type</TableCell>
      <TableCell header>Description</TableCell>
      <TableCell header>LPT required</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell>**Solo operator**</TableCell>
      <TableCell>Single operator running a complete Orchestrator node. Full control, full responsibility, full earnings. The standard deployment for most operators.</TableCell>
      <TableCell>Active Set threshold for video jobs. Minimal for AI-only.</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Pool node**</TableCell>
      <TableCell>A go-livepeer node running in transcoder mode, connected to an existing pool operator's Orchestrator. The pool operator handles on-chain operations (staking, reward calling, ticket redemption). The pool node provides GPU compute and receives off-chain payouts.</TableCell>
      <TableCell>None - the pool operator stakes.</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Pool operator**</TableCell>
      <TableCell>An Orchestrator that accepts external transcoder workers. Manages on-chain operations and distributes earnings to workers. Requires infrastructure reliability and community trust.</TableCell>
      <TableCell>Active Set threshold + buffer for reliability.</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**O-T split**</TableCell>
      <TableCell>Separate Orchestrator and transcoder processes, typically on different machines. The Orchestrator handles protocol interaction and job routing; the transcoder handles GPU compute. Enables security isolation and multi-GPU scaling.</TableCell>
      <TableCell>Active Set threshold (on Orchestrator node).</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Siphon**</TableCell>
      <TableCell>A lightweight transcoder that connects to a remote Orchestrator, "siphoning" work to a local GPU. Useful for operators with GPUs in locations that cannot run a full Orchestrator (residential connections, shared hosting).</TableCell>
      <TableCell>None - the remote Orchestrator stakes.</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

<Note>
  Deployment type is independent of node mode. A solo operator can run in <Badge color="blue">Video</Badge>, <Badge color="purple">AI</Badge>, or <Badge color="green">Dual</Badge> mode. An O-T split can run any node mode. A pool worker typically runs whatever workloads the pool operator accepts.
</Note>

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Protocol Terms

<AccordionGroup>
  <Accordion title="Active set" icon="users">
    The group of Orchestrators eligible to receive video transcoding work in the current round. Membership is determined by total bonded stake (self-stake + delegated stake), ranked by position. The Active Set size is a protocol parameter.

    AI inference routing does not require Active Set membership - it prioritises capability and price over stake position.
  </Accordion>

  <Accordion title="Round" icon="clock">
    A protocol time period of approximately 22 hours (5760 Ethereum L1 blocks). Each round, active Orchestrators can call `Reward()` to claim their share of newly minted LPT. Rounds are sequential and continuous.
  </Accordion>

  <Accordion title="Reward call" icon="gift">
    The on-chain transaction (`Reward()`) that an Orchestrator calls once per round to claim minted LPT. Missing a reward call forfeits that round's rewards permanently. Gas cost on Arbitrum is approximately \$0.01-0.12 per call.
  </Accordion>

  <Accordion title="Reward cut" icon="scissors">
    The percentage of inflation rewards that the Orchestrator keeps before distributing the remainder to Delegators. Set by the Orchestrator. A lower Reward Cut means more goes to Delegators, which can attract more delegation.
  </Accordion>

  <Accordion title="Fee cut" icon="percent">
    The percentage of ETH service fees that the Orchestrator keeps before distributing the remainder to Delegators. Separate from Reward Cut. Both are set independently by the Orchestrator.
  </Accordion>

  <Accordion title="Stake (self-stake)" icon="coins">
    LPT bonded directly by the Orchestrator to its own address. Self-stake demonstrates commitment and is a prerequisite for activation. Self-stake weight is identical to delegated stake weight for Active Set ranking.
  </Accordion>

  <Accordion title="Delegated stake" icon="hand-holding-dollar">
    LPT bonded to an Orchestrator by Delegators. Combined with self-stake, delegated stake determines the Orchestrator's total bonded stake, which affects Active Set position and governance vote weight.
  </Accordion>

  <Accordion title="Activation / deactivation" icon="power-off">
    The on-chain transaction that registers (activates) or unregisters (deactivates) an Orchestrator on the Livepeer Protocol. An active Orchestrator appears in the Orchestrator pool and is eligible for the Active Set. Deactivation removes the Orchestrator from eligibility.
  </Accordion>

  <Accordion title="Service URI" icon="globe">
    The public URL that an Orchestrator advertises on-chain so Gateways can connect to it. Must be reachable from the internet. Format: `https://your-domain:8935` or similar.
  </Accordion>
</AccordionGroup>

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Operational Terms

<AccordionGroup>
  <Accordion title="Orchestrator (process)" icon="microchip">
    The go-livepeer process running with the `-orchestrator` flag. Handles protocol interaction, job routing, payment negotiation, and capability advertisement. In a combined deployment, also runs the transcoder. In an O-T split, the Orchestrator process runs separately from the transcoder.
  </Accordion>

  <Accordion title="Transcoder (process)" icon="film">
    The go-livepeer process running with the `-transcoder` flag. Performs the actual GPU compute work (video re-encoding, AI inference). In a combined deployment, runs within the same process as the Orchestrator. In an O-T split, runs on a separate machine.
  </Accordion>

  <Accordion title="AI worker / AI runner" icon="robot">
    The container that executes AI inference jobs. Go-livepeer communicates with the AI Runner via HTTP. The AI Runner loads models into GPU memory and processes inference requests. Configured via `aiModels.json` and the `-aiWorker` / `-aiModels` flags.
  </Accordion>

  <Accordion title="Session" icon="link">
    A logical connection between a Gateway and an Orchestrator for a specific job. Video sessions are stream-based (one per active stream). AI sessions are job-based (one per inference request or batch). The `-maxSessions` flag limits concurrent sessions.
  </Accordion>

  <Accordion title="Segment" icon="puzzle-piece">
    A short chunk of video (typically \~2 seconds) that represents the unit of work for video transcoding. Gateways split incoming streams into segments and distribute them to Orchestrators. Orchestrators transcode each segment independently.
  </Accordion>

  <Accordion title="Capability" icon="list-check">
    A specific workload type that an Orchestrator can process. Video capabilities are implicit (all Orchestrators with NVENC support video). AI capabilities are explicit - each pipeline and model is registered individually via `aiModels.json` and optionally advertised on-chain via `-aiServiceRegistry`.
  </Accordion>

  <Accordion title="Warm model / cold model" icon="temperature-half">
    A warm model is loaded into GPU memory and ready for immediate inference. A cold model must be loaded from disk before processing, adding seconds to minutes of latency. During the current beta, Orchestrators typically support one warm model per GPU.
  </Accordion>

  <Accordion title="Pipeline" icon="diagram-project">
    A specific AI workload type: text-to-image, image-to-image, image-to-video, audio-to-text, LLM, live-video-to-video, etc. Each pipeline has its own API endpoint, model requirements, and pricing.
  </Accordion>

  <Accordion title="BYOC (Bring Your Own Container)" icon="box">
    Custom AI inference containers that Orchestrators can run alongside standard Livepeer pipelines. BYOC containers must conform to the Livepeer AI worker API specification.
  </Accordion>

  <Accordion title="Pool" icon="users">
    A shared infrastructure arrangement where a pool operator runs the Orchestrator node and multiple pool workers connect as remote transcoders. The pool operator handles on-chain operations; workers provide GPU compute. Earnings are distributed by the pool operator.
  </Accordion>
</AccordionGroup>

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Economic Terms

<AccordionGroup>
  <Accordion title="PM ticket (probabilistic micropayment)" icon="ticket">
    The payment unit in the Livepeer Protocol. Gateways send lottery tickets to Orchestrators for each job. Most tickets are non-winning; winning tickets can be redeemed on-chain for ETH. Over time, the expected value of winning tickets equals the fair payment for work performed.
  </Accordion>

  <Accordion title="Ticket redemption" icon="receipt">
    The on-chain transaction where an Orchestrator redeems a winning PM ticket on the Arbitrum TicketBroker contract to receive ETH. Redemption costs gas. Orchestrators typically batch redemptions to optimise gas costs.
  </Accordion>

  <Accordion title="pricePerUnit" icon="tag">
    The flag (`-pricePerUnit`) that sets the Orchestrator's video transcoding price in wei per pixel. Gateways with `-maxPricePerUnit` below this value will not route work to the Orchestrator.
  </Accordion>

  <Accordion title="pricePerGateway" icon="tags">
    The flag that allows setting different prices for different Gateway addresses. Useful for commercial relationships where specific Gateways receive preferential pricing.
  </Accordion>

  <Accordion title="autoAdjustPrice" icon="chart-line">
    A flag that enables dynamic price adjustment based on current demand. When enabled, the Orchestrator automatically adjusts its price based on session utilisation.
  </Accordion>

  <Accordion title="Inflation rewards" icon="coins">
    Newly minted LPT distributed to active Orchestrators each round. The inflation rate is a protocol parameter. Rewards are proportional to total bonded stake. Orchestrators must call `Reward()` each round to claim.
  </Accordion>

  <Accordion title="Service fees" icon="money-bill">
    ETH earned from processing actual jobs (video transcoding segments, AI inference requests). Paid by Gateways via PM tickets. Revenue depends on workload volume, pricing, and Gateway selection.
  </Accordion>

  <Accordion title="Earnings" icon="wallet">
    The combined total of inflation rewards (LPT) and service fees (ETH) earned by an Orchestrator. Operators split earnings with Delegators according to their Reward Cut and Fee Cut settings.
  </Accordion>
</AccordionGroup>

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Deprecated Terms

<AccordionGroup>
  <Accordion title="Broadcaster (deprecated)" icon="circle-exclamation">
    The pre-2023 name for a Gateway. The `-broadcaster` flag has been replaced by `-gateway`. The go-livepeer codebase internally still uses "BroadcasterNode" as the enum name. The CLI tool `livepeer_cli` displays "BROADCASTER STATS" - this refers to Gateway metrics using the legacy term.
  </Accordion>

  <Accordion title="Combined mode (ambiguous - avoid)" icon="triangle-exclamation">
    Used in v1 documentation to mean two different things: (1) running Orchestrator + transcoder in a single process (vs O-T split), and (2) running both video + AI workloads. To avoid confusion, use **"single-process deployment"** for the architecture meaning and **"dual mode"** for the workload meaning.
  </Accordion>

  <Accordion title="Hybrid (informal - use Dual Mode)" icon="triangle-exclamation">
    Community shorthand for running both video and AI workloads. The canonical term is **dual mode** (matching the Gateway glossary's <Badge color="green">Dual</Badge> badge). "Hybrid" may appear in community discussions, Discord, and planning documents.
  </Accordion>

  <Accordion title="Pool worker (renamed - use Pool Node)" icon="triangle-exclamation">
    Earlier v2 documentation used "pool worker" for a node running in transcoder mode within a pool. The canonical term is now **pool node**. Community terms include "worker", "miner" (Titan Node), "GPU contributor", and "transcoder". The go-livepeer flag is `-transcoder` in all cases.
  </Accordion>
</AccordionGroup>

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Operational Mode Asymmetry: Gateways vs Orchestrators

Gateways and Orchestrators both use go-livepeer but have a fundamental asymmetry in how operational modes work:

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header />

      <TableCell header>Gateway</TableCell>
      <TableCell header>Orchestrator</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell>**Off-chain viable for production?**</TableCell>
      <TableCell>**Yes.** Off-chain Gateways use a remote signer for payment operations. No ETH wallet, no staking, no blockchain interaction at the Gateway. This is a genuine, sustainable production configuration.</TableCell>
      <TableCell>**No.** Off-chain Orchestrators (`-network offchain`) have no protocol discoverability, no inflation rewards, no Active Set membership. Only Gateways explicitly pointing via `-orchAddr` can send work. Useful for testing and development only.</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**On-chain requirements**</TableCell>
      <TableCell>ETH deposit + reserve on Arbitrum. No LPT staking. No Active Set. No reward calling.</TableCell>
      <TableCell>LPT stake (Active Set threshold for video). ArbETH for gas. On-chain activation. Reward calling each round. Service URI registration.</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>**Operational mode fork**</TableCell>
      <TableCell>**Yes** - on-chain vs off-chain is a genuine production choice that affects the entire operational model, setup flow, and payment architecture.</TableCell>
      <TableCell>**No** - Orchestrators are effectively always on-chain for production. Off-chain is a testing configuration, not an operational mode choice.</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

This asymmetry means the Gateway documentation needs a genuine on-chain/off-chain fork throughout (setup, payments, monitoring). The Orchestrator documentation does not - it can treat on-chain as the default with off-chain mentioned only in the quickstart (for local testing) and in pool worker documentation (where the pool operator handles on-chain).