About
Objectives
To strengthen Cardano's decentralization and the integrity of its treasury and governance through fact-based, verifiable decision-making. I judge every governance action on its merits, weighed against the chain and the data themselves rather than narrative or authority, and I vote to keep power dispersed and to hold proposals — including treasury withdrawals and protocol changes — to evidence rather than promises.
Read moreShow less
Motivations
I run the BKIND stake pool and have operated on Cardano since its early days (participated in Shelley ITN), where I saw how concentrated or undisclosed stake can shape a network from the start. That convinced me governance must be transparent and verifiable, so I verify everything against the chain myself rather than take claims on faith. I register as a DRep to turn that verify-don't-trust stance into a governance vote. My belief is that a sustainable, expanding Cardano needs real diversity — decentralization of both stake and governance power — alongside high-quality, innovative, value-adding solutions for its stakeholders. That balance is the lens I bring to every proposal.
Read moreShow less
Qualifications
Stake pool operator (BKIND) and builder of independent Cardano infrastructure: a pure, from-scratch on-chain block decoder and ledger auditor that reconstruct chain state directly from the Ouroboros protocol without third-party indexers, plus audit systems for financial and metering data. Background in IT process and governance frameworks. I read CBOR, ledger rules, and on-chain evidence directly, and assess proposals on what the chain and the data actually show.
Read moreShow less
Governance record
- Yes4 (57%)
- No3 (43%)
- Abstain0 (0%)
No vote changes
Percentiles compare active DReps with at least five concluded actions since their registration. What these numbers mean
Recognition (4)
Activity
Want to see how your own views compare? Find a DRep who votes like you.
NoReduce minPoolCost to 75 adaSubmitted epoch 654View rationaleActive2d ago
BKIND votes No. At action 154 I opposed both the bundling and the cut. This resubmission resolves the bundling objection; the objection to the cut stands: it acts on the income of the operators it is meant to help, and repeats a 2023 reduction that left no trace. Re-measured at epoch 653.
Action: parameter change 75e7882a8ef2bc...dd9b#0, Reduce minPoolCost to 75 ada.
What is being decided. One parameter moves: minPoolCost from 170 to 75 ada. I verified the on-chain payload: only that change, with the correct predecessor reference and guardrails script. Without the bundled security parameter of action 154, SPOs cannot vote on this action; DReps and the Constitutional Committee decide alone.
I verified the document I am voting on. The blake2b-256 digest of the bytes retrieved from https://gateway.pinata.cloud/ipfs/bafkreidy6ftyudcx6lwkualmjbgkurhlqo35s6jarq3phxendcr5el6n34 equals the anchor hash recorded on chain, e32f6117912d810c82f0f153e7bf787024870ddb82601113e580c7d86bd8f384.
At action 154 I voted No with a full rationale on chain: I supported the Plutus memory increase, opposed this cut, and objected that one vote could not record both. The proposer has now unbundled the two, which is the form my rationale asked for, and I credit that. This vote is therefore about the cut alone.
The mechanism is unchanged since I analysed it at 154. The fixed fee recovers an operator's fixed costs, which do not scale with stake, and discloses those costs on chain; minPoolCost is read in exactly one place in the ledger, the validation that refuses a certificate priced below it. It stops underpricing and enables nothing else. The proposal expects market pressure to push declared fees down to the new floor: pressure to declare a fee other than what the pool costs to run, the behaviour the minimum exists to prevent. I do not object to revisiting the level. I object to converting a disclosure of costs into an instrument of price competition.
The measurement, re-run at epoch 653 across the 765 public operators (margin below 100%) whose pool earned a reward: removing 95 ada costs the median operator 21.2% of take-home income; the 233 operators declaring exactly 170 lose 39.2%; the lowest income class (88 operators) 52.1%, the highest (97 operators) 6.3%. The 98 pools at 100% margin are untouched, collected 66.1% of all operator income that epoch, and paid their delegators 1.8 ada in total. At 154 (epoch 645) these figures were 21.3, 38.7, 51.5, 6.2 and 67.8 percent: materially unchanged, on both of my independent data sources.
A small operator has two options and no third: match the lower fee and lose that income while the servers cost what they cost, or hold it and advertise a lower return to delegators who compare precisely that number. Competition on a fixed fee is competition in who can best afford to give up fixed income, and that is by construction the party who needs it least.
BKIND votes No. The form of this action is right; the mechanism inside it is unchanged, measured twice now, eight epochs apart, with the same result. I vote to keep power dispersed, and keeping the operators we have is part of that (govActionId 75e7882a8ef2bc...dd9b#0).
YesShould stakePoolTargetNum (k) be raised from 500 to 1000? (SPO poll)Submitted epoch 656View rationaleActive3d ago
BKIND votes Yes, as SPO and as DRep. Concentration is measured rising, the change is reward-neutral against a lovelace-validated formula, redelegation is proven cheap, and the active network holds six times the capacity needed. I vote to keep power dispersed.
Action: info action f6fd3678f12edc...cb4c#0, Should stakePoolTargetNum (k) be raised from 500 to 1000? (SPO poll).
What is being decided. This is an Info Action: it changes no parameter and has no on-chain effect. It asks whether sufficient SPO support exists to proceed with a later Parameter Change action raising stakePoolTargetNum from 500 to 1000. The document declares its own standard for reading the result, and how that standard should be interpreted is disputed in the community. That dispute does not touch this vote: an explicit Yes, cast with the pool's full stake, counts identically under every reading on the table.
I verified the document I am voting on. The blake2b-256 digest of the bytes retrieved from https://gateway.pinata.cloud/ipfs/bafkreia3u74dgyvg5v3u7wxwip44wwqzyhynqqm4wzyhkkwevaiynlihnm equals the anchor hash recorded on chain, ab85aad06200d7d7ec79181b68d0651083ffdd9b9bcd15c54212d4d681a9b680.
I take part in Cardano governance in two roles, as operator of the BKIND stake pool and as DRep. My registered DRep rationale commits me to two things: keeping power on this network dispersed, and holding every proposal to evidence rather than narrative (drep17x37hhwte...l2slp4, smitblockchainops.nl/governance/drep.jsonld). This vote applies both, and my position is unchanged since I registered: the Cardano ledger should be carried by a broad network of independently owned pools.
The evidence below is reproducible from cardano-db-sync and verified against my own independently built indexer.
Concentration is rising. The top-50 pools' share of active stake grew from 14.1% at epoch 400 to 18.2% at epoch 653, monotonically. 158 pools now control half of all delegated stake, down from roughly 198 at epoch 300. While k sits still, concentration has only one direction: up.
The pool register overstates the real network. 2,896 pools are registered (epoch 655), but only 1,339 produced a block in 2026. 1,495 registered pools produced nothing this year and none of their registered relay addresses answers as a Cardano node: I probed all 2,449 registered relay endpoints, with node-to-node handshakes on everything that accepted TCP; a handful of addresses still respond, but with a refused connection, a web server, or silence. Together these pools hold 0.21% of active stake. Claims about the size of the pool network should therefore be based on the 1,339 pools that actually produce, not on the register.
BKIND votes Yes. stakePoolTargetNum sets the number of pools the reward scheme steers the network toward, and it is the one lever with a measured track record of moving stake. It cannot by itself guarantee independent ownership, but a higher pool count is the precondition for a broader owner base, and while k sits still, concentration has only one direction: up. The measurements say the network needs this step. I vote to keep power dispersed, and this Yes is that vote (govActionId f6fd3678f12edc...cb4c#0).
NoUpdate Constitutional Committee 2026Decided epoch 654View rationaleEnacted20d ago
BKIND votes No, to stop this action. The election could have given the committee eight voting members and a six-hand constitutional check; the action fixes seven and five, and its abstract never says so. A five-for-five update with the audited candidates has my Yes. I vote to keep power dispersed.
Action: update committee 729daaf2f9f89f...0850#0, Update Constitutional Committee 2026.
What is being decided.
One action does three things: it removes three credentials from the constitutional committee (Cardano Atlantic Council, Cardano Japan Council, KtorZ), it seats four members with terms ending at epoch 799 (Marek Mahut, Philip DiSarro, Leandros BSP, Cardano Curia, the latter two re-elected), and it leaves the approval threshold at two thirds. Five seats expire at the end of epoch 653 and four are refilled, so the committee goes from eight seats to seven. The three members whose terms run to epoch 726 are untouched. (One of the eight current seats has stood vacant by resignation since epoch 597; I return to what that means for the count in section 2.)
I verified the document I am voting on. The blake2b-256 digest of the bytes retrieved from ipfs://bafkreif22553h3reaedrd376hzgkjng6kxnb3o7ycu3j4pzjbcjerv2bce equals the anchor hash recorded on chain, 6014f3e6c052eb1e83ce344bda1ee5262000a83d1d1aa62d63726d91316e6647. The credentials and expiration epochs in the document match the on-chain payload entry by entry. The action's predecessor reference, 4dab331457b61b...b704#0, is indeed the last enacted committee action, enacted at epoch 602; the one committee action submitted in between expired at epoch 607 without ratification. The term arithmetic holds: 799 minus 653 is 146 epochs, exactly committeeMaxTermLength, and the document's explanation of why the action can therefore only be ratified in its final epoch is correct.
I also verified the committee's current voting composition, because the objection below turns on it. The committee holds eight seats today, established by two enacted actions: the committee action enacted at epoch 581 seated seven members, and the committee action enacted at epoch 602 seated an eighth, Cardano Curia. One of those eight, Cardano Atlantic Council (cold credential 349e55f8...), resigned its seat on chain in epoch 597; that is the only committee resignation in the chain's history, recorded 2025-11-26 and cross-checked against a second, independent decode. The seat remains in the committee map but, by committeeAcceptedRatio, a resigned member is excluded from both the numerator and the denominator of every vote. The working committee has therefore been seven voting members since epoch 602, and six for the interval between the resignation and Curia's seating. This fact governs how I state my objection, and I state it against the fact rather than around it.
- What I support.
The chamber must be renewed or it stops working: committeeMinSize stands at 5, and without this action the committee falls to three members at the end of epoch 653. An election was held, with open candidate registration, a published timeline, and results audited by a third party. Two sitting members were confirmed in their seats and two new members were elected. None of that is my objection, and had this action refilled the seats it retires, it would have had my Yes.
- The objection this vote records.
The action retires five expiring seats and refills four, and the abstract never says so. It speaks of updating "the four Constitutional Committee seats" whose terms expire; in fact five expire, four are refilled, and one seat is left empty. That empty seat is Cardano Atlantic Council's, the member who resigned in epoch 597: the action removes a seat that has been vote-empty since epoch 597 and does not restore it. The reduction of the committee's ratified size from eight seats to seven is visible only by counting the names in two tables, and the abstract does not state it.
Seven seats at a two-thirds threshold is the more concentrated of the two chambers this election could have produced. Seated five for five, with the audited fifth candidate alongside these four, the committee would have held eight voting members, and approval of a constitutional change, a treasury withdrawal or a hard fork would have taken six hands, for the first time in the committee's history. As submitted, the action fixes seven voting members and a five-hand check through epoch 799, each seat weighing a seventh instead of an eighth. Choosing the smaller chamber, and choosing it silently, is the objection this vote records.
Two facts have to be stated against overreading that objection, and I state them myself. First, because Cardano Atlantic Council resigned in epoch 597, committeeAcceptedRatio in Ratify.hs lines 143 to 163 has excluded that seat from every count since: a resigned member leaves both numerator and denominator, so the working committee has been seven voting members, and the working bar five of seven, since epoch 602, and six members in the interval before Curia's seating. This action lowers no bar that operates today. Second, the eight-seat committee ratified at epoch 602 already contained the resigned seat, and no committee in the chain's history, the interim committee included, has held more than seven voting members. The eight-member chamber is therefore not a past state this action abolishes; it is the option this election put within reach for the first time, and the action declines it. My objection is exactly that and no more: offered a more dispersed chamber and a less dispersed one, the action fixes the less dispersed, for two years, without saying so.
The eighth seat did not have to stay empty. The committee's seat count was last set by a ratified vote at the committee action enacted in epoch 602, which brought it to eight; the seat Cardano Atlantic Council had resigned in epoch 597 was already vacant within that eight; and the 2026 election was the moment to fill it. The election's fifth candidate, the Asia Africa Cardano Coalition, polled 1,142,561,765 ada of voting power, 146 million ada behind the fourth seat, ready to be seated; I verified the election tally in full, ballot by ballot against the chain, as set out under Sources. Instead the action refills four of five expiring seats and fixes a seven-member committee in place through epoch 799, a term of some two years. The chamber's size was decided by the election working group, off chain, when it opened four seats against five expiries; the choice between eight voting members and seven was never put to the voters of this election, on chain or off. The only ratified parameter vote touching committee size, the change enacted at epoch 643 that lowered committeeMinSize from 7 to 5 (c75bb221...#0), rules itself out as that ballot in its own text: it "does not directly affect the current number of Committee members", nor does it "imply that reducing Constitutional Committee size is desired". It is, by its own description, an operational buffer, not a mandate for a smaller chamber. An earlier proposal of the same change was dropped at epoch 614 without ratification.
My DRep registration states my mandate in one sentence: "I vote to keep power dispersed." An eight-member chamber disperses the constitutional check across more hands than a seven-member one, and this election put both within reach. A Yes on the action that fixes the more concentrated of the two, unannounced and unasked, is not a vote I can cast under that sentence.
- Two questions, one button.
This is the same structure I voted No on at action 154, where a fee-floor cut I opposed was bundled with a memory increase I supported. Here the bundle is renewal, which I support, and reduction, which I oppose. The vote admits no separation: Yes endorses the reduction, No is recorded against the renewal, and abstention, because abstained stake leaves both numerator and denominator, helps the action pass without saying anything at all. No reading of the counting rules produces a vote that says what I mean, so the rationale must carry what the ballot cannot.
The contradiction deserves to be named in full, because every voter on this action faces it: passage fixes the more concentrated of the two reachable chambers, failure halts essential governance for an unbounded time. Whichever way the vote falls, one of the two goes under. That choice was constructed by bundling the two into one action; it is not a law of nature, and a five-for-five update would have dissolved it entirely. My vote answers the half my mandate binds me to.
- What this No is for, and what it costs.
I vote No because I want this action, in this form, not to pass. I am precise about what that means, because the consequence of failure is serious and I do not wish to be misread as dismissing it.
Under the ledger's counting rules a DRep who does not vote counts as No, and a pool that does not vote counts as No unless its reward account delegates to the always-abstain DRep. My stake is therefore counted against this action whether I speak or not; what casting the vote adds is that the opposition is voted rather than silent, on the record and argued, and that other voters can weigh these arguments and join it. Recounted at cast time, 31 August 2026, in epoch 652: the action stands at 66.2% weighted Yes on the DRep side against a threshold of 0.67, and at 39.9% on the SPO side against a threshold of 0.51. Of the stake counted as No on the DRep side, only 12 million ada is a voted No; 1,561 million ada is 233 registered DReps who have not voted, and 150 million ada is the always-no-confidence DRep. On the SPO side, 219 pools holding 4,480 million ada have voted Yes, one pool holding 60 million has voted No, and 6,684 million ada of pool stake has not voted.
If the action fails, the consequence is the one CIP-1694 states: with the committee below its minimum size, "the constitutional committee will be unable to ratify governance actions." Parameter changes, hard forks, treasury withdrawals and constitutional amendments would wait until a new committee action passes, and nothing in the protocol forces that repair or sets its date. I know that price and I vote No with it in view, because the remedy for a failed committee update is not this committee update again: it is a corrected one. Committee actions need no committee approval, so that road stays open even with the chamber below strength, and a replacement that seats five members for five expiring seats, with the audited fifth-placed candidate alongside these four, repairs the committee without shrinking it. The freeze lasts exactly as long as it takes to submit and ratify the version that should have been submitted first.
Sources.
The committee's current composition, the expiring seats, the predecessor action and its expired sibling, the epoch-597 resignation of Cardano Atlantic Council (the only committee resignation in the chain's history), the protocol parameters cited (committeeMinSize 5, committeeMaxTermLength 146, the 0.67 and 0.51 thresholds, the two-thirds committee threshold), and the vote tallies were measured on a cardano-db-sync instance and cross-checked against an independent from-scratch decode of the chain bytes. Both sources return the same current committee, eight seats of which Cardano Atlantic Council's is recorded resigned, and the same single resignation at epoch 597. Both sources also return the same committee actions (seven members seated at epoch 581 in place of the interim committee, one member added at epoch 602, one proposed addition expired unratified at epoch 607) and the same single resignation; the interim committee's seven seats are confirmed by the Conway genesis file itself and by the genesis-derived state in db-sync. Together these give the membership history behind section 2: at no point has the committee held more than seven voting members. The two sources agree, voter by voter, on the cast votes reported in section 4; those counts are the cast-time recount of 31 August 2026, in epoch 652. The sources agree on the weighted SPO tally to the displayed digit. On the DRep side they agree to within rounding, with one classified difference found and explained: one DRep holding 14 thousand ada is recorded as expired in one source and active in the other, an expiry-refresh difference that does not move the percentages. The DRep weights for epoch 652 exist in db-sync only; the same method on both sources at epoch 651 agrees as stated. The committee counting rule is cited from cardano-ledger-conway-1.22.1.0. The committeeMinSize parameter change (7 to 5, enacted epoch 643) and the quotations from its anchor document were verified against the document's on-chain hash. The off-chain election tally I verified in full. All thirty-eight ballots in the published audit bundle were retrieved by content identifier, and each matches its blake2b-256 hash in the bundle's own ledger; the per-candidate head count matches the published result exactly; every ballot carries a valid ed25519 signature over the ballot's own content; on thirty-seven of the thirty-eight, the signing key's blake2b-224 digest is the voting DRep's on-chain credential, the thirty-eighth being a script DRep whose link to its ballot rests on the voting platform's account layer; and summing each voter's on-chain DRep stake at the epoch-645 boundary, the announced snapshot of 23 July 2026, reproduces the proposal's voting-power table to the lovelace for all ten candidates, independently on both chain sources. Two limits remain. Completeness is not provable from the published data: the bundle proves that every published ballot is genuine, not that every cast ballot was published. And the published results file itself states a voting power of zero for every candidate; the quantity that decided the seats is reproducible only by redoing the computation against the chain, as done here. Election dates and the audit attribution are taken from the proposal document.
BKIND votes No, and votes No to stop this action.
The candidates are not the objection and the renewal is not the objection. The objection is that this election could, for the first time in the committee's history, have widened the constitutional check on every parameter change, treasury withdrawal and hard fork to eight voting members and six approving hands, and that this action instead fixes seven members and five hands for a full term (the seat vote-empty by resignation since epoch 597 retired rather than refilled), inside an action whose abstract never mentions it, while an audited fifth candidate stood ready. The ballot offers no way to consent to the renewal without consenting to that choice. Against today's depleted chamber the bar does not move; against the chamber this election put within reach, the check stays narrower by one hand, for two years, by a choice made off chain and put to no ballot. Silence would be counted as No just the same, but silence shows no one why. A committee update that seats five members for five expiring seats, with these candidates, brings the chamber to eight and has my Yes the day it is submitted. I vote to keep power dispersed, and this No is that vote (govActionId 729daaf2f9f89f...0850#0).
NoReduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)Decided epoch 653View rationaleExpired23d ago
BKIND votes No. I support the Plutus memory increase and oppose lowering minPoolCost from 170 to 75 ada; this action does not let me record both. The cut acts on the income of the operators it is meant to help, reaches 0.3% of delegated stake, and repeats a 2023 reduction that left no trace.
Action: parameter change ab474223d40e2e...a306#0, Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2).
What is being decided.
One action changes three values: minPoolCost from 170 to 75 ada, maxTxExUnits.mem from 16,500,000 to 17,500,000, and maxBlockExUnits.mem from 72,000,000 to 77,500,000. The steps fields are unchanged from their current values. ExUnits is a single parameter with two fields, so the proposal is correct that nothing else moves.
I verified the document I am voting on. The blake2b-256 digest of the bytes retrieved from ipfs://bafkreifc5ct5fpeu4ygx6k4cqzbyzny7xfmuljywgn7jge3zkf2tidacym equals the anchor hash recorded on chain, f200d39e39a3db74bdaa4f04865b4da38b5403322984c6fdcaf09bd44cacf868.
- What minPoolCost is.
Two distinct things have to be kept apart, because the proposal acts on only one of them. The fixed fee is the per-pool value each operator declares in its registration certificate. minPoolCost is a single network-wide protocol parameter that sets the minimum the fixed fee may take. The proposal does not remove the fixed fee. It lowers the minimum the fixed fee is allowed to be.
The fixed fee does two things, and both are visible in the design. It recovers the operator's fixed cost: in Rewards.hs lines 122 to 127 the declared fee is subtracted from a pool's rewards before the margin is applied to the remainder, and where the reward does not reach the fee the operator receives the whole of it. Fixed costs do not scale with stake, so they are settled first. It also discloses that cost to delegators, because the fee is declared per pool in the registration certificate on chain rather than set once network-wide, so every operator states what running their pool costs them.
minPoolCost protects both functions by putting a floor under the fixed fee. Pool.hs line 256 refuses a certificate whose declared fee is below minPoolCost. In the whole of the Shelley and Conway source, ppMinPoolCostL occurs exactly once outside the parameter definition, and that is the line. Nothing tests an upper bound. The minimum therefore adds no option to an operator who wants to charge more. It only stops one who would price the fee below their own cost to attract stake.
The proposal uses the minimum for the opposite purpose. It expects that market pressure will lead small pools currently declaring the minimum to lower their declared fee to the new, lower minimum, improving their competitiveness. That is pressure on operators to declare a fee other than what their pool costs them, which is the behaviour the minimum exists to prevent. The information a delegator can read from the fixed fee lies in its variation across pools, and a minimum that competition obliges every small pool to sit on discloses nothing.
I do not object to revisiting the level of the minimum. I object to converting the fixed fee from a disclosure of costs into an instrument of price competition, which is what the stated mechanism requires.
- Two unrelated changes in one vote.
I support the Plutus memory increase and oppose the fee-floor reduction. This action does not let me record both, and no reading of the counting rules produces a vote that says what I mean.
The two subjects are unrelated, and the proposers say so: these two changes are otherwise unrelated, one lowers the stake pool fixed-fee floor, the other increases Plutus script execution headroom. The ledger keeps them apart as well. cppMinPoolCost sits in the Economic group and is read in one place only, Pool.hs line 256, when a pool certificate is validated. cppMaxTxExUnits and cppMaxBlockExUnits sit in the Network group and are applied when transactions and blocks are validated.
Yet the vote admits no separation. Yes endorses a reduction I consider unjustified. No is recorded against a memory increase I support. Abstaining is worse than it looks: under Ratify.hs line 277 abstained stake leaves both the numerator and the denominator, so withholding support raises the yes-ratio instead of lowering it. On the tally of 28 August 2026, epoch 652, the proposal stands at 59.5%, and had the ten abstaining DReps voted No it would stand at 58.3%. That gap has narrowed sharply, from 8.8 percentage points a day earlier, because two of the largest abstaining DReps, holding 786 million ada between them, changed their vote to Yes on 28 August. The mechanism is unchanged, but the stake that carried that effect has moved into the numerator. This is a snapshot of an open vote: across epochs 648 to 652 the yes-ratio has climbed from 22.7% to 59.5% as support accumulated, and the action remains active until it expires at the end of epoch 653. The bar it must clear is 0.67, not a simple majority.
The two halves also carry different risk. A memory limit reverts cleanly: it is applied at validation, so restoring the old value restores the old behaviour from the next block. minPoolCost does not. Pool.hs line 256 checks it only when a certificate is submitted and never re-applies it to registrations already on chain. The proposers state the consequence themselves: SPOs who lower their declared cost below 170 ada while the floor is 75 ada cannot be compelled to raise it back to 170 ada if the parameter is later reverted. One reversion plan is presented for both halves, and it lends the reversibility of one to the other.
The reasons given for combining them do not carry that cost. The proposers cite submission efficiency and a wish to allow SPOs to give input on minPoolCost. The 100,000 ada deposit is returned to the proposer under Epoch.hs lines 195 to 199, and governance actions run concurrently, with two submitted in epoch 646 alone, so a separate submission costs no additional ada and no additional time. On the second reason: minPoolCost carries the tag NoStakePoolGroup, for which paramChangeThreshold returns NoVotingAllowed under Internal.hs lines 395 to 402. Attaching maxBlockExUnits, a SecurityGroup parameter, gives stake pools a 51% vote on their own fee floor that the ledger withholds from them. The proposers acknowledge this is a consequence of bundling rather than a requirement of PARAM-05 itself.
That this can be done separately is not speculation. Part 1 of the same memory increase, action c21b00f90f18fce4003edf42b0b0d455126e01c946e80cc5341a9f9750caf795 index 0, the identical two parameters, submitted alone, was ratified at epoch 613 and took effect at epoch 614, with 225 DReps in favour, 4 against and 6 abstaining.
- The measure works against the operators it names.
This is my central objection.
The stated purpose is to improve the position of small pools. The instrument is those pools' income.
Because the fixed fee is deducted before the margin, a large pool's income is the margin on tens of millions of delegated ada and the fixed fee is a rounding error, while for a small pool the fixed fee is the income. The declared margins show it: the median runs from 1% in the smallest size band to 4% in the largest, and in the group already sitting on the current floor it is 1.5% on 4.6 million ada of stake.
That asymmetry decides who can afford to compete on the fee. Measured on the actual leader rewards at epoch 645, across the 752 pools that declare a margin below 100% and actually earned a reward that epoch, so that their delegators receive something, removing 95 ada from an operator's declared fee costs the median public operator 21.3% of the income the operator takes home. For the operators already declaring 170 ada it costs 38.7%. For the lowest income class, 84 operators, it costs 51.5%. For the highest income class, 95 operators, it costs 6.2%. And for the roughly 98 pools that declare a 100% margin it costs nothing at all.
Those last pools are not a rounding error in the ledger's accounts: they collect 67.8% of all operator income on the network. At epoch 645, 91 of the 98 paid their delegators nothing whatever, and all 98 together paid out 3 ada. For them the fixed fee is irrelevant, because they keep the entire reward either way.
A small operator then has two options and no third. Match the lower fee, and lose that income while the servers, the bandwidth and the time cost exactly what they cost today. Or hold the fee, and advertise a lower return than the pool beside it, to delegators who compare precisely that number. There is no branch on which the position improves. Competition on a fixed fee is competition in who can best afford to give up fixed income, and that is by construction the party who needs it least.
The obvious rejoinder is that a lower fee attracts delegation, and the margin on that new stake repays the fee it gave up. For these pools it does not. Among all 2,541 public pools declaring a margin below 100%, which is the wider population of which the 752 measured above are those that also earned a reward at epoch 645, the median margin is 1.5%, and among those below the viability threshold a quarter declare exactly zero. At a margin of 1.5%, and at the epoch-645 reward rate used below, replacing 95 ada of forgone fixed fee each epoch would take roughly 22 million ada of fresh delegation, just over a quarter of a saturated pool, on a pool defined by having almost none. At zero margin no delegation repays it at all. The attraction is in any case largely zero-sum: stake drawn to one small pool is stake another loses, and what little could come from the handful of saturated pools need not land on one this small, and saturation caps what any single pool can hold in any case. The rejoinder ends where it began: the fixed fee is the income.
The margins involved are not abstract. Of the 1,406 pools that produced a block in 2026, 159, which is 11.3%, produced one block a month or less, and 213, which is 15.1%, produced no more than about one and a half blocks a month. For the pools that make about one block a month, the median operator income over epochs 605 to 645 works out at 2,715 ada a year, and at the ADA price on 28 August 2026 that is about 566 US dollars, before a single hosting invoice. Over those same forty epochs the number of pools paying their delegators anything at all fell from 830 to 752.
One further point the proposal never addresses. The minimum is denominated in ada, and the costs a fixed fee at the minimum exists to cover are not. minPoolCost was set to 170 at epoch 445, on 27 October 2023, when ada traded near 0.29 US dollars, so a fixed fee at the minimum then recovered about 49 dollars. At the ADA price on 28 August 2026 it recovers about 35, more than a quarter less in real terms, which no one ever voted on. The cut to 75 takes it to about 16. The proposal removes 56% of the nominal amount on top of an erosion the exchange rate had already delivered, and it mentions the rate nowhere. The figures are 170 ada at 0.2895 US dollars on 27 October 2023, close from Yahoo Finance, and at 0.2085 US dollars on 28 August 2026, spot from CoinGecko and matched by Coinbase. The change to the minimum is on chain at epoch 445.
- The reduction acts on a variable that is not the constraint.
The proposal presents the reduction as preparatory: a healthy ecosystem of smaller pools must be economically viable before any future k increase is effective, so improving small-pool economics via this reduction is a prerequisite step, not an alternative. That makes k the destination and the fee floor the road to it. The two can be measured against each other.
A pool covers its cost when its rewards exceed its fixed fee. At the measured epoch-645 rate of 0.00028954 ada of reward per ada of stake per epoch, that threshold sits near 587,000 ada of delegation at a minimum of 170, and near 259,000 ada at a minimum of 75. Measured at epoch 650: 1,511 pools sit below 259,000 ada and are still short of the floor even at 75, of which 154 produce blocks, holding 42 million ada between them. A further 153 pools sit between 259,000 and 587,000 ada and are the ones this change brings above the floor, of which 130 produce, holding 64 million ada. And 1,016 pools sit above 587,000 ada and are already above the floor at 170, of which 995 produce, holding 21,406 million ada.
The reduction changes the arithmetic for 153 pools holding 64 million ada between them, which is 0.3% of all delegated stake, and 130 of those already produce blocks. Ten times as many pools remain below the threshold even at 75 ada.
stakePoolTargetNum moves quantities of a different order. Saturation is circulation divided by k, currently 77.6 million ada, and only 7 pools stand above it, with 101 million ada in excess. Raising k to 750 would place 154 pools above the line and put 2,504 million ada, which is 11.6% of all delegated stake, under pressure to move, and at k equal to 1,000 it would be 4,908 million.
That is not a projection. k has been changed once, from 150 to 500 at epoch 234 in December 2020. At epoch 233 not one pool of 1,276 stood above saturation. One epoch later, 74 pools held 3,638 million ada above the new line. By epoch 239 the excess was 261 million and by epoch 244 it was 101 million: 93% of it moved within five epochs, about twenty-five days.
The number of producing pools rose from 537 at epoch 233 to 858 at epoch 250 over the same window. I do not attribute that growth to the change, because the ecosystem was expanding and the producing count was already climbing by roughly 2.5% per epoch beforehand. What is directly attributable is the drain itself, because that stake sat above the new ceiling the moment it was lowered.
Set the two side by side. The step described as a prerequisite reaches 0.3% of delegated stake. The change it is said to prepare for has already, once, moved 3.6 billion ada in a month. k has never been proposed: of the eight parameter-change actions in Cardano's history, none contains stakePoolTargetNum and none contains poolPledgeInfluence. k has stood untouched for 416 epochs. It carries the tag NoStakePoolGroup under PParams.hs line 660, so operators have no vote on it in that capacity either.
One qualification belongs here. Stake displaced from saturated pools goes wherever delegators send it, which need not be to small pools. The figures bound what could move, not what would. They establish the order of magnitude, and it is not the fee floor.
A correction on a related point. The proposal states that the reduction has a marginal effect on the treasury. The treasury take is computed as deltaT1 equals tau times rPot in PulsingReward.hs lines 138 to 141, before any pool-level distribution occurs, so the treasury draws the same amount from the reward pot either way; what lowering the minimum changes is only the split between operator and delegator inside the remainder. The one channel by which that split touches the treasury at all is third-order, through rewards forfeited by deregistered accounts under IncrementalStake.hs line 121, and it is a speck, not the marginal effect the proposal describes.
- The 2023 reduction left no trace.
minPoolCost was halved once already, from 340 to 170 ada at epoch 445 in October 2023. That is the one place where the proposal's mechanism can be checked against outcome rather than expectation.
Counting for each calendar year the pools registered and not retired at year end, and how many of them minted at least one block that year: in 2020, epochs 208 to 238, 1,486 pools were active at year end and 971 of them produced at least one block, 65.3%, with 1,065 pools producing a block at some point in the year. In 2021, epochs 239 to 311, 3,151 were active and 1,927 produced, 61.2%, with 2,210 in all. In 2022, epochs 312 to 384, 3,216 were active and 1,854 produced, 57.6%, with 2,036 in all. In 2023, epochs 385 to 457, 3,113 were active and 1,688 produced, 54.2%, with 1,873 in all. In 2024, epochs 458 to 530, 3,039 were active and 1,501 produced, 49.4%, with 1,617 in all. In 2025, epochs 531 to 603, 2,948 were active and 1,421 produced, 48.2%, with 1,513 in all. And in 2026 so far, epochs 604 to 650, 2,896 were active and 1,336 produced, 46.1%, with 1,406 in all.
2020 covers 31 epochs from the Shelley start and is not comparable, because d was still 0.32 at the end of that year, so most blocks came from federated nodes. 2026 covers 47 epochs rather than a full 73.
The registered population has been broadly stable. The producing population has not: from 2,210 in 2021 to 1,406 so far in 2026, while total block production stayed flat at roughly 1.5 million per year. The same blocks are made by steadily fewer pools.
Around the change itself, nothing happens. The ten-epoch means of the per-epoch count of producing pools run 1,127 over epochs 425 to 434, 1,111 over 435 to 444, 1,088 over 445 to 454 with the new floor in force, then 1,090, 1,078, 1,079, 1,086, and 1,084 over 495 to 504. That is flat for sixty epochs afterwards, within the band it occupied before.
And most pools never followed. Of the pools that produced a block in the last twenty epochs, 59.3% still declare 340 ada and 30.0% declare 170. 205 epochs after the floor was halved, the majority of producing pools have never moved to it, and those that did are disproportionately the smallest: 43.4% of producing pools below 1 million ada of stake declare 170, against 17.3% in the 10 to 30 million band.
I make no causal claim here, and I tested two and discarded them. The decline in producing pools does steepen, but only from around epoch 505, ten months after the change, and the apparent break disappears entirely under a 60-epoch window. New pools entering production did fall by 61% after the change, but new registrations fell by 57% over the same period and the ratio between them barely moved, so that fall belongs to people no longer starting pools rather than to the floor.
What remains does not depend on attribution. The reduction produced no visible improvement in the population it was aimed at, on any measure available: not in the number of producing pools, not in the output of the pools that adopted it, and not in how many chose to adopt it. A second reduction is now proposed on the strength of a mechanism whose first application left no trace.
Sources.
Every figure above comes from an independent decode of the chain bytes, measured at epoch 650 unless stated otherwise, and every source reference is to cardano-ledger-conway-1.22.1.0 and cardano-ledger-shelley-1.18.1.0. Each figure was then checked, row by row, against an independent cardano-db-sync instance: a different decoder, a different ledger replay, a different schema, written by IOG. The two agree exactly on the declared cost, margin and pledge of all 6,161 pools, on 5,376 rows of per-pool stake at epochs 645 and 650, on 1,849 rows of per-pool block counts, on the leader and member rewards of all 904 pools that earned anything at epoch 645, on the DRep stake distribution, and on every one of the 256 votes cast on this action as of 25 August 2026. The comparison produced no differences at all. The single row db-sync holds that I do not is a 500 ada pool-deposit refund, which it records as a reward type and I do not. The live vote tally quoted earlier has moved past that cross-checked snapshot and is measured on db-sync alone, by a method that reproduces the doubly-checked series through epoch 651 to the lovelace. The queries behind each number are available on request, and I will supply them to anyone who wants to check a claim rather than take it on trust.
BKIND votes No.
The memory increase deserves to pass and would pass on its own, as its first half already did. The fee-floor reduction does not belong in the same vote, and on its own merits I would oppose it: it acts on the income of the operators it names rather than on their competitive position, it reaches 0.3% of delegated stake while the parameter that has demonstrably moved stake in this ecosystem is left untouched, and its first application in 2023 left no trace on the population it was meant to help.
A No here is not a vote against Plutus headroom. It is a vote against deciding two unrelated questions with one button, and against a measure whose burden falls hardest on the smallest operators and not at all on the largest (govActionId ab474223d40e2e...a306#0).
YesWithdraw 25,400,000 ada for Intersect: Governance coordination and technical ...Decided epoch 646View rationaleEnacted2mo ago
BKIND votes Yes on the treasury withdrawal that funds Intersect's governance coordination and technical stewardship for June 2026 to June 2027. Most of the ask, 18.8 million of the 25.4 million ada, funds the technical stewardship, incident response and release coordination that keep Cardano secure, the function that houses Intersect's Security Council and the Intersect Bug Bounty Program. As an independent Cardano auditor I judge that this security capability must continue, and that it should be strengthened to reach the third-party code now built across the ecosystem.
Action: treasury withdrawal b3d452bff7769d...0ccf#4, withdraw 25,400,000 ada to fund Intersect's governance coordination and technical stewardship for the Cardano ecosystem from June 2026 to June 2027.
I vote Yes. I judge this action as an independent Cardano auditor who reconstructs and checks chain state with my own software rather than taking it on authority, weighing both what the withdrawal funds and what this ecosystem needs.
Most of the ask, 18.8 million of the 25.4 million ada, is allocated to technical stewardship, incident response and release coordination, the work package that also carries the core Cardano repositories. That is the ecosystem's security and incident-response function. It houses Intersect's Security Council, the group facilitated by Intersect under its Technical Steering Committee that validates, triages and remediates vulnerabilities, and it operates the Intersect Bug Bounty Program that opened in November 2025. Funding this action keeps that capability standing. Of everything in this budget, the security function is the part I would least want left unfunded.
The reason is not abstract. In my own work as an auditor the security surface of this ecosystem is widening, not narrowing, as more value and more third-party code build on Cardano, and attackers grow more capable. The November 2025 chain partition made it concrete. A single malformed delegation transaction woke a deserialization bug that had lain dormant in the code since 2022 and briefly split the network into two chains. No user funds were lost and the network stayed online, but it was resolved in roughly fourteen and a half hours only because a coordinated incident response, spanning Input Output Global, the Cardano Foundation, EMURGO, Intersect, exchanges and hundreds of stake pool operators, shipped patched node versions and let Ouroboros settle the canonical chain. That coordination layer is exactly what this action funds. Without it, the next incident response has to be assembled only after the incident has already begun.
I vote Yes to keep this function, and I would go further: it should be strengthened. Early detection and safe, coordinated remediation of vulnerabilities should reach beyond the core node to the third-party code being built across the ecosystem, where a growing share of user value now sits. The Intersect Bug Bounty Program today scopes to the Cardano Core Node and Intersect-maintained repositories, with third-party contracts out of scope. Extending that reach, so that a flaw in a third-party contract is found early and closed safely rather than discovered by an attacker, invests in the resilience of the whole ecosystem and not only its core. Strengthening the security function is in that sense a decentralisation measure: it protects the many builders and users who now depend on this chain.
The ask is also proportionate. This 25.4 million ada withdrawal corresponds to a reduced annual budget, cut year over year from 7.875 million to 6.35 million dollars while preserving the critical functions, and it cleared Intersect's 2026 community budget process before it reached the chain. Funding a leaner request that protects the ecosystem's security is an easy Yes.
Operators and developers who want to compare notes on ecosystem security are welcome to email developmentbkind@gmail.com.
I vote Yes on the treasury withdrawal funding Intersect's governance coordination and technical stewardship (govActionId b3d452bff7769d...0ccf#4). The ecosystem's security and incident-response function must continue, and it should be strengthened to reach the third-party code built across Cardano.
Show 2 moreShow less
YesBlockfrost's transformation to not-for-profitDecided epoch 646View rationaleExpired2mo ago
BKIND votes Yes on Blockfrost's transformation to a community owned nonprofit. I judge it on what I can verify on chain: a single treasury transfer of the code, trademarks and domains into community ownership under an elected board. Usage figures I cannot independently confirm are left out.
Action: TreasuryWithdrawal 5439b614162543...9997#0, Blockfrost's transformation to not-for-profit, requesting the withdrawal of a total of 9,832,979 ada from the treasury.
I vote Yes. This treasury withdrawal is not a subsidy to a private company. It funds a single transfer of Blockfrost into community ownership, and for a DRep whose measure is decentralisation as mutual enablement, that is what the treasury exists for.
I judge this action only on what I can verify. The facts below come from the action's own data recorded on the chain and from the proposal metadata whose hash is anchored on the chain, both of which anyone can reproduce independently. I have deliberately left out the project's usage statistics, its request volumes, traffic share and free tier proportion, because I cannot independently confirm them. A rationale should rest on what can be checked, not on the proposer's own numbers.
What earns my Yes is the structure of the action itself. Blockfrost's source code, trademarks, and domains are committed to an independent nonprofit, governed by the community. It is to be directed by a board the community elects, with four seats for open source infrastructure teams and one open community seat, while Input Output steps back to a purely advisory role with no vote during the transition. The proposal also commits to publishing operating costs on a public dashboard under that board's approval. Its proposed path to sustainability has any future commercial tier run by the nonprofit, with profits returned to the Cardano treasury, turning this withdrawal from a gift into an investment the ecosystem can be repaid on.
Critics argue that an incumbent with prior ecosystem funding should not receive more, and that the treasury should not pick winners. Those are fair questions, and they argue for exactly this design rather than against it. Open accounting, community control, and an irreversible handover are the conditions I want attached to public money before it is spent, and this action attaches them. The alternative is to let this infrastructure quietly turn commercial again or decay.
A public good placed under community ownership, with its costs made open and its upside returned to the treasury. On that verifiable basis, I vote Yes.
I vote Yes on Blockfrost's transformation to not-for-profit (govActionId 5439b614162543...9997#0).
YesHard Fork to Protocol Version 11 ('van Rossem' Hard Fork)Decided epoch 644View rationaleEnacted2mo ago
BKIND votes Yes on the protocol-11 hard fork. The upgrade is ready by every measure I can verify myself on-chain: a rising supermajority of block production already signals protocol 11, measured by my own independent indexer and bit-exact verified against db-sync. I judge it on that evidence.
Action: HardForkInitiation fdd468da5cc4ac...344d#0 — upgrade to protocol version 11.0.
I vote Yes because the protocol-11 upgrade is ready by every measure I can verify myself on-chain. I judge this action on that evidence, not on advocacy or authority — consistent with how I registered as a DRep.
I do not take readiness claims on faith. The figures below were produced by my own independent indexer — software that reconstructs chain state from the network genesis and the live Ouroboros node-to-node protocol, decoding raw blocks itself, with no third-party indexer, API, or pre-built dump, and accepting each (slot, hash) only when a quorum of independent relays agrees. I then cross-checked every figure, bit-for-bit, against an independent db-sync instance.
Network readiness. The share of blocks signalling protocol 11 has risen monotonically from 49.9% (epoch 632) to 85.7% in the last complete epoch (638) and 86.7% in the current epoch (639). For all seven completed epochs, my independent indexer and db-sync report identical block counts — zero divergence. A rising supermajority of block production already runs protocol-11-capable software; enacting will not strand the network.
My own pool. BKIND has signalled protocol 11 since 10 May 2026 (epoch 630), on every block it has produced since, with no reverts. I do not ask the network to adopt what I have not already run myself.
Tooling built on protocol 11. Smit Blockchain Operations has built three air-gapped toolkits — SPO Tools, DRep Tools, and Wallet Tools — on the protocol-11 source, and exercised them live on Cardano mainnet (governance votes, DRep registration, delegations, payments). We encountered no issues attributable to the protocol-11 code. Their source and binaries will be released as open source for the community shortly.
On this evidence the upgrade meets my bar — verifiable readiness, not promises.
A constructive note to the protocol developers. Building an independent implementation is the most honest test of how completely a protocol is documented. We hit a meaningful number of edge cases with the same root cause: behaviour that is correct in the reference code but carries no inline documentation — for example SSC proof handling, reward-calculation timing, ledger-state diff APIs, value bounds, and hard-fork-combinator era boundaries. These are documentation gaps, not protocol defects. Because independent verifiability is itself a pillar of decentralisation, better inline documentation lowers the barrier to independent implementations and auditors — and is, in that sense, a decentralisation measure. Developers with questions are welcome to email developmentbkind@gmail.com.
I vote Yes on the protocol-11 hard fork (govActionId fdd468da5cc4ac...344d#0).
On-chain profile details
- DRep ID
- drep1ytc6...6c82l4eq
- Registered since
- Jun 22, 2026
- Last metadata update
- 3mo ago
- Data freshness
- On-chain data as of 2d ago