Formal Statement of Dissent on the Critical Integrations Proposal
A request to incorporate grassroots adoption tooling as protocol-level work
The Critical Integrations Proposal is now in voting, and given its authorship and institutional support, it is expected to pass. I acknowledge its technical necessity and the competence of the proposing teams. My intent is not to oppose the work, but to record a formal and constructive dissent regarding a strategic gap that this proposal does not address.
The proposal allocates substantial resources to protocol maintenance, wallet standards, ledger improvements, and infrastructure reliability. These elements are essential. However, it provides no corresponding investment in grassroots adoption tooling, particularly the frameworks needed for real-world community financial institutions such as Iddirs, Equbs, Chamas, SACCOs, Tontines, ROSCAs, Self-Help Groups, and similar structures across Africa, Asia, and Latin America.
These systems represent the largest existing decentralized financial networks globally, and yet Cardano still lacks:
- community treasury and rotating-savings modules
- emergency-fund and community-insurance primitives
- simple governance workflows for non-technical groups
- verifiable community membership and participation credentials
- diaspora-to-community financial rails
This omission has persisted across multiple funding cycles.
For this reason, I am voting NO, not to block the technical work—since it will proceed regardless—but to request a corrective measure:
Grassroots adoption tooling should be incorporated into this proposal, or delivered as a separate but parallel proposal by the same teams who maintain protocol-level integrations.
This work is not ancillary. It should be treated as part of Cardano’s core infrastructure.
Embedding grassroots tooling within the same organizational context ensures continuity, long-term maintenance, and ecosystem-level coordination. Treating it as protocol-level work also prevents fragmentation and reinforces the principle that adoption and infrastructure must evolve together.
In summary, my NO vote is a signal to ensure the historical record reflects this gap, and to encourage future budgeting—ideally by the same technical stewards—to balance protocol integration with the tooling required for real-world community adoption.