(at the time of writing the gov.tools site did not have a Parameter Change dropdown value on Propose a Governance Action page implemented yet, although I hear it is in the works)

This proposal is to change the parameter "minimum fixed rewards cut for pools (minPoolCost)" value from it's current value of 170 Ada to 0 Ada. This is to allow stake pool operators to set their fee structure as they see fit - without always forcibly taking a chunk out of pool rewards, the protocol-level action which results in continually growing gap (as the per-block reward continues to reduce over time, by staking design) in maximum ROI that a given small pool can offer compared to a big pool with similar fee structure in place.

Small pools / recently registered pools with moderate pledge by the pool operator currently both offer inferior ROI to delegators, rendering them essentially non-competitive when it comes to trying to attract some delegations from general public. This gap was somewhat less noticeable in the early years of mainnet staking, when the per-block reward was greater (over 1600 Ada in early epochs, down to 358 today) and ROI in general were large. Please compare the data in<br> https://github.com/hodlonaut/a/blob/ec4b0253de013c43e3d5e88e3b8debc5415cc806/small-zero-variable-170-pools-30Apr2025.png <br>with<br> https://github.com/hodlonaut/a/blob/ec4b0253de013c43e3d5e88e3b8debc5415cc806/big-zero-variable-170-pools-30Apr2025.png <br> to see the ROI discrepancy for similar-fee-structure pools in recent history.

While some small subset of such pools have implemented their own custom refund-some-Ada-to-delegators mechanisms, it's not something very trivially achievable nor is it clearly visible/represented in an arbitrary Cardano wallet.

Furthermore, it is my opinion that every SPO should have the ability to specify their own fee structure for their pool based on their own infrastructure/expenses/goals/strategy, instead of trying to fit into some one-size-fits-all box. The change should also should open up the opportunity for smaller pools to be more prominent in wallets that prioritize near-past/future ROI - as well as more prominently highlight the wallets that might have some deficiencies in the options they present to delegators (e.g. promoting some high average lifetime ROI pool over a smaller pool that offers better returns in near future).

I am also hopeful that with this no-longer-needed forced variable removed from the picture, we'll gain better insights into other tweaks we might need to apply to level the playing field, so to speak e.g. if a small pool with decent pledge and very competitive fee structure (with fixedCost = 0 and some variable fee) gets shoved way down Daedalus rankings despite making regular blocks and producing on-chain verifiable returns on par with some bigger pools with matching fee structure, we might need to look into other parts of the calculations (e.g. performance multiplier).

minFixedCost parameter was set to 340 Ada at the launch of Cardano staking, based on a survey of a subset of SPOs on the topic of their expenses at the time, with one of the additional reasons behind it being to try and direct the stake towards the known entity / "OG" pools (that were expected to receive a decent chunk of early mainnet stake based on their participation / delegator familiarity from Incentivised Testnet that preceded it), making it less attractive for some random bad actor to spin up a large number of new pools - as these would very quickly be pushed lower in the ranks of a wallet such as Daedalus for the reasons mentioned in the next paragraph. I'd also hazard a guess that non-zero minFixedCost also is a moderate contributor to the whole "our simulation showed that network will eventually converge to X saturated pools" vision - that I personally don't consider to be an ideal end scenario for the decentralized network anyway (and given we have k = 500 and over 1000 pools making at least one block per epoch on average, I'd argue the simulation struggles to capture the nuances of the complex reality, and my personal ideal scenario is as many unique sustainable pool operators out there as possible, not some specific number to aim for).

In epoch 444 (October 2023, almost 20 months ago now) the parameter update was activated to lower minFixedCost from 340 to 170. Since then, there hasn't been any visible reduction in average blocks minted per epoch, according to my dbsync queries, so there's seemingly not much ammunition for the commonly voiced race-to-zero-via-under-specced-cardano-node-servers critique.

From ~22 billion of active stake across 2918 pools with active stake currently, we have 4.4 billion of stake (19.9%) with pools that have minFixedCost set to 170, and from these the 1.32 billion of stake (5.98% of total stake in network) is with pools that have both minFixedcost = 170 and variable fee of 0% i.e. with the lowest possible fee structure.

While on the subject of race-to-zero fear tactic, see <br> https://github.com/hodlonaut/a/blob/ec4b0253de013c43e3d5e88e3b8debc5415cc806/itn-top-pools.png <br> for top block producing pools from Incentivized Testnet, that preceeded Shelley mainnet launch. Pay close attention to the Fixed Fee (Ada) column and Variable Fee (%) columns. The image is intended to demonstrate that despite there being some absolute zero-fee pools (0 Ada fixed, 0% variable) registered on the network at the time (I actually managed one of those myself), the stake and block production didn't aggregate heavily in such pools. Also notice a large number of Fixed Fee = 0 pools in that screenshot, clearly a decent portion of SPOs were content with the rewards they received and managed via variable fee component.

There have been some suggestions to implement a minimum-variable-fee parameter at the protocol level, while I do see some merits to it (guarantees some income for the SPO, without re-introducing the ROI discrepancy based on pool size), it is beyond the scope of this current proposal and can be discussed/evaluated at an appropriate time juncture in the future.

The suggested monitoring after the proposed minFixedCost parameter adjustment that would be appropriate (the following list is not exhaustive, I will add to it if I think of some additional items): chain density, average block propagation times, percentage of active stake in minimum-fee pools, composition of min-fee pool cohort e.g. via community-curated stake pool group data, MAV/Nakamoto coefficient changes, relative performance of minimum-fee pools and their on-chain relay availability.

Should there be a need to revert this change (e.g. if some ominous looking stake aggregation is observed over months/years or network performance is deemed to be deteriorating), another parameter change on-chain action would need to be submitted - however it is worth noting that currently (to the best of my knowledge) an increase to min- parameter is not enforced i.e. if minFixedCost after being 0 later was set back to 170, any pool that had a certificate update with a value below 170 would remain as-is until they attempt to submit another pool certificate update.

With regards to constitutional guard-rails related to minPoolCost parameter:

MPC-01 (y) minPoolCost must not be negative => check

MPC-02 (y) minPoolCost must not exceed 500,000,000 (500 ada) => check

MPC-03 (x - "should") minPoolCost should be set in line with the economic cost for operating a pool => given the 'should' and vagueness of this guardrail, as well as wide variety of individual pool setups, infrastructure and resources, external funding and personal strategies, I'm of the opinion that people shouldn't be forced into this or that pool fee structure and can achieve the desired cost reimbursement using the most flexible configuration arrangement that this proposal aims to facilitate.

Thank you for reading, please reach out if you have any questions/clarifications/corrections - I will add some more data-based materials to support my rationale if I think of some other useful metrics.