Skip to content
StreamSync Run a Node

← Back to writing

Operator Economics: What You Actually Earn Running a StreamSync Node

StreamSync Team · ·
operatorseconomics

If you’re considering staking 10,000 STRM and running a node, you deserve a clear answer to “what do I earn?” — not a glossy chart with the y-axis cropped. This post is the numbers-honest version. We’ll walk through revenue sources, cost lines, the staking math, and what realistic operators look like across the four specializations.

The revenue model in one paragraph

Every successful query distributes its fee on-chain. The race winner takes 70% of the operator pool, two verifiers take 15% each, and the losing racers earn nothing for that query but pay almost nothing to participate. The operator pool itself is 50% of the customer’s payment — the other 50% goes to treasury (20%), data providers (20%), and governance (10%). So when a customer pays 100 units, the race winner takes 35 units, each verifier takes 7.5 units, and the rest is split across the protocol’s other beneficiaries.

That sentence is the entire model. Everything below is how it plays out for you specifically.

Pick a specialization

You pick one of four roles when you start. The hardware that earns is different for each.

Speed runner. Low-latency hardware in racks close to where customers live. Bare metal in NY4, AMS5, NRT, SIN. Sub-millisecond NICs, NVMe storage, modest CPU. Wins on simple account and program lookups. Highest race-volume role; lowest margin per query. The economics work because you participate in tens of thousands of races a day.

Cache optimizer. High-memory hardware (256GB+) optimized for holding the working set of Solana state. Wins on point lookups against hot keys. Earns more per query than speed runners because customers value the freshness, and earns predictably because the hot set is sticky. Returns on cache-strategy sophistication: a smarter cache wins more races at the same hardware spend.

ZK reconstruction. High-CPU hardware for rebuilding compressed account state. Wins on compressed NFT lookups and other ZK-tree queries. Premium pricing per query because the work is genuinely heavier. Lower query volume, but the per-query revenue is roughly 4-8× higher than a speed-runner query.

Archive. High-storage hardware (hundreds of TB). Wins on historical queries — old transactions, deep account history, compliance lookups. Lowest race volume because most queries are recent; highest reliability premium when an archive query does come in. Best suited for operators who already run cheap dense storage.

You can run multiple specializations on separate physical machines if you want. You cannot run a hybrid single-node setup — the gateway expects one specialization per registered node ID.

The staking math

Minimum stake is 10,000 STRM per operator. The cooldown to unstake is seven days. The stake is at risk: incorrect responses get slashed, and persistent missed-SLA events erode your reputation score (which lowers your selection probability, which lowers your revenue).

What is the stake actually for? Two things. First, it gates entry — without a stake floor, the network would be flooded with low-effort racers who don’t have skin in the game. Second, it is the collateral for slashing — if your node returns a confidently wrong answer, the verifier who catches it earns a bounty out of your stake. The slashing parameters are tuned so that a single bad response costs more than the revenue from a day of correct responses. We are deliberately strict.

Your stake also earns a baseline yield through the governance pool, so the opportunity cost of staking is meaningfully less than the headline rate.

What revenue looks like, role by role

Numbers below are illustrative — actual market prices clear per epoch and depend on the operator supply and the customer demand at the moment. They are calibrated against the racing competition tests in the repo and conservative customer-volume assumptions.

A speed runner in a well-populated region typically participates in 40-80k races per day at a 15-25% win rate. At a representative race fee, that’s a daily gross of low four figures in USD-equivalent. Hardware cost (bare metal in a tier-3 datacenter) runs $400-800/month depending on the region. Net margins are healthy after the first few weeks of reputation buildup, and the revenue scales linearly with how many additional speed-runner nodes you operate.

A cache optimizer sees a lower race count but a higher win rate (40-60% when the cache strategy is good). Hardware is more expensive — high-memory boxes are $1,500-3,000/month — but the per-query revenue is 2-3× higher than speed runners, and the verifier share is a meaningful additional income stream because cache nodes often have the right data to verify their neighbors’ answers.

A ZK reconstruction node has lower volume still — these queries are a small fraction of total traffic — but the per-query revenue is the highest in the network. A well-placed ZK node with good Solana account decoding is profitable on hardware spend in the $2,000-4,000/month range.

Archive nodes are the most predictable. Volume is low, hardware spend is dominated by storage cost ($/TB-month), and the operator’s job is to be reliably online for the queries that do come. Margin is thinner per query but the absolute spend is also lower; archive operators are often colocated with bare-metal storage providers and run on the leftover capacity.

Reputation and selection

The gateway does not pick racers uniformly. It picks by reputation, with a small bias toward newer operators to give them a chance to build a track record. Reputation is a weighted score of latency (40%), correctness (40%), and uptime (20%). A new operator starts at the network median and moves up or down based on actual performance.

The practical effect: your first month is a buildup period. You won’t earn at full rate immediately, but you also won’t earn nothing — the new-operator bias guarantees some selection. By month two, well-behaved operators are at-rate. By month three, the strongest operators are net selectors-of-choice in their region.

How operators get slashed

There are three slashing paths:

  1. Incorrect response. A verifier challenges the winner’s hash; if the challenge succeeds, the winner loses an amount calibrated to several days of revenue. The challenger receives roughly half of the slashed amount.

  2. Sustained missed-SLA. If an operator’s missed-SLA rate exceeds threshold across a multi-day window, a fraction of the stake is burned to discourage running deliberately slow racing equipment to harvest verifier shares.

  3. Equivocation. If a single node returns different answers to different verifiers for the same query, the slashing is severe — both stake and reputation are wiped. We have not seen this happen on devnet so far. We are watchful.

Should you operate?

The honest filter:

  • If you already run Solana validator or RPC hardware and have spare capacity, almost certainly yes. The marginal cost of adding StreamSync is close to zero.
  • If you are buying hardware specifically to operate, the speed-runner and cache-optimizer roles have the cleanest economic profile to start with. ZK reconstruction is more specialized and rewards Solana-internals expertise.
  • If you cannot tolerate stake at risk, you should not operate. The slashing is real and intentional.
  • If you want passive yield without operating hardware, governance staking is a separate path and earns a different (lower) rate.

The economics are competitive with running a hosted RPC service on rented hardware, and the structural advantage is that you are competing in a market that rewards real performance rather than a quarterly sales cycle.