JohnM

A minimum pool fee makes it costly to run loss-making pools just to gather stake, and that still matters. But block rewards are now a fraction of what they were when 170 ada was set, so the fee takes a large share of the rewards of a pool making one or two blocks an epoch. Its delegators pay for that however well the pool performs.

I am voting Yes because the problem is clear and the fix is simple. Nobody has to lower their fee. The Parameter Committee reached consensus on this value, and Input Output Research separately concludes that a high floor is more likely to reward large operators splitting stake than to deter it. The downside is confined to how existing rewards are shared; block production and security are untouched.

The benefit is modest. The ledger shows the 2023 reduction did not change how most stake is priced, and the yield effect is material only for a narrow band of small pools. I am not claiming this alone improves decentralisation. A No, though, keeps a floor that now works against small pools, with nothing better until a minimum margin comes in by hard fork.

Primary rationale
OpenZeppelin's security record is not the issue, and Intersect has set this up properly: milestone payments it verifies, an independent oversight committee, automatic sweep-back of unused funds.

I am voting No mainly because the treasury has already funded part of this work and the proposal does not say so. In May 2026 DReps approved Input Output's Developer Experience Initiative, which includes an OpenZeppelin-style contracts library now in development. This proposal says Cardano has no standardised, audited contract library and mentions neither that work nor the other libraries in the ecosystem. An 11.79M ada request should start from what exists and explain what it adds.

I also cannot rebuild the cost. Delivery is five equal payments of 2,288,750 ada with no roles, headcount or day rates. The contract language, which drives staffing, audit method and maintenance, is picked after funding, and 20% goes out at signature before anything is delivered.

S&P Global's agreement to buy OpenZeppelin came after the proposal was written, and there is no disclosure or change-of-control provision. Nothing improper in that, but the counterparty has materially changed.

A Yes would fund a second library before the first is delivered and compared, on a budget I could not check. My No has a cost too: the work does not start on this timeline, and OpenZeppelin may not come back.

I abstain, and I want the reasoning on record because an abstention on a memorial action is easy to misread.

Fabian von Bergen's contribution to Cardano is not in question. He was an ITN era participant, ran the Tempus (TMS) stake pool, was an ambassador from the earliest days of the program, and was a steady, honest presence on the Cardano Forum for years. He passed away in January 2026. If the only question in front of me were whether he deserves recognition from this network, my answer would be yes without qualification.

I am abstaining because two deserving names are in play for the same upgrade and there is no agreed procedure for reconciling them. The Hard Fork Working Group has signalled it intends to name the first Dijkstra hard fork after Alexander Esgen, whose Peras work sits inside the release. This action proposes von Bergen. Both claims are defensible and neither has been measured against a written standard, because none exists. A DRep tally is not the right instrument for settling that, and I would rather say so openly than bury it inside a vote either way.

I would also note that commemorative naming is arriving faster than upgrades can absorb it. That is worth addressing in advance rather than one contested action at a time.

Vote

Abstain

Problem / objective

The Protocol Version 12 hard fork, the first release of the Dijkstra era, needs a name. Cardano has increasingly used its naming convention to memorialize contributors who died while active. This action asks the DRep body whether Fabian von Bergen should be that name. It does not itself name the fork. It records DRep sentiment and passes that to the Hard Fork Working Group and the Technical Steering Committee as input.

Proposal approach

An Info Action carrying the proposed name and a written dedication in the metadata. Info actions enact nothing and carry no ratification threshold. The output is a permanent, publicly verifiable tally of DRep, SPO and Constitutional Committee positions. This mirrors Protocol Version 11, where the info action "Name Protocol Version 11 hard fork - van Rossem" carried 83.62% DRep support representing 4.44B ada.

Evidence reviewed

• Proposal metadata anchor at str8pool.com and its on-chain hash
• Governance action record on gov.tools
• Intersect weekly updates #122 (31 July 2026) and #123 (7 August 2026): Hard Fork Working Group intends to name PV12 after Alexander Esgen, with an In Memoriam section in the metadata for other recently departed contributors, and acknowledges this von Bergen action
• Cardano hard fork naming history: Byron, Shelley, Allegra, Mary, Alonzo, Vasil, Valentine, Chang, Plomin, van Rossem
• van Rossem naming action outcome and PV11 activation on 18 July 2026
  Cardano Forum records for the Tempus (TMS) stake pool and the SPO interview series confirming Fabian's ambassador and SPO status since 2018
  Intersect Technical Steering Committee minutes evidencing Alexander Esgen's Peras work

Benefits / expected impact

The action gives the community a formal opportunity to recognize a long serving contributor, and it shows that a community member can put a substantive question on chain without a working group sponsoring it. It has also surfaced something that was not visible before: Cardano is now choosing between commemorative names with no criteria for doing so. That gap is easier to close now, while the stakes are low, than it will be later.

Cost / funding analysis

No treasury request. No funds move. No protocol parameter changes. The only costs are the proposer's deposit and the attention the vote takes. The whole weight of this decision sits in what the record establishes.

Risks

An abstention on a memorial action can be read as a comment on the person. That is the main risk in my position and the reason this rationale is published in full.

A supportive tally the Hard Fork Working Group later sets aside would leave a visible record of DRep sentiment being solicited and then ignored. That does not help confidence in the governance layer.

Resolving competing names by tally, with no criteria, risks establishing that naming outcomes turn on timing and visibility. That is a poor precedent to set by accident.

Deferring pending a framework carries its own risk: frameworks deferred sometimes never arrive. I have tried to mitigate that by stating what I would support and on what terms. None of these risks are technical.

Tradeoffs

The strongest argument against my position is that the action asks a narrow question I could answer narrowly. Whether Fabian deserves the honour is answerable on its merits, and my answer is yes.

I have not voted that way because in a two name contest a Yes is not only an assessment of Fabian. It also ranks another candidate below him, and I have no principled basis for doing that. Esgen's Peras work sits directly inside the release this fork opens, which is its own kind of fit. I would rather state that plainly than fold it into a Yes and leave the reasoning unstated.

The second tradeoff is candour about frequency. Raising it risks sounding ungenerous toward people who are genuinely deserving. I have raised it anyway, because leaving it unsaid means the question gets settled by default.

Open questions / unresolved issues

Nothing is written down about who may propose a hard fork name, how competing proposals are reconciled, or what weight an info action tally carries once cast. Nor has the Hard Fork Working Group stated whether it treats such a tally as binding, advisory, or neither.

It is unclear whether the proposed In Memoriam section is meant as additional recognition or as an answer to naming questions. That has not been settled. The broader question stays open: what is commemorative hard fork naming actually for, and what recognition sits alongside it for contributors the naming cannot cover.

Conflicts / disclosures

None. No relationship, financial or otherwise, with the proposer, with str8pool, with the Tempus stake pool, or with Fabian von Bergen's family. No relationship with Alexander Esgen or with the Hard Fork Working Group. No compensation, solicitation or inducement of any kind connected to this vote.

Primary reasons

Fabian von Bergen's contribution is not in question and my vote is not a comment on it.
Two deserving names are before the community for one upgrade, with no agreed method for reconciling them.

A DRep tally is not the right instrument for ranking two commemorative claims with no criteria behind them.
Commemorative naming is arriving faster than upgrades can absorb it, and that is better addressed deliberately than one contested action at a time.

I would vote readily on a naming action brought under an agreed standard, including one carrying Fabian's name.

Final rationale

Cardano has chosen, repeatedly, to record in the names of its upgrades that infrastructure is built by people. It is one of the few cultural artifacts this network has produced that cannot be forked or bought. Protecting it now means being honest about a structural problem rather than voting past it.

Fabian von Bergen gave this community the kind of contribution that leaves nothing to point at: years of steady, honest presence, a stake pool, an ambassadorship dating to the earliest days of the program. That record speaks for itself and I am not weighing it here.

What I am weighing is that two people with real claims are in front of the community for one name, and nothing written down tells anyone how to choose. In that situation a vote does not express a judgement about merit. It expresses a preference, and preferences aggregated into a tally will look afterwards like a decision the community made on principle when it was not. I would rather abstain and say why than contribute to that.

The frequency question follows from the same place. Between Vasil, Plomin, van Rossem and now two candidates for the next upgrade, more contributors deserve recognition than there are upgrades to name. Intersect's proposed In Memoriam section reads as a response to exactly that arithmetic. This is not a reason to recognize fewer people. It is a reason to decide in advance what this specific honour is for, so recognition does not come down to which name reached the ledger first.

My thoughts are with Fabian's family and with everyone in this community who knew him.

Conditions / recommendations

I recommend Intersect and the DRep community produce a short written hard fork naming procedure before the next naming decision: who may propose, how competing proposals are reconciled, what weight an info action tally carries, and what recognition sits alongside the fork name for those it cannot cover. I will help draft it. With that settled I would vote on naming actions without hesitation.

I ask that the Hard Fork Working Group clarify whether the proposed In Memoriam section is meant as recognition alongside the fork name or as an answer to naming questions. The two are different and the distinction should be stated before the PV12 hard fork action is submitted.

I would support recognizing Fabian von Bergen in the Protocol Version 12 record on its own merits, separate from the naming question.

What would move me to Yes: an agreed naming procedure his claim can be assessed under, or confirmation that no competing name is being carried forward for this upgrade.

Date

2026-08-22