Stake pool performance vs margin (tax)

You might get better rewards with a low tax pool on a sunny day, but what do you do when the rain starts?

Time to crunch the numbers again:

That’s misleading (I would say much more harsh things) for some reasons, for example pledge is not considered and it’s highlighting ITN where pledge was not part of the calculation also ITN was not really properly implemented.

I do not like these kind of subjective reports at all, which is only good for few things e.g. false marketing and manipulating public opinion.

3 Likes

You are right, I completely left pledge out. My goal was to show what happens when a pool with a low tax starts to lose blocks and how this affects delegator returns compared to a higher tax pool that mints all of it’s assigned blocks.

I do state that:

The only difference between the two pools is the pool margin.

I’ve been a bit obsessed with the created/assigned blocks metric since the ITN started.

I think we can both agree that if a pool starts to lose blocks it will have a negative impact on the returns. I know that the Haskell code is more stable and the HTN proved that. There’s no need to create monitoring/restart scripts like we did on the ITN. However, a pool can lose blocks due to operator error.

We’ll have to wait and see if the created/assigned blocks will be a relevant metric for mainnet or if all pools will eventually converge to the same percentage of created/assigned blocks.

I’m highlighting the ITN because my pool did good on the ITN. It’s like going to a job interview and you start talking about the highlights of your previous job.

I also mentioned the following:

Please note that ITN Performance might or might not correlate with mainnet performance. This is just me talking about my previous accomplishments.

I agree that my report is subjective, after all I mention my pool by name and I’m highlighting my past performance.

I wouldn’t call this false marketing since created/assigned blocks is a good indicator (at least in theory) and I don’t imply that the ITN performance will correlate with mainnet performance.
Also, my ITN performance is my proven track record. From a technical point of view, I was on top of my game when I had to debug sync issues and write monitoring/restart scripts. Sure, it’s a different ball game on mainnet, but the technical skills transition over.

I’m new to the whole article writing thing. I’m still learning the ways and I’m trying different approaches to see what works and what doesn’t.

Thank you for your feedback. I will take it into consideration when I write other articles

I think your piece is very relevant, but not from the angle of missing blocks due to operator error, but due to losing slot battles.

Slot battles are part of the protocol.
I can’t find a reference right now however I’ve read that the haskell code is better at handling slot battles to ensure fainess to all pools. This is achieved by wating for multiple possible blocks before randomly choosing one.
I believe that slot battles will converge to the same 50/50 win/lose ratio for all pools.
I think that there was this trick on the ITN with setting your clock a few ms forward to ensure a slot battle win :grinning:

Edit: grammar/typos

The slot battles are eliminated by selecting the lower VRF in the block headers for the same slot. Of course assuming no multiple pools are running /w same Cold/KES/VRF keys.

1 Like

Thanks for the info. I wasn’t aware that there was already progress to make it more fair. If you find the reference I’d be very interested