Small pools are dying...what do you think?

Having several accounts with one seed would be awesome. It should be possible with the current system if the wallet used different derivation paths. They might also be other solutions.
Charles was talking about one to many delegation, so for this stakepool portfolio idea you would be able to stake to multiple pools from one wallet. Anyway, from my perspective this might be a nice to have, but I don’t consider it a high priority at the moment. Maybe it’s more interesting for people that have very large amounts of Ada.

Agreed, d is probably the worst enemy of small pools right now as it can heavily influence their performance. It would have been nice if pools could win slots as if d was 0 but the iohk federated nodes were able to check and override the blocks with a chance of d. But it’s too late for that now and it’s probably not that easy to implement.

Yes, but that can only be done /w different accounts i.e. m/1852'/1815/Accounts' derivation path, as the stake key is derived from the m/1952'/1815'/X'/2 and the system used that key as (reward) account and staking keys, and pair the normal payment keys /w the staking key to track these derivated addresses. It’s is explained in the design spec, why they decided this path, though it means that all your addresses are exposed, similar to know the account public key the m/1852'/1815'/0' as you can derive all addresses form that account key. So, no privacy if you’re staking.

1 Like

It’s kinda tricky. I mean, saturation point is 200M, we have 1000 pools (theoretically, we can stake 200bi ADA, but we will only have 45bi). IOHK, Emurgo or anyone linked directly to Cardano protocol should not have pools, or express a limited time to operate pools themselves, cause maybe it’s even the best way to get data, I don’t know. Is it possible to bring saturation point down? I’m really a newbie here hahahaha


If Cardano is based on mathematics we should be able to create formula to predict what it takes to produce a block. Based on a variety of factors (pledge, delegated ADA, system up time, speed of transactions, etc.) a relatively reliable table could be developed showing a percentage of successful block creation with various parameters.

For example, a pool with 100k ADA pledge, 1m ADA delegated, 100% uptime, and 10k TPS would generate a block 85% of the time in every epoch. Changes to any of the parameters would increase/decrease the success percentage.

Obviously, people much smarter than I would develop the parameters and the correct formula for the application. However, I think it could be a useful tool for current and future SPOs. At least, the small pool operators will be able to see why their pools are not producing blocks and what it would take to be more successful.

All the parameters are already known. An epoch has 21600 blocks, with d at 0.76 that means currently 5184 blocks are produced by pools. The chance to mint a block are directly related to the relative stake of a pool.

With currently 15 bn Ada staked a pool from your example would create 0.007% of blocks. That’s 0.4 blocks per epoch or roughly 2 blocks over a span of 5 epochs.

Tps does not play a role in this.

1 Like

Thank you. As I said someone much smarter than me could figure this out. Since all the parameters are known, what combination of parameters would guarantee at least one block per epoch when d=0?

Roughly 650k Ada combined pledge and stake with the currently 13 bn Ada staked is needed to produce 1 block on average per epoch. It could still happen though that no block is produced and 2 in another epoch. If more Ada in total is staked the number changes proportionally.

There is no combination of parameters that guarantees at least one block per epoch. You would have to change the protocol to achieve that and I don’t see a reason to.

One point missing from discussion, or only implied, selection of block producer is random.

It based on a random chance that is affected by the amount of relative stake.

1 Like

Haha, very good point! Cardano isn’t a get rich quick scheme… Which disappoints many in the crypto space

Dear community members,

You have regularly and consistently asked about the staking strategy by the foundation. Since we have so many channels, I am somewhat randomly choosing this one to outline (very) briefly our thoughts and next steps, as follows:

First, our initial strategy was indeed very simple, let’s call it “rough and handmade”, to serve as an initial iteration with the aim of safely deploying first.

Second, we will shortly publish our current staking - where and how much. Transparency is a good thing!

Third, we will shortly publish our first official draft (v1) of a more detailed staking strategy. While we will deploy this first official strategy immediately upon publication, we will take into account your feedback (I trust there will be lots!) and we will then iterate to a v2, and so on.

I want to manage expectations right away: It is and will be truly impossible to please everyone. Different people have different opinions, and different people weigh different parameters differently. Good reading on this issue here: - best do read the book, though it ain’t easy reading… :slight_smile:

Have a great weekend!

— Nathan


Thanks for the update Nathan

Looking forward to your updates and appreciate the transparency.

Re the link, yep interesting, think the ‘difference principle’ will be well debated !

Like the fact safety was your first priority, also being prepared to evolve is definitely the way forward with your v1/v2 etc.

I agree, you’re not going to please everyone !

Throwing my hat into the ring (with the thought to benefit all of us), for CF/IOG/Emurgo to share some of their funds around the pools (to support and solidify the eco-system) would be a good target to aim for.

How could that be achieved ? open to suggestions

multi_sig will fix this

Hi Nathan,
I love that you are addressing this topic and I also believe transparency is a good thing. As a stake pool operator I know the difficulty in attracting enough delegation to stay in the SPO game and I really appreciate when the foundation supports the SPO community by delegating to stake pools.

Cardano has some very amazing stake pool operators. It may be hard to delegate in a way that is fair, but delegating to the community will make the community stronger. Investing in your community is a win, win!

When the Cardano Foundation, Input Output, and Emurgo delegate to the SPO community it builds that community. The Cardano Foundation, Input Output, and Emurgo have every right to run stake pools of their own, but it feels like more like you are competing with the community when you do. I know that my small stake pool can’t compete with the three pillars of Cardano.

I’m hoping (at least in the short term) the focus stays on, or returns to building community as it is a community worth building and a community worth keeping!


An important premise: Do what’s possible only if it’s just and moral.

This should be obvious:

  1. Charles should make available a turnkey PO system (code only) with ongoing support, free. This action would materially support Charles’ statements with reference to Cardano’s decentralization and stability requirements. The system (soft setup) should be immediately available to anyone who wants to participate in Cardano’s decentralization process.

  2. A delegation transfer from Charles’ pools (corporate pools and private) should be made to new pools that achieve an established verifiable performance/stability standard. It can be done.

Charles’ pools are needed for the network.
Prove it.

Charles has a right to make money as a PO.
We all know Charles’ stated ambition for Cardano. 1. Centralizing relatively (relative to civilian PO’s!) large ADA blocks is counterproductive. 2. The inappropriateness of capturing revenue from these large blocks of up to 7%, as PO’s struggle to the penny, well, I haven’t the words.


Rob : Charles is moving his ADA farm to Coinbase later this year, according to Phillipe. Memory cite: Cardano Effect > 9/6 > a little over an hour in.

Another data point for Charles’ idiograph.

1 Like

Hi Nathan,

Thank you for addressing this.

Could you provide estimated timeframes for publishing current CF delegations as well as for publishing the first official strategy for community delegation?

Your friend,