How you earn
A node's reward is a share of one day's emission, decided by what it staked and by three measurements of what it did with that stake. This is the formula the software actually runs, with the parts it cannot know marked as such.
Every constant on this page is read from crates/rewards in openfiat-core. No node has been paid yet.
What decides your share
Emission per epoch is fixed. Your reward is your weight over every eligible node's weight, and weight is a stake multiplied by three measurements of service — each of which is at most 1.0.
share = emission × (stake × connectivity × availability × pinning) ÷ Σ (the same, for every eligible node)
effective_stake
What you staked
Read from your on-chain stake account, never from a figure your node reports about itself. One stake backs one node: if two nodes name the same account, both are excluded for the epoch.
connectivity_bps
Whether you bridge to Solana
1.0 if the network saw your node originate a Solana blockhash announcement, 0.4 if it only ever saw you gossip. A bridging node does strictly more work, and the difference shows in its own signed announcements rather than in a claim.
availability_bps
How much of the day you were up
The share of the epoch's 24 one-hour slices your node was heard in at all. Being heard once in a slice scores it and being heard five hundred times scores the same, so flooding the network earns nothing.
pinning_bps
Whether you serve content
1.0 if your node returned bytes matching a content address when challenged, 0.7 if it was never challenged or failed. This is the only one of the three that is proven rather than plausible — bytes that hash to a CID cannot be produced without holding them.
One caveat on that fourth term. OFS-4100 §9.2's confirmed table lists three factors — stake, connectivity, availability — and does not mention pinning. The crate applies it anyway. Where the specification and the code disagree this page follows the code, because the code is what would compute a schedule; but read the pinning multiplier as running ahead of the specification rather than settled by it.
Nothing here can exceed 1.0
Every multiplier is a fraction of one, and the software refuses to start with a parameter set where one is not.
That is not caution, it is the only arrangement that adds up. The pool for an epoch is a fixed number of tokens, and the multipliers decide how that pool is divided. A multiplier above 1.0 would not pay a good node extra out of somewhere — it would apportion tokens the Infrastructure bucket does not contain. RewardParams::validate rejects such a set outright rather than letting the shortfall surface on payout day.
It is also why the reward for serving content is built as a penalty on nodes that do not. “Nodes that pin earn more” and “nodes that do not pin earn less” describe the same outcome, and only the second can be implemented without inventing tokens. A pinning node keeps its whole share; a node that pins nothing yields three tenths of its own.
| Connectivity | Content | Multiplier |
|---|---|---|
| Bridging to Solana | Answered a challenge | 1.00 |
| Bridging to Solana | Not challenged, or failed | 0.70 |
| Gossip only | Answered a challenge | 0.40 |
| Gossip only | Not challenged, or failed | 0.28 |
Read the middle two rows together: a gossip-only node that serves content (0.40) still earns less than a bridging node that serves none (0.70). Serving content is a premium on top of a chain connection, never a substitute for one.
Try your own numbers
The left column is what you control. The right splits the result in two: what your inputs settle exactly, and what depends on a network that has not formed yet.
Your node
Below 1,000 OPEN a node is not weighted at all. It is not paid a smaller share — it is skipped.
Of the epoch's 24 one-hour slices. A slice counts once, however much traffic you send during it.
Settled by your inputs
1.00of a possible 1.00
Your quality multiplier — the three service factors, collapsed the way the schedule collapses them.
- connectivity
- 1.00
- availability
- 1.00
- pinning
- 1.00
- quality
- 1.00
Depends on the rest of the network
Your share is your weight divided by every eligible node's weight, so it cannot be computed from your inputs alone. There is no live total to substitute — this page reads no chain state, and no reward has ever been distributed. So the total is a guess, you set it, and both figures below rest on it and on nothing firmer.
- 1.1%
- Your share of the epoch's pool
- 928.72
- OPEN per epoch, under that assumption
The whole pool is 82,192 OPEN per epoch, split across every eligible node. Both figures move the moment anyone else stakes, and neither is a forecast.
The pool is finite
Bootstrap emission is a bucket, not a rate. It empties.
120,000,000 OPEN — 12% of supply — is set aside to pay nodes while protocol revenue is too small to matter, spread evenly across roughly four years of daily epochs. On the day it runs out the reward pool becomes exactly the Infrastructure treasury's share of settlement fees: what the network earned, and nothing more. Anyone sizing a node against the figures above should size it against that day too.
- 120,000,000
- OPEN in the bucket
- 82,192
- OPEN per epoch
- 1,460
- Daily epochs
The Infrastructure / Node Bootstrap genesis allocation, 12% of total supply.
Shared by every eligible node, and capped by whatever is left in the bucket.
About four years, after which emission is whatever protocol revenue funds.
What this page will not tell you
Three figures are missing, and each is missing on purpose.
What it is worth in your currency
OPEN has no market and therefore no price. A figure in dollars, euro or renminbi here would be a number this project invented about its own token and then handed you with the authority of a calculator. There is no honest rate to convert at, so there is no conversion.
A yield, an APR, or a return
A percentage return reads as a promise, and this is not something the protocol can promise. The emission behind it empties in four years, the share is divided with every node that joins, and none of the parameters is fixed — §9 makes all of them governance-updatable. One annualised number would hide all three.
What the network has staked today
This page reads no chain state. Your share depends on the total staked across every eligible node, and rather than substitute a plausible-looking figure the calculator makes that total an assumption you set, then labels everything resting on it.
What is actually running
The calculation exists. The payment does not.
Nodes observe each other's liveness and publish what they saw, and the schedule that turns those observations into amounts is implemented and tested — deterministically, so anyone holding the same observations derives the same answer and the paying node can be checked rather than trusted. What is missing is the last step: nothing submits a schedule on chain, and the rewards vault is empty. No node has ever been paid.
Every value here is a governance parameter rather than a constant: the 1,000 OPEN floor, the 24 availability slices and all four multipliers can be changed by a vote without a code change. These are today's defaults.
Constants read from crates/rewards/src/params.rs; the arithmetic mirrors schedule.rs, including where it truncates.
Run one and find out
The reward model is the smaller half of the decision. The larger half is whether the machine, the bandwidth and the attention are worth it to you — the operator guide has the real hardware, the real commands, and the parts that are not built yet.