Skip to main content
Running an Orchestrator keystore on the same machine as GPU workloads creates two risks. A GPU machine reboot mid-round permanently loses that round’s LPT inflation reward, and missed rewards compound over time. A machine actively processing untrusted media data also makes a poor keystore host for staked LPT. The Siphon split setup solves both. OrchestratorSiphon runs on a small, secure machine and handles all on-chain actions: reward calling, fee withdrawal, governance voting, and service URI updates. The GPU machine runs go-livepeer in transcoder mode and processes work while keystore access stays on the secure machine. The two machines are independent. The GPU machine restarts, is replaced, or goes offline for maintenance without interrupting reward claims. Adding a second GPU machine later leaves the secure machine unchanged. For a comparison with the O-T split and pool worker alternatives, see .

​
Architecture

​
When to Use This Setup

Use Siphon when...

GPU machine uptime is uncertain; keystore isolation from workload processing is needed; multiple GPU machines should run behind one Orchestrator identity; or LPT inflation rewards are needed before GPU infrastructure is ready.

Use combined go-livepeer when...

A single machine is sufficient and reward calling alongside workloads fits the operational model. The standard Setup Guide covers this path.
Siphon runs on the secure machine alone to keep claiming LPT inflation rewards while GPU infrastructure is being prepared. When ready, deploy go-livepeer in transcoder mode and update the service URI. The keystore and on-chain registration stay unchanged.

​
Prerequisites

The secure machine needs stability, restricted access, and reliable outbound Arbitrum RPC connectivity. A small VPS (1 vCPU, 512 MB RAM) is sufficient.

​
Part 1 - Secure Machine: Install OrchestratorSiphon

​
Part 2 - GPU Machine: Install go-livepeer in Transcoder Mode

​
Verifying the Split is Working

Once both machines are running, confirm each side is operating correctly. Secure machine (Siphon):
Check Siphon reward activity
# Confirm rewards are being called
journalctl -u orchSiphon --since "24 hours ago" | grep -i "reward\|round"
A reward call should appear for each round (~once every 22 hours). Check the on-chain record on the Livepeer Explorer. GPU machine (go-livepeer):
Check go-livepeer workload activity
# Look for incoming work
journalctl -u livepeer --since "1 hour ago" | grep -i "transcode\|segment\|session"
Transcoding activity appears when Gateways are routing work. A quiet node after 15-20 minutes usually points to a service URI or networking issue, so check that the URI resolves correctly and that port 8935 is open.

​
Day-to-Day Operations

With the split setup running, ongoing workload is minimal. Secure machine - mostly automatic:
  • Siphon calls reward() each round with no intervention needed
  • ETH fees are swept to the receiver address when the threshold is met
  • Check journalctl -u orchSiphon periodically for errors
  • Keep ETH balance above eth_warn and top up when Siphon logs balance warnings
GPU machine - standard Orchestrator operations:
  • Monitor workload activity and metrics
  • Restart cleanly after upgrades or hardware changes
  • Ensure the IP or DNS entry stays valid so the service URI resolves
Reward safety stays with the secure machine. GPU-side maintenance leaves the reward schedule running unchanged.

​
Adding a Second GPU Machine

To add a second GPU machine:
  1. Install go-livepeer in transcoder mode on the new machine
  2. Point -orchAddr at the same service URI, or at a load balancer serving both machines
  3. The Orchestrator’s advertised capacity increases as Gateways observe higher throughput
The Siphon configuration on the secure machine stays unchanged. Stake, on-chain identity, and reward schedule are unaffected.

​
Troubleshooting

The Orchestrator wallet ETH balance has dropped below the amount needed for gas. The eth_minval is intended to prevent this, but sharp Arbitrum gas spikes or unexpectedly fast fee accumulation still drain the wallet when the threshold is set too low.Check the balance in Siphon logs, then top up the Orchestrator address with ETH on Arbitrum One. Siphon resumes automatically.
  1. Verify the service URI on-chain resolves to the GPU machine’s IP or hostname
  2. Check port 8935 is open and reachable from the internet
  3. Confirm go-livepeer started successfully in transcoder mode - check for GPU detection in startup logs
  4. Check the Livepeer Explorer to confirm the Orchestrator is in the active set and the service URI is listed correctly
  5. Confirm pricing is within the range Gateways will accept - a -pricePerUnit value above the market range stops work from routing regardless of uptime
  1. Update the DNS record or IP configuration first
  2. Trigger Siphon’s interactive mode and update the service URI to the new address
  3. Wait a few minutes for the on-chain update to propagate
  4. Verify the new URI appears on the Livepeer Explorer before testing incoming work
Yes. Siphon manages on-chain actions independently. The Orchestrator continues claiming LPT inflation rewards each round regardless of whether the GPU machine is running. The only consequence of the GPU machine being offline is that Gateways cannot route work to it - staked LPT and reward schedule are unaffected.

Alternate Deployments

Overview of all three alternate deployment options and how to choose between them.

O-T Split Setup

The O-T split using go-livepeer on both machines, with keystore handling kept on the Orchestrator host.

Earnings and Rewards

How LPT inflation rewards and transcoding fees work - the two revenue streams Siphon helps protect.

Reward Calling

Reward calling mechanics, gas cost breakdown, and what happens when a round is missed.
Last modified on March 16, 2026