{ "@language": "en-gb", "@context": { "CIP100": "https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#", "hashAlgorithm": "CIP100:hashAlgorithm", "body": { "@id": "CIP100:body", "@context": { "references": { "@id": "CIP100:references", "@container": "@set", "@context": { "GovernanceMetadata": "CIP100:GovernanceMetadataReference", "Other": "CIP100:OtherReference", "label": "CIP100:reference-label", "uri": "CIP100:reference-uri", "referenceHash": { "@id": "CIP100:referenceHash", "@context": { "hashDigest": "CIP100:hashDigest", "hashAlgorithm": "CIP100:hashAlgorithm" } } } }, "comment": "CIP100:comment", "externalUpdates": { "@id": "CIP100:externalUpdates", "@context": { "title": "CIP100:update-title", "uri": "CIP100:uri" } } } }, "authors": { "@id": "CIP100:authors", "@container": "@set", "@context": { "name": "http://xmlns.com/foaf/0.1/name", "witness": { "@id": "CIP100:witness", "@context": { "witnessAlgorithm": "CIP100:witnessAlgorithm", "publicKey": "CIP100:publicKey", "signature": "CIP100:signature" } } } } }, "authors": [], "body": { "comment": "YES - Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2).\n\nIn regards to minPoolCost, this reduction has been discussed and debated by the community for years. Many believe this to be an important step in proving that liquid delegations are viable in the context of allowing smaller stake pools to attract delegators, others think it will force small stake pools out of operations via a race to the bottom. The reality of this param is that it is fundamentally useless to the network beyond bootstrapping and initial now less relevant ideas, and ultimately has caused a long term issue with the reward curve. The incentives this parameter provides are not healthy to the Cardano network, this and the lack of other parameters that provide pool incentives is exactly the main topic of discussion among SPOs. Firstly, there is little to no incentive to delegate to small stake pools. Any delegator with the knowledge of how the rewards work will understand they lose money if they stake with small pools, this is just the math of the situation we are in. For small SPOs to be able to compete we must be attractive to delegators. Secondly the race to the bottom is not predicated by this parameter, some likely feel this way because it is the only reliable income they have to gain from being a small stake pool, which includes us at Upstream with a current 250k stake. With this lens we cannot in good conscience support minPoolCost at all, and would vote for it to be ultimately replaced with a clearer poolCost (a cost reflective of what a Stake Pool thinks it's worth, delegators can decide, as it should be). Stake Pools can set any fee they like and we will likely keep ours to ensure operations for a short time, but at some point for small pools to be competitive we need to be able to say in earnest 'delegate to Upstream and earn the same as you would from any other pool' (or as close to that sentence as possible). Of course this is just a band-aid on the actual problem, which is the lack of params that actually drive liquid delegation to smaller pools, which of course can only be achieved if smaller pools are paid equal or more rewards to delegators, than that of larger pools. That is an honest and true incentive to achieve this goal, if indeed this is the collective Cardano goal. Until we have this, small pools will always bear the brunt of our network's incentive structures, and these discussions are only token gestures to cover the problems / intentional alternative incentives. If the aim is a secure network with thousands of productive pools then let's put our money where our mouth is and drive incentives back down the pyramid we have created.\n\nAs for Plutus Memory Limits, this continues on from the first step in the long planned updates (since 2024) and we approved the previous gov action and so we complete this here. The impact for these parameters is minor, only affecting those who must update direct implementations, if at all. Reviewing the technical communities' work, the proposal references and the provided benchmarks make it clear it's very low risk and impact for day to day chain activity." }, "hashAlgorithm": "blake2b-256" }