Economic analysis of Chunk only producers

Hi @everyone:

Just to put some facts and numbers on the table, and following @cloudmex-alan proposal for Alternative rewards models for validators, I attach a spreadsheet which evaluates the Net annual income of a Chunk only producer under different fees and total stake received.

Previous posts related to this subject:

Params and calculations


At the current date (Jan 23 2023), the following conditions apply:

  • NEAR market price = 2.58 $USD/NEAR
  • Stake of last Block producer (validator #100) = 438,248 NEAR
  • Min estimated cost for running a Validator node (see details in spreadsheet) = 100 $USD/month
  • Rewards received per epoch and per staked NEAR = 0.000176 NEAR
  • Chunks produced per epoch (based on my own experience) = 15 chunks
  • Epoch duration (average) = 18 hs
  • Epochs per average month (30.4 days per month) = 40,5 epochs

Calculated Net annual income

 Stake * Rewards_per_stake_and_epoch * Epochs_per_month * NEAR_Price * Fee/100*12  
 - Total_costs_per_month * 12

The spreadsheet

Open Google Sheet: Chunk-only-validator-economics-v2.xlsx

DISCLAIMER this is based on my very short experience as a Chunk only producer (pool idtcn4) so please comment and/or correct my assumptions whenever you think they are wrong.

Results screenshot (Jan 23, 2023)

Preliminary conclusions

As the following spreadsheet shows , under the current market conditions and at a 1% fee, a Chunk only producer will never be profitable, even after collecting a 500,000 N stake, which just disqualifies it as a Chunk only producer.

Is is not the purpose of this post to discuss what “marketing” activities can a Chunk only validator do to keep a decent amount of delegators attached to it’s pool, besides a very low fee (unprofitable for Chunk only producers as the numbers show) and having a provable and persistent high uptime (very difficult for new validators at least at this initial stage).

But considering the fact that some long time validators have now decreased their fees to 0% (avado, panda), and some well known ones (zavodil) have fees in the order of 1%, I think it is unfeasible for Chunk only producers to have fees much greater than 1% for two reasons:

  1. Higher fees will not allow them to compete with more established and proved validators.
  2. It is unlikely that Liquidity pools will delegate to them with higher fees.

A note about Liquidity pools:

Even when some liquidity pools (such as Metapool) inform us that 10% fee is the maximum allowed, it is highly improbable that they will delegate to Chunk only producers a huge amount of stake, considering that if you increase fees the APY goes down, and that Chunk producers have no enough provable history (yet).

In my (very short !) own experience, after running my node for almost a month at 100% uptime at 5% fee, and having been in the pending delegations list many times at, the node have never received any delegations at all.

Not to blame anybody, Liquidity pools have to provide the best outcome for those who are staking with them, and Chunk only producers just may not be the best choice most of the time.


Awesome work! Thanks, @mariozito!

That is what I tried to say!

I think we should think about limiting the bottom fee percentage for top nodes or speak with @zavodil and others about this.

We should think about how we can implement limitations, like:
Top-20 nodes - minimum fee percentage - 7%
Top-50 Nodes - minimum fee percentage - 5%
Top-100 Nodes - min 3%
And etc
But as I understood we can’t do this without poolv2

So waiting for new proposals


Great job! I also became a chunk only validator after SW-III. And It is quite essential question for me too.

But I suppose that there is mistake in a counting:

As I see:

  • Epoch duration (average) = 14 hs
  • Epochs per average month (30.4 days per month) = 52 epochs

Of course it doesn’t make chunk only validation profitable, but it moves breakeven point.


And this counting ignores a really secure way for validator pools. I mean backup nodes.
The secure way doubles costs for validators and make it personal financial disaster.


Great thanks for your correction !

I think that it has changed since the moment I started running the node (~Dec 15th) or I just miscalculated it. My mistake anyway.

Anyway, as you said it improves breakeven, but it does not change profitability a lot.

Of course this is highly sensitive to NEAR price, in my first version it was 1.6 so it was worst.Hope it keeps going up :slight_smile:


Totally agree. As mentioned in the sheet details, it does not consider a Backup node, which is really needed.

BUT I wanted to keep cost estimation to a bare minimun to demonstrate that even when running under bare minimum costs it is still unprofitable in the long term.

Of course, this costs may vary from validator to validator but I don’t think nobody can go below those min costs.

And putting all costs on the table really makes it MUCH worst. So shared the sheet so anyone can play with their own costs and fees.


Hello @mariozito, thank you for sharing your research. As we have been discussing in previous posts, to improve decentralization in the network we need more validators. I think no one wants to lose money every month for the whole year just to keep their node, so we need to make some proposals to improve profitability.

Tagging some people to include in this topic: @DDeAlmeida @cloudmex-alan @blaze @Alpar_NEAR @george_NEAR @marcelo @Bowen @satojandro


No, no and no! See: [Research] Alternative rewards models for validators - #9 by JoeSixpack

Anyway enough talk, put forward a NIP and lets get it done.


In the last days we also found that 100% fee’s are not mandatory abuse.

Lets think a custodial service of staking that is looking the best APY to their holders. 100% fee is a legit option. But thinking on an extra support like UBI this 100% fee validators should be removed.

Updated the sheet the with corrections mentioned by @ruziev-dev

  • Epoch duration (average) = 14 hs

Still the same link: Chunk-only-validator-economics-v2.xlsx


Just for the record: is impossible to keep a 100% uptime for a small chunk producer:

*I’ve changed my node to Azure, with this characteristics:
The network bandwidth is ok

In config.json I’ve added more spaces for peers:

Then I’ve lost a chunk and the uptime goes to 90.91%