IO & Midgard Labs: L2 Scalability Initiative
239 DReps voted · 88 with a rationale · 12 changed their vote
Open a row to read the rationale.
- Yes20.4M ₳No rationale
- Yes20.3M ₳No rationale
- Yes19.9M ₳Rationale
We are not done with Basho, the non-cannibalizing L2s of Hydra and Midguard are needed on Cardano to address a broad spectrum of high-performance applications and better support builders across both open and restricted trust environments.
Let's unleash the full power of eUTXO for our L2s with this. I thus vote YES! - Abstain17.3M ₳Rationale
IO & Midgard Labs: L2 Scalability Initiative
- No16.7M ₳Rationale
I’m voting NO because this proposal asks for ₳ 10 million while bundling multiple workstreams with different maturity and risk profiles, without providing the level of cost traceability and milestone evidence that a multi-million-ADA treasury withdrawal requires. At this scale, each major stream should stand on its own with explicit staffing/FTE counts and rates, a clear “definition of done,” and artifact-based acceptance evidence. Otherwise, governance cannot do proper price discovery or evaluate whether we are paying for research, prototyping, production hardening, or GTM assumptions under one umbrella. Bundling also reduces decision precision: a voter may agree with one component but not another, yet must accept or reject the entire package, which is not an appropriate governance structure for spending at this size. Beyond structure, L2 work creates long-term obligations (maintenance, operator economics, ecosystem integration) and therefore demands particularly strong accountability gates to avoid funding “potential” without clear delivery. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.
- No16.4M ₳Rationale
IO has been funded by a significant amount of premine tokens.
- Yes14.2M ₳No rationale
- Yes14.1M ₳No rationale
- No13.9M ₳Rationale
I am voting NO on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#4.
First, I don't believe I have a conflict of interest on this proposal. I am not set to receive any funds from the proposal, nor do I consider it a competitor to projects Sundae Labs is building. Some might see Midgard as a competitor to Gummiworm, for example, but neither Philip DiSarro nor I view it that way. In fact, we are working closely together to make sure that Midgard and Gummiworm complement eachother and integrate deeply; and we're currently working on a version of the SundaeSwap protocol that can be deployed to Midgard.
Given the above, and Sundae Labs history as the first company to successfully execute smart contracts on Hydra; the first company to demo a working application on Hydra; our open source contributions to Hydra; our involvement in the Hydra Doom project; and our role in the Glacier drop, Hydra has a place near and dear to my heart.
Unfortunately, I cannot vote Yes on this proposal. In particular:
- Continuing to invest heavily in Hydra has hit a point of diminishing returns. I believe that Hydra should be supported by and work at the direction of those who are building businesses on top of it. If funding is directed to Hydra, it should be in driving adoption in more businesses, not in continuing to iterate on the core.
- Hydra is not a suitable technology for most forms of DeFi; Despite the branding, for example, "Delta DeFi" is a (fantastic and useful) centralized exchange. By proposing that one of the deliverables here should be a "reference implementation for DeFi", I fear the proposal fundamentally misunderstands either Hydra or DeFi.
- The proposal is an Omnibus proposal, covering three workstreams that appear to only be tangentially related, in an effort to trade on the recognition and excitement for one to fund the other.
I would be far more supportive of a proposal that focused exclusively on the Data Availability solution hinted at in this proposal. Alternatively, I would support a Hydra specific proposal that focused on finding and supporting business that would be directly suitable for Hydra, such as business-to-business settlement, gaming, point of sale settlement systems via Maravedí, and driving improvements to the Hydra core based on direct engagements with said ventures and their revealed needs.
Ultimately, it's painful to vote no on this. Hydra has been a key inspiration for much of our ambition, and has the potential to unlock many exciting things for the Cardano ecosystem. However, I must vote my conscience, and after carefully considering this proposal, I believe this would take Hydra in the wrong direction and misallocate public resources.
You can find a larger writeup justifying my vote here.
- Abstain13.3M ₳Rationale
Agreed. A constructive ABSTAIN fits this case well.
The key nuance should be:
RCADA supports all three areas in principle and would likely have supported them if presented independently, but the combined proposal prevents differentiated assessment of workstreams with different maturity levels, risk profiles, and accountability concerns.
Here is a final rationale draft:
RCADA Rationale
RCADA votes ABSTAIN on the IO & Midgard Labs: L2 Scalability Initiative Treasury Withdrawal proposal.
RCADA supports the strategic direction of this proposal. Cardano needs credible Layer 2 infrastructure if it is to compete for high-performance use cases such as DeFi, AI-agent micropayments, gaming, consumer payments, and other applications that require faster finality, lower fees, and higher throughput than L1 can currently provide. We recognise that L2 development is not a rejection of Cardano’s base layer; it is a necessary complement to it.
We also support the three workstreams in principle.
Hydra production hardening is valuable and timely. Hydra has a distinct role in known-party, high-frequency environments, and the proposed work around performance optimisation, operational tooling, documentation, observability, DeFi reference implementations, and support for live adopters such as Delta DeFi and Masumi appears useful for the ecosystem.
The L2-agnostic infrastructure workstream also has merit. Shared data availability research and prototyping could help avoid future fragmentation and provide common infrastructure for current and future Cardano L2s.
Midgard is likewise a promising direction. A permissionless optimistic rollup designed around Cardano’s EUTXO model could meaningfully expand the range of applications that can build on Cardano, particularly open-participation DeFi and consumer-facing use cases.
If these workstreams had been presented independently, RCADA would likely have been supportive of each of them, while still providing specific feedback and scrutiny appropriate to their individual scope and maturity.
However, as a single bundled Treasury action, this proposal is weaker than several of the other infrastructure proposals we reviewed in this funding round.
The issue is not that the three areas are unrelated. RCADA understands why they were grouped together: they are all part of a coherent L2 scaling strategy and may share research, infrastructure, ecosystem coordination, and adoption pathways. Hydra, Midgard, and shared L2 infrastructure address different parts of Cardano’s scaling challenge and could reinforce one another over time.
The difficulty is that they carry different maturity levels and risk profiles. Hydra hardening is comparatively practical and connected to current production use cases. The data availability workstream is more exploratory and architectural. Midgard is strategically interesting but materially higher risk, particularly around the transition from a single-sequencer testnet toward decentralised multi-operator coordination. The proposal itself identifies this transition as a high-likelihood, high-impact technical risk.
This creates a governance problem. DReps are being asked to cast one vote across workstreams that deserve separate evaluation. RCADA cannot express support for the more mature Hydra work while separately applying stronger conditions to the more speculative or higher-risk components. An all-or-nothing vote reduces the quality of governance judgement, even when the overall strategic direction is sound.
RCADA also shares community concerns around delivery accountability, responsibility splits, prior milestone confidence, and budget granularity. The workstream-level budget is helpful, but the broader cost distribution still places 86% of the request under “Development,” which limits public review of staffing assumptions, contractor allocation, and precise cost attribution. Given the proposal’s reliance on multiple teams, live adopters, and future coordination structures, clearer public separation of responsibilities and acceptance criteria would have improved confidence.
We also note that the expected benefits depend partly on external adoption behaviour. The proposal explicitly identifies Delta DeFi and Masumi as important production validation partners and recognises that delays could put early adopters at risk. That is a reasonable ecosystem argument, but it also means the impact case depends on execution and adoption beyond the core technical deliverables.
RCADA does not want this abstention to be interpreted as opposition to Hydra, Midgard, or Cardano L2 scaling. Quite the opposite: we believe L2 development is important, and we want to see these efforts continue. Our abstention is a process and confidence signal, not a rejection of the technical vision.
A stronger proposal would separate the three workstreams or provide clearer internal gating, milestone-level cost attribution, responsibility mapping between IO and Midgard Labs, evidence of prior delivery status, and objective readiness criteria for Midgard progression. RCADA would be more comfortable supporting each workstream on its own merits with appropriate conditions attached.
For these reasons, RCADA votes ABSTAIN. We support the direction of travel and would likely support the individual components if separately proposed, but we cannot fully endorse the bundled structure, uneven maturity profile, and unresolved accountability concerns in this single Treasury action.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."
- No12.1M ₳Rationale
The primary reason for opposing this proposal is that Cardano has not yet fully realized or demonstrated the operational capacity of its Layer 1 despite years of research, development, and substantial treasury and ecosystem investment into L1 scalability initiatives as acknowledged in the proposal. The ecosystem is still waiting for major promised upgrades such as Leios, Peras, and other throughput and finality improvements that have repeatedly been presented as foundational to Cardano’s long-term scalability strategy. These initiatives remain largely in research, prototyping, simulation, or phased engineering stages rather than fully deployed and proven in production under meaningful ecosystem load. At the same time, the treasury continues to be requested to allocate very large sums toward additional L1 scalability efforts, including a separate ₳27.7M request focused on further expanding L1 capacity by IO. Under these conditions, it is difficult to justify another major treasury allocation toward an ambitious multi-layer L2 expansion before the ecosystem has fully evaluated the real-world capabilities of the upgraded base layer that the community has already heavily funded.
This proposal also introduces a sequencing problem that has not been adequately addressed. The proposal argues simultaneously that future L1 upgrades are still coming and that those upgrades will still not be sufficient for modern applications, thereby requiring accelerated investment into Hydra, Midgard, and broader modular scaling infrastructure today. However, because the future operational limits of upgraded Cardano L1 remain unknown, the ecosystem is effectively being asked to commit treasury resources toward a long-term modular scaling architecture before determining whether the upcoming base-layer upgrades materially change Cardano’s competitiveness. This creates the risk of prematurely expanding ecosystem complexity, governance overhead, liquidity fragmentation, and operational burden before establishing whether upgraded L1 can satisfy a meaningful portion of the ecosystem’s scaling requirements.
Another major concern is the growing disconnect between infrastructure spending and measurable ecosystem outcomes. Cardano has consistently demonstrated strong research quality, sound academic foundations, and thoughtful engineering direction, but these strengths have not yet translated into the level of mainnet adoption, developer traction, liquidity growth, user activity, or application dominance necessary to justify aggressive expansion into increasingly sophisticated scaling architectures. The ecosystem today is not facing widespread congestion caused by overwhelming adoption demand. Instead, the more immediate challenge appears to be limited application growth, weak competitive positioning relative to faster-moving ecosystems, fragmented user attention, and declining market confidence in Cardano’s ability to convert long-term research into visible ecosystem execution. Under these circumstances, funding additional scalability infrastructure risks prioritizing future theoretical demand over present ecosystem realities.
The proposal also relies heavily on projected ecosystem growth that remains uncertain and largely speculative. Claims surrounding TVL growth, transaction growth, developer expansion, and ecosystem competitiveness are presented narratively rather than through concrete adoption guarantees or enforceable milestone-linked metrics. The proposal assumes that developers and applications currently building on or considering Hydra and Midgard will remain committed to Cardano and eventually generate meaningful ecosystem activity, but these assumptions are external dependencies rather than guaranteed outcomes. Treasury funding should not be based primarily on hypothetical future adoption without stronger evidence that the ecosystem is already approaching the operational limits of its current infrastructure.
Concerns surrounding execution confidence further weaken the case for support. Over multiple cycles, the ecosystem has funded foundational scalability research, engineering implementation, optimization work, and production-readiness efforts. Despite this, many of Cardano’s most important scalability promises remain future-facing rather than fully realized in production. This has contributed to growing delivery skepticism within parts of the community. The question is no longer simply whether the technical architecture is theoretically sound. The more important governance question is whether the ecosystem has sufficient evidence that previously funded scalability initiatives are translating into timely, measurable, ecosystem-wide outcomes. This proposal does not sufficiently address that confidence gap. It explains the urgency of L2 scaling, but it does not adequately explain why the treasury should believe that ambitious timelines around Hydra productionization, Midgard decentralization, and shared infrastructure deployment will succeed when prior scalability roadmaps have consistently required extended timelines to mature.
There are also significant technical and operational risks embedded in the proposal itself. Hydra remains highly specialized infrastructure with limited applicability to generalized open-participation environments, while Midgard’s path toward decentralized multi-operator coordination introduces a new and complex engineering challenge that the proposal itself acknowledges as one of its highest-risk components. Rollup ecosystems are operationally difficult even in ecosystems with significantly larger developer bases, liquidity pools, and production experience. The Cardano ecosystem has not yet demonstrated large-scale success operating these systems in production under meaningful economic pressure. Funding such infrastructure at this stage therefore carries substantial uncertainty relative to the size of the treasury request.
From a governance perspective, there is also concern about strategic overextension. The ecosystem is simultaneously being asked to continue heavily funding unfinished L1 scalability work while also financing a broad L2 expansion strategy. This creates the appearance that Cardano is attempting to solve future scaling problems before resolving current adoption and competitiveness challenges. A healthier sequencing approach would prioritize demonstrating the real-world impact of previously funded L1 scalability investments, proving stronger adoption growth, improving developer experience, increasing meaningful application deployment, and establishing measurable ecosystem momentum before committing further large-scale treasury resources toward expansive L2 infrastructure initiatives.
None of these concerns imply that L2s are inherently unnecessary or without value. Hydra, optimistic rollups, and modular execution environments which all got funded last cycle under the ₳96.8M IO proposal may eventually play an important role in Cardano’s long-term architecture. However, we believe that governance decisions must consider timing, treasury efficiency, ecosystem readiness, execution credibility, and measurable return on investment. At the present stage of ecosystem maturity, this proposal appears premature relative to Cardano’s demonstrated adoption profile and unresolved base-layer roadmap.
- Yes10.9M ₳No rationale
- No10.8M ₳No rationale
- NoChanged10.4M ₳Rationale
Updating rationale (reason from changing NO to ABSTAIN to NO):
L2, Midgard: Treasury should not be treated as a blank cheque for overlapping insiders, unfinished prior work and vague future promises.
Here's the core issue -
This proposal asks for ₳10.4 million across Hydra, shared L2 infrastructure and Midgard. This bundles together multiple narratives, multiple entities and multiple future claims - without first answering the most basic question
What was funded before, what was actually delivered, and what value did it create?
Midgard Labs has already received prior support without completing a single milestone.
In any normal funding environment, that would be the first filter. Before new money is approved, prior execution gets examined.
And from what I can see, there is no completed milestone history here that justifies another large Treasury allocation involving Midgard Labs.
That alone should make voters pause. There's also a broader governance issue. This proposal presents Hydra and Midgard as complementary, and maybe in theory they are. But in governance terms, this is still a large request tied to entities with close alignment and overlapping influence. When the same orbit of people and companies keeps coming back for Treasury funds without clear prior accountability, voters should be much more skeptical.
Treasury should not become an internal capital pool for connected entities.
Another concern -the proposal sells a lot of future upside - 10,000+ TPS, sub-cent fees, production-ready L2s, treasury revenue from sequencers, stronger ecosystem growth, more TVL, more MAUs. But a lot of that is still prospective, not proven.
And when you dig in, even the proposal admits key parts are still unresolved:
- DA strategy is still at prototype/spec stage
- Midgard's multi-operator coordination is a major engineering risk
- operator economics and GTM incentive design are not fully executed
- mainnet readiness depends on subsequent cycle work
That is a lot of uncertainty for a proposal of this size.
To be clear - I am not dismissing Hydra, or saying Cardano should ignore L2s. I am saying the burden of proof rises when the ask is large, the parties are closely connected and prior funded work remains incomplete.No new Treasury money should go to Midgard related work until prior funded milestones are clearly completed, publicly demonstrated and shown to have created value for the ecosystem.
If this were a normal company board, investor committee or grant review, the answer would be the same - show me what you deliver, the value and then we can talk
That's why I voted NO
Earlier votes
Abstain3mo agoSuperseded
Midgard is owned by Charles Hoskinson - who also own IOG. Midgard Labs who is also working on Midgard and has yet to produce any milestones for prior work that was funded. In any normal funding process, this is the first question that should be asked, what was delivered prior? and did it bring any value?
I find very confusing that a proposal involving Midgard Labs would be even considered. There is no single milestone completed for prior work.
No3mo agoSuperseded
Midgard is owned by Charles Hoskinson - who also own IOG. Midgard Labs who is also working on Midgard and has yet to produce any milestones for prior work that was funded. In any normal funding process, this is the first question that should be asked, what was delivered prior? and did it bring any value?
I find very confusing that a proposal involving Midgard Labs would be even considered. There is no single milestone completed for prior work.
- No9.6M ₳No rationale
- Yes9.2M ₳No rationale
- No8.8M ₳Rationale
私はこの提案にNo票を投じます。L2技術の重要性や将来的な可能性については理解していますが、現時点のCardanoエコシステムにおいては、より優先すべき課題があると考えています。特に、LeiosやPerasなどL1改善がまだ発展途上であることに加え、提案内で示されている需要やユースケースの多くは将来期待ベースであり、現時点で十分な実需がある段階には至っていないと考えています。そのため、現段階では本提案よりもL1改善やエコシステム基盤強化を優先すべきだと考えており、本提案にNo票を投じます。\n\nI will vote No on this proposal. While I understand the importance and long-term potential of L2 technologies, I believe there are currently higher-priority areas within the Cardano ecosystem. In particular, L1 improvements such as Leios and Peras are still under development, and many of the proposed use cases and demand assumptions remain future-oriented rather than based on existing real-world adoption. For now, I believe greater priority should be placed on L1 improvements and broader ecosystem infrastructure, and for that reason I will vote No on this proposal.
- Yes8.1M ₳No rationale
- No7.6M ₳Rationale
I appreciate both teams and I have voted in favor of Hydra and Midgard proposals previously. Unfortunately, there is an unfinished Catalyst Fund 12 proposal Anastasia Labs - Midgard: Cardano Layer 2 with 500,000 $ADA requested. Three milestones have been verified as completed, three are still outstanding. The proposal was supposed to deliver a Midgard MVP. Last year, I also voted in favor of a Treasury Withdrawal worth ₳2,162,096 for Midgard - Optimistic Rollups administered by Intersect. That proposal stated: "Midgard is already in active development, and we have already made significant progress towards our goal of EOY mainnet readiness." I voted Yes with the expectation of end of 2025 mainnet readiness. This current proposal states: "Midgard is approaching its testnet phase". Essentially, as much as I appreciate both teams building on Cardano, I think this proposal is somewhat premature - at this moment of the 2026 budget year. Also, if resubmitting, please do revisit the original Catalyst proposal and 2025 Treasury withdrawal. For example, the Catalyst proposal stated: "Several projects, including FluidTokens, have already committed to utilizing Midgard. This early adoption showcases the confidence of the community and developers in the capabilities of Midgard to deliver a high-performance Layer 2 solution." I have seen that there are some differences now with the FluidToken team - not that it matters to me as a DRep. Business relationships are business relationships. What I am interested in is: are there projects - now in 2026 - that have expressed interest or are committed to utilizing Midgard? The demand for Midgard matters for a positive vote.
- Yes7.2M ₳No rationale
- No6.4M ₳No rationale
- No5.9M ₳Rationale
I am voting No.
I understand the importance of scalability and the potential role of Layer 2 solutions in the long term. However, I do not believe this addresses the most immediate constraints facing the ecosystem today.
Cardano is not currently limited by throughput or execution capacity—we are limited by users, activity, and demand. Investing heavily in future scale before that demand materializes feels misaligned with where the ecosystem needs to focus right now.
This is not a rejection of the direction, but a question of timing and prioritization. I would rather see resources directed toward driving usage and adoption first, and allow scaling solutions to be pulled forward by real demand rather than built ahead of it.
- No5.8M ₳Rationale
현재는 L1의 트랜젝션을 끌어올 요소에 재무부자금을 할당하는게 더 좋은 판단이라 생각함
- Yes5.4M ₳No rationale
- Yes5.3M ₳Rationale
Voting YES. Closes Cardano's most pressing competitive gap - finality, fees, and throughput - through a co-venture with Midgard Labs that decentralises L2 stewardship rather than concentrating it within IO. Same gold-standard treasury safeguards as the broader 2026 batch, with the added structural innovation of L2 sequencer revenue routing back to the Cardano treasury.
The three-workstream design is well calibrated: shared L2-agnostic data availability infrastructure benefits every current and future Cardano L2, Hydra hardening protects live production commitments from Delta DeFi and Masumi, and Midgard's mainnet path delivers Cardano's first permissionless optimistic rollup. Hydra and Midgard address distinct trust models - they are not competing solutions, and supporting only one would leave a meaningful coverage gap. The Midgard Labs co-venture is precisely the distributed stewardship outcome the Cardano 2030 Vision is designed to produce.
Peter Horsfall - Independent DRep, Oceania.
- Yes5.3M ₳Rationale
STORM Partners votes YES on the IO & Midgard Labs L2 Scalability Initiative.
Cardano needs both L1 and L2 scaling paths. Hydra and Midgard are strategically important because they represent Cardano-native approaches to scalable execution, and both can become real differentiators if executed well.
Our support comes with a clear caveat. Midgard has had accountability and public communication challenges, and L2 infrastructure is difficult to evaluate from the outside. We support the proposal because the direction matters, but we expect stronger public reporting, clearer progress updates, and better evidence of adoption by real application teams. - Abstain4.8M ₳No rationale
- Yes4.7M ₳No rationale
- Yes4.6M ₳No rationale
- Yes4.4M ₳Rationale
My only objection to this proposal concerns the current state of Midgard. The project has already received substantial funding in the past through treasury withdrawals and Catalyst, yet we have seen very limited updates from the development team and significant delays. In particular, it is claimed that all Catalyst milestones have been delivered, but without officially submitting the SoM completion. Over the coming days, I will closely monitor the explanations provided by the team, as requested by many DReps. Should any concerning issues arise, I will not hesitate to change my vote to No (although I do not expect that to be necessary).
==========================================
In general (and this applies to all IOG proposals), I firmly believe Charles is the most capable leader to guide Cardano into its next phase. With his experience, resources, technical knowledge, his army of developers, researchers and strong personal incentive for Cardano’s long term success, I will vote in favor of everything his company proposes. I wish we had even better alternatives, but we don't, cause there aren't any.
Since I am not a technical expert (particularly in this AI driven era), I will not pretend to fully evaluate the cost of these initiatives. That said, for a blockchain with a $10 billion market cap, an annual investment of approximately $40 million in core development does not seem excessive, especially in such a fast moving and highly competitive industry. Ultimately, this level of funding only makes sense if one trusts the incentives and capabilities of the person responsible for managing these resources.
I have also carefully reviewed the arguments circulating on X against funding IOG and find them unconvincing, as they never offer any viable alternative path forward. This includes the so called “conflict of interest” concerns regarding Midnight Ambassadors who are also DReps.
For transparency, I maintain close and regular communication with my 240 delegators through our Greek DAO Discord channel and update them via YouTube videos. They fully understand and expect me to ignore the social media noise, chaos and paranoia, and instead follow common sense and what is genuinely best for Cardano. - Yes4.1M ₳Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "IO & Midgard Labs: L2 Scalability Initiative" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qghg4q43), pois entendemos que ela aborda um ponto essencial para a competitividade da Cardano: escalabilidade, redução de custos e melhoria da experiência de uso para aplicações de alto volume, como DeFi, micropagamentos, jogos e pagamentos de consumo. A combinação entre uma infraestrutura L2 agnóstica, o fortalecimento da Hydra e o avanço da Midgard rumo à mainnet parece relevante para ampliar o uso real da rede, sem descaracterizar a importância da L1 como camada fundamental de segurança e liquidação. Embora o valor solicitado, de ₳10.425.871, seja expressivo, consideramos que o orçamento apresenta uma relação custo-benefício defensável diante do escopo técnico, dos potenciais ganhos de adoção e da possibilidade de geração futura de receita para o ecossistema. Também pesou positivamente a existência de entregáveis identificáveis, cronograma por workstream, marcos de entrega, validação por terceiros, gestão via contratos inteligentes, acompanhamento pela Intersect e previsão de devolução de recursos não utilizados. Ainda que alguns critérios técnicos de aceite possam exigir acompanhamento próximo durante a execução, os mecanismos de controle e transparência previstos tornam a proposta suficientemente monitorável para justificar nosso apoio.
[English]
We chose to vote "YES" on this governance action "IO & Midgard Labs: L2 Scalability Initiative" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qghg4q43), because we understand that it addresses an essential point for Cardano’s competitiveness: scalability, cost reduction, and improved user experience for high-volume applications such as DeFi, micropayments, gaming, and consumer payments. The combination of agnostic L2 infrastructure, the strengthening of Hydra, and the advancement of Midgard toward mainnet appears relevant to expanding real network usage, while preserving the importance of L1 as the fundamental layer for security and settlement. Although the requested amount of ₳10,425,871 is substantial, we consider the budget to present a defensible cost-benefit ratio given the technical scope, potential adoption gains, and the possibility of future revenue generation for the ecosystem. We also view positively the existence of identifiable deliverables, a workstream-based timeline, delivery milestones, third-party validation, smart contract-based management, Intersect oversight, and the planned return of unused funds. While some technical acceptance criteria may require close monitoring during execution, the proposed control and transparency mechanisms make the proposal sufficiently trackable to justify our support. - No4M ₳No rationale
- Yes3.8M ₳Rationale
The necessity of L2 architecture to Cardano in the short term override my many concerns about the proposal and specifically the procurement process for it.
A PDF version of this rationale is also made available.
This initiative addresses one of Cardano’s most strategically important long-term requirements: scalable transaction throughput with near-instant finality and extremely low transaction cost. I believe scalable L2 infrastructure is highly valuable and treasury appropriate as ecosystem infrastructure. If Cardano ultimately wants meaningful consumer-scale applications, gaming, payments, social systems, AI-agent transaction layers, or high-frequency activity, then scalable off-chain execution environments are not optional.
I also believe the timing is appropriate. Scalability infrastructure cannot be treated as something to begin only after ecosystem demand fully arrives. These systems require long research, engineering, testing, and ecosystem integration cycles. Waiting until scaling pressure becomes urgent would likely place the ecosystem years behind competitors.
The underlying strategic direction is valid and important.
My concerns are primarily around governance discipline, accountability, and proposal structure.
The largest issue for me is that Midgard Labs already received substantial prior treasury funding, reportedly approximately ₳2M, while significant milestones and ecosystem traction remain incomplete or unclear. Before additional funding is allocated, I believe governance should demand much stronger milestone transparency, delivery accounting, and demonstrated execution progress relative to prior commitments.
I am also concerned that the proposal lacks sufficient financial clarity regarding who is performing which portions of the work and how funding allocation is divided between IO, Midgard Labs, research activities, Hydra-related engineering, and operational functions. Treasury governance requires clearer attribution of responsibility, cost allocation, and accountability than what is currently presented.
The proposal structure itself further complicates evaluation. Bundling multiple distinct workstreams — including Midgard initiatives, broader L2 research, and Hydra-related efforts — makes it difficult to properly evaluate execution quality, ROI, milestone achievement, and value-per-ADA across the individual components. Governance works best when deliverables are separable and measurable.
I am additionally uncomfortable with the allocation of approximately ₳625k toward relatively unclear engagement and coordination functions without stronger specificity around deliverables, measurable outcomes, and operational necessity. Particularly in research-heavy initiatives, vague coordination categories can become areas where accountability weakens significantly.
Despite these concerns, I still believe scalable L2 infrastructure is strategically critical for Cardano’s future competitiveness and treasury appropriate as a long-term ecosystem investment. However, future proposals of this nature would benefit substantially from tighter milestone accountability, clearer vendor responsibility separation, more granular financial transparency, and less bundling of distinct workstreams under a single governance vote.
- Abstain3.7M ₳No rationale
- Yes3.1M ₳No rationale
- No3.1M ₳Rationale
I have to vote NO on this proposal, as there is no clear description of what has been delivered for past funding on Hydra and Midgard, and what exactly we will be getting as a final product for both L2s.
There is much hype and buzz in this proposal about potential value both L2s could bring, but no clear details about how these L2s will get us there and what will be built out for the community to make this all happen.
This is much too vague of a proposal to justify spending 10.5 Million ADA of community funding, and I expect that if IOG would like Hydra and Midgard funding that they address my previous concerns and resubmit.
Also, in no way should any founding entity, like IOG or its founder Charles Hoskinson publicly attack and pressure Cardano community members and DReps into voting Yes for their proposals. This dishonorable and disrespectful behavior is unbecoming of any leader who wishes to be taken seriously and in turn granted respect.
If this behavior continues in the future, I will be downvoting every proposal by such entities who behave this way as a consequence. Please keep in mind that actions have repercussions.
I also do not appreciate IOG frontrunning the entire Intersect budget process with the intent of claiming the entire NCL for 2026 and leaving nothing for community builders.
I expect this proposal to complete all deliverables as stated, and if this is not done, IOG will receive no further Yes votes from me in the future.
- Yes2.8M ₳Rationale
I am voting YES for this one with the expectation that the team gets it's previous milestones closed out!
- Yes2.7M ₳No rationale
- Yes2.7M ₳No rationale
- Yes2.7M ₳No rationale
- Yes2.6M ₳No rationale
- Yes2.6M ₳Rationale
Cardano L1の安全性を維持しながら、高速・低コスト・高頻度ユースケースを取り込むには、L2の実用化が不可欠である。HydraとMidgardは競合ではなく、Hydraは参加者が事前に定まる既知参加者型の高速処理基盤、Midgardは誰でも自由に参加できるpermissionless型のオープン基盤として、それぞれ異なるユースケースを担う補完的なスケーリング構造である点を評価する。さらに、Delta DeFiやMasumiなど実需に基づく開発支援も重要である。
Midgardの分散運用化やデータ基盤設計など、将来のL2基盤を左右する技術的に難易度の高い領域にはリスクがあるものの、CardanoのDeFi、AI、ゲーム、決済領域への拡張に直結するため、強く賛成する。
また、L2の価値がL1およびTreasuryへ還元される設計（①L2活動がL1への投稿を通じてプロトコル収益を生み出す点、②sequencer収益の一部をTreasuryへ還元する設計意図が示されている点）は評価するが、長期的な寄生リスクについては継続的な監視が必要である。
To maintain the security of Cardano L1 while enabling high-speed, low-cost, and high-frequency use cases, L2 adoption is essential. Hydra and Midgard are not competing solutions but complementary scaling layers: Hydra serves as a high-speed solution for known participants, while Midgard provides a permissionless environment open to anyone. This dual approach effectively supports different use cases. It is also important to support real-world builders such as Delta DeFi and Masumi.
Although there are risks in technically challenging areas such as Midgard’s multi-operator model and data availability design, this proposal is directly aligned with expanding Cardano into DeFi, AI, gaming, and payments, and I strongly support it.
I also value the design where L2 activity contributes back to L1 and the Treasury (through L1 transaction fees and the intended routing of a portion of sequencer revenue). However, the long-term risk of value extraction at the L2 level should be continuously monitored.
- Yes2.5M ₳No rationale
- Yes2.5M ₳Rationale
let's get our scalability efforts over the line
- Yes2.3M ₳No rationale
- No2.3M ₳No rationale
- Abstain2.3M ₳No rationale
- Yes2.1M ₳No rationale
- Yes2.1M ₳No rationale
- Yes2.1M ₳Rationale