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
- Yes3 (100%)
- No0 (0%)
- Abstain0 (0%)
No vote changes
Recognition (3)
Activity
YesWithdraw 25,400,000 ada for Intersect: Governance coordination and technical ...Decided epoch 646View rationaleEnacted15d 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 b3d452bff7769d7f557ec6b8974760ee6c5e496c276652b654032966621e0ccf#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 b3d452bff7769d7f557ec6b8974760ee6c5e496c276652b654032966621e0ccf#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.
YesBlockfrost's transformation to not-for-profitDecided epoch 646View rationaleExpired21d 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 5439b6141625436ccf600f910bb0b3301b6288933a2cdf7939758848ae8b9997#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 5439b6141625436ccf600f910bb0b3301b6288933a2cdf7939758848ae8b9997#0).
YesHard Fork to Protocol Version 11 ('van Rossem' Hard Fork)Decided epoch 644View rationaleEnacted1mo 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 fdd468da5cc4ac8431dcd7e2b3211666c73bc229f85879469f67f1d9d51d344d#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 fdd468da5cc4ac8431dcd7e2b3211666c73bc229f85879469f67f1d9d51d344d#0).
On-chain profile details
- DRep ID
- drep1ytc6...6c82l4eq
- Registered since
- Jun 22, 2026
- Last metadata update
- 1mo ago
- Data freshness
- On-chain data as of 4d ago