Dr. Navjit Dhaliwal

Looking forward to hardfork

Reimbursing owed funds, should be a yes

Phil is the first one that should be removed. He has made multiple racial slurs against Cardano community members. He has made multiple potential defamatory remarks and use derogatory terms. He should not be in any position in governance. As a CC member you have to hold the upmost professionalism, treat everyone fairly, with respect but Phil has done exactly the opposite.

IOG is again not transparent with the costs. Too much expenditure for too little return

Any partnerships with Emurgo or involving Emurgo should be down voted until the security issues are resolved. Emurgo currently can not be trusted to operate in a secure fashion

Although the business model is not very successful and there aren't many users, alternative wallets that are open source are needed

In order to bring more transactions on Cardano, it needs to support builders. Not enough has been invested into the biggest need in Cardano

So far this year Cardano governance is approved

137 million ADA expenditure + 116 million ADA IOG proposals, so far

That is already 253 million ADA expenditure. I will be voting NO/ABSTAIN on all other proposals because imo the yearly spend should be between maximum 200-250 million.

However I think this proposal is very strong and should be considered by other dReps

So far this year Cardano governance is approved

137 million ADA expenditure + 116 million ADA IOG proposals, so far

That is already 253 million ADA expenditure. I will be voting NO/ABSTAIN on all other proposals because imo the yearly spend should be between maximum 200-250 million.

So far this year Cardano governance is approved

137 million ADA expenditure + 116 million ADA IOG proposals, so far

That is already 253 million ADA expenditure. I will be voting NO/ABSTAIN on all other proposals because imo the yearly spend should be between maximum 200-250 million.

So far this year Cardano governance is approved

137 million ADA expenditure + 116 million ADA IOG proposals, so far

That is already 253 million ADA expenditure. I will be voting NO/ABSTAIN on all other proposals because imo the yearly spend should be between maximum 200-250 million.

This is already over the threshold. My vote doesn't effect the outcome.

This is already over the threshold. My vote doesn't effect the outcome.

Peras itself is strategically important. The proposal's core promise is faster settlement, with Peras targeting roughly 2 minute finality instead of ~12 minutes today, which matters for exchanges, bridges, partner chains and dApps that need stronger settlement guarantees.

I still land on NO because, as a Treasury proposal, this is too bundled, too long duration and too hard to evaluate cleanly. It asks for 39.8 million $ADA/$9.95 million USD over 2026-2028 across 17 work packages in 9 areas and explicitly says the portfolio should be treated as one delivery pipeline rather than a modular menu. That is exactly the problem - voters are being forced into one yes/no decision on a mix of very different items - some clearly critical, some much more debatable. If this were just Peras v1 mainnet readiness, I would be much more open to supporting it and voting YES.

The second issue is budget clarity. The proposal justifies the total primarily through an average rate of $176 an hour for senior Cardano infrastructure engineers and a two year effort horizon. That rate is not outrageous on its own for specialized protocol work. But from the materials here, I still do not get a clean, easy to audit package by- ackage budget showing how much is actually going to:

For a proposal this large and this broad, I want a much sharper line of sight between the money and the deliverables.

The third issue is carry over risk from prior funding. Tweag publicly disclosed in April 2026 that its ongoing Cardano delivery suffered a roughly $3.5 million effective funding shortfall because the prior budget had assumed a much higher ADA/USD conversion rate and that a significant portion of the work had to be paused while the most critical roadmap items continued. Their own tracker currently shows some work streams as done but others as on pause or pending final demo. That makes this new proposal look, at least in part, like a catch-up and stabilization proposal for a budget stress problem from the previous cycle, not just a clean forward looking ask. It weakens the investment case for locking in a larger two year contract.

The fourth issue is overlap with other 2026 asks. The separate Consensus proposal already includes maturing consensus changes through release candidate readiness and specifically mentions conformance testing against formal specifications and integration into the primary node. The Maintenance proposal already covers node bugfixing, infrastructure, monitoring, and testnet maintenance. The Plutus proposal already covers formal verification, conformance and security for smart contract infrastructure. That does not mean Tweag's work is useless - it means Treasury voters are being asked to fund multiple proposals that cluster around the same correctness, readiness and maintenance surface area. The boundaries are not clean enough for a proposal this large.

Because that is not how it is presented, I vote NO.

This proposal is not transparent enough for another 23 million $ADA after 70 million $ADA was already approved for Pentad V1.

About 90% of the budget sits inside one confidential bucket for "integration and maintenance costs," with no public vendor level breakdown for Circle, LayerZero, Pyth, Dune or Fireblocks. I understand the NDA between the actual integrations but who is doing the maintenance? Who are the 3rd party vendors? Who is providing the infra?

The proposal also allows funds to be converted into stablecoins and held with a custodian, including minting and custody fees, without clearly quantifying those costs up front. Steering Committee discretion remains very broad and reporting is only bi-annual.

On the V1 integrations:

$USDCx is live but it is USDCx via Circle xReserve, not the broader "USDC/USDT on Cardano" story many people had in mind, prior to the proposal. Cardano's stablecoin market cap is still only very low, with about $16.6 million USDCx, so the realized liquidity impact remains much smaller than the narrative suggests - majority of the deploy by one founding entity with $NIGHT pairing.

But what about Dune and Pyth? What do they bring?

• Dune is an analytics/data platform. For Cardano, it gives SQL queryable onchain data, APIs/DataShare and dashboards for things like transactions, fees, staking, validator activity, smart contracts and user activity. A project usually does not need a deep protocol integration to "use Dune" - it mainly uses Dune by querying the indexed Cardano data and publishing dashboards or internal analytics on top of it. In other words, Dune is mostly a data visibility layer, not a protocol capability layer

• Pyth is an oracle/market data network. Projects integrate it when they need external price feeds for things like perps, lending, synthetics or risk engines. The integration path is more technical than Dune -developers fetch signed price updates off-chain with Pyth's SDK, then pass those updates onchain, where their validator checks the Pyth state UTxO/reference input and verifies the price update in the transaction flow. So Pyth is a runtime dependency for DeFi logic

Their impact on Cardano is still limited - both are mostly enablers, not direct adoption engines. Dune makes Cardano easier to analyze, compare, and monitor but analytics alone do not bring liquidity or users. We already have Taptools and Xerberus that do this.

Pyth is oracle infrastructure, but oracle access alone does not create volume unless multiple serious DeFi apps actually integrate and use it at scale.

Are there competing Cardano native tools already? Yes.

For analytics and data access, Cardano already has ecosystem native tools like @TapTools, Cardanoscan, @cexplorer_io, @StatsAda and other explorers/analytics products. Dune's advantage is not that Cardano had no analytics before - its advantage is that it puts Cardano data inside a crosschain platform already used by crypto researchers, fund and growth teams. That is useful but it is still different from saying it created new enterprise adoption on its own. We also have oracles on Cardano already

Does this provide enterprise adoption? No.

Dune can help enterprise or institutional teams see and compare Cardano data more easily and Pyth can help DeFi products build with institutional style pricing infrastructure. But neither one, by itself, is an enterprise adoption event.

LayerZero

This is probably the integration with the highest upside but it is also the clearest example of why I do not think the proposal is fully candid in its top line framing.

The official CCI V1 closure report says LayerZero is only in advanced stages and is targeting Q3 for launch. It also says that OFT deployments on Cardano are explicitly out of scope for V1 and may need separate governance actions later. So LayerZero is not a cleanly delivered/live integration

That is reinforced by LayerZero's own public developer docs. The "Get Started" docs currently tell developers to choose from EVM, Solana, Aptos or Hyperliquid and the public mainnet endpoint deployment page I checked does not list Cardano. That does not prove Cardano work is nonexistent but it does show that from a public builder and market perspective, Cardano does not yet look like a standard first class live LayerZero environment.

Fireblocks

The proposal presents Fireblocks as a new full native integration funded in V2, expected to cover $ADA, CNTs, staking and governance workflows. That already means V2 is not purely a maintenance proposal. It is partly a new integration proposal bundled inside a maintenance budget.

The official CCI V1 closure report is explicit that Fireblocks did not result in a V1 disbursement and that the ecosystem instead got an Iagon SDK level Fireblocks integration outside V1. The report even acknowledges that this delivered "material institutional access." Meanwhile, the public Fireblocks GitHub repo for cardano-raw-sdk describes a Fireblocks/Iagon integration that already supports:

• ADA and CNT transfers
• governance operations
• staking operations
• and mainnet/preprod/preview support through the Iagon API

That is exactly why I have an issue with the V2 framing.

The proposal and closure report effectively say -
yes, Iagon delivered something meaningful but "most institutional counterparties" still need a full native L1 Fireblocks integration. The problem is that this is asserted, not really proven. There are no named counterparties, no quantified demand, no pipeline value, no expected custody volumes, no exchange listings tied to it and no business case explanation for why the existing Iagon path is not sufficient for a larger portion of the market. It also contradicts discussions Iagon has had with business partners wanting to use the solution.

From a business perspective, that means V2 is undervaluing an existing ecosystem delivered stop-gap while asking Treasury to pay again for a deeper version without clearly quantifying the incremental return.

For transparency - I am the CEO of Iagon and Iagon works with Fireblocks. That may create a perceived conflict of interest, so I want to disclose it clearly.

My comments on Fireblocks should be read as focused on governance, scope clarity and Treasury accountability, not as a statement against Fireblocks as a company or product. My issue is not with Fireblocks itself. My issue is whether this proposal clearly justifies the additional Treasury spend and properly explains the incremental value to Cardano.

The transparency problem

The proposal does mention maintenance and infrastructure costs

• attestor operations for Circle
• DVN and endpoint operations for LayerZero
• oracle feed continuity and publisher incentives for Pyth
• schema/subgraph maintenance for Dune.

But it does not break any of that down by vendor, by integration, by FTE, by infrastructure unit cost or by SLA cost. Everything is rolled into the same ~90% bucket.

That is not good enough for Treasury capital. The response to this is basically - confidentiality. But confidentiality may be commercially understandable and still governance poor.

If the community cannot see the 3rd party cost structure, then the community cannot really judge whether the renewals are well priced, whether the value is proportional or whether one vendor is being overpaid relative to ecosystem benefit.

The proposal is too opaque. Too much money sits in a confidential bucket. Too much discretion sits with the Steering Committee. Too little hard ROI is shown for what V1 already bought.

I voted YES on the revised TOKEN2049 Singapore Platinum proposal.

EMURGO has a mixed history and event spend should always be scrutinized. I voted yes because they listened

• the proposal was separated from the larger bundle,
• reduced from Title to Platinum
• and EMURGO has now said it will forgo the 15% management fee and refund it to the treasury

That directly addresses one of the biggest concerns. At this size, the proposal is easier to justify as a builder platform - large booth, Cardano stage, builder tickets, showcases, networking and content capture

This is still NOT risk free - execution matters, KPIs are still partly marketing heavy and EMURGO should be held to a high reporting standard. But the revised version is materially better, and the willingness to remove the management fee was one of the main reasons I moved to YES.

As one of the employees at Eternl worked at Iagon and just recently parted ways - it was fair to abstain from this proposal

I voted no because, from a business perspective, this proposal tries to do too much at once for Treasury to fund comfortably as one package.

This is not one focused product ask. It is a bundled platform strategy:

• smart contract development
• application runtime
• application focused L1 node
• L2 integration

That may be a strong internal product vision for Lantr, but Treasury should be more careful about funding a broad platform bet before there is stronger proof that the market will converge around it.

That is my first issue. Platform demand is assumed more than proven. The proposal shows activity, integrations, and prior delivery. That is good. But that is not the same as proving that Scalus has already become, or is clearly becoming, the default application platform for Cardano builders.

My second issue is the node strategy. A meaningful part of the proposal is about building and hardening an application-focused L1 node. But Cardano already has multiple node, chain-access, and data-access efforts across the ecosystem. Treasury should ask whether this is truly filling a critical gap or whether it is helping one vendor vertically integrate its own stack at ecosystem expense.

My third issue is dependency risk. Some of the most important roadmap items depend on third-party projects like Hydrozoa/Gummiworm and Blaster, which are outside Lantr’s direct control and not funded through this proposal. That makes delivery risk materially higher.

My fourth issue is the proposal’s own framing. "Scalus is a product, not a project." That may make sense from a startup perspective. Public ecosystem capital should come with tighter delivery clarity than a flexible product roadmap built around reprioritization and internal sequencing shifts.

And finally, the proposal already starts normalising future maintenance dependence. Once Treasury funds a platform like this, it is difficult to stop, because maintenance, hard fork support, patches, compatibility, and ecosystem support all become recurring asks.

This proposal may be technically interesting, but it is too broad, too vendor-centric, too speculative in its ecosystem impact and too open ended in its future support expectations for me to support at this size.

That is why I voted NO

Cardano has already funded a very substantial amount of research. IO’s 2025 IOR/Cardano Vision program alone covered 20 research streams and 6 technology validation streams and IO says it delivered 24 peer-reviewed papers in 2025 while advancing multiple validation tracks. IO also says that across its history, IOR has produced 250+ peer-reviewed papers, with only about 20% implemented in Cardano. That is exactly the key business problem here - the issue is no longer whether IOG can produce research. The issue is whether Treasury should keep paying at this scale when the conversion from research into deployed value is still relatively low.

That is the first reason I voted no - Cardano does not have a research-production problem. It has a research-to-deployment conversion problem.

This proposal tries to answer that by saying it is more "product-aligned" and more "implementation-ready." But when you look at the actual outputs, the proposal is still fundamentally a research umbrella - papers, technical reports, CPSs, prototypes and some CIPs. The proposal itself describes 38 papers/technical reports, 8 CPSs, 12 prototypes and 5 CIPs across seven work packages. Lot of work but it is still mostly pre-product and pre-deployment work, not direct ecosystem shipping.

From a business perspective, that matters because Treasury capital is limited and should become more demanding over time.
At some point, the burden shifts from - "can this produce interesting research?" to
"will this produce enough real-world deployed value relative to cost?"

I do not think this proposal clears that bar strongly enough.

The second reason I voted no is overlap

• Leios/Peras analysis
• L2/ZK infrastructure
• Plutus verification
• light clients and decentralized APIs
• Babel fees and intent markets
• bridge and interoperability security
• SPO incentives
• governance incentives
• identity
• dissemination/commercialization pathways

There is overlap with the rest of the 2026 proposals

• the separate Consensus proposal already funds Leios production, validation, adversarial testing and hardfork enabling work- IO even says "the science is done" there
• the separate L2 Scalability proposal already funds Hydra hardening, Midgard mainnet work and shared L2 primitives
• the separate Plutus proposal already funds execution efficiency, formal correctness and developer-experience work around Plutus.

So while this proposal tries to frame itself as the upstream research pipeline, from a Treasury point of view it still looks like a very large umbrella sitting next to several implementation proposals covering closely adjacent areas.

That creates the obvious concern - Where does this proposal end and the others begin? Similar story with other proposals from IOG

The third reason I voted no is weak milestone discipline for a proposal of this size. The total ask is about 32.9 million $ADA/$7.9 million USD for 36 FTEs, which works out to about $219.5k USD per FTE per year. That number is not absurd on its own for senior research heavy work but the payment gates are too soft. Funds are released in four equal tranches based on

• execution of the services agreement
• submission of the interim report
• delivery of the Q3 R&D session and report
• submission of the final report

That is not strong enough for a proposal of this scale. Those are reporting and process checkpoints, not sharp, objective, output-based release gates by work package. For a broad research portfolio, that means Treasury is being asked to fund a large moving program with relatively flexible internal reallocation and comparatively light milestone constraints.

The proposal even says that because of the exploratory nature of the work, it uses a portfolio based approach to dynamic reallocation and re-prioritization. That may be sensible from an R&D management perspective, but it is weaker from a Treasury governance perspective because voters are funding a broad envelope rather than tightly bounded deliverables.

A company or ecosystem with unlimited capital can afford to run many parallel research bets. Treasury should not assume that luxury. Cardano already has deep research depth. Instead this still reads like a large strategic research umbrella trying to cover too much of the future at once.

The fifth reason I voted no is simple - the proposal itself admits the conversion problem.

It says IOR has produced over 250 papers, with about 20% implemented in Cardano. That is useful honesty but it also reinforces my concern. Treasury should not keep rewarding research breadth without demanding stronger implementation conversion and clearer accountability for what gets shipped, adopted and used.

That is why I voted NO

I voted NO on the TOKEN2049 Title Sponsorship top-up and YES on the Cardano Summit 2026 proposal.

The TOKEN2049 top-up is primarily an incremental spend on premium visibility - a larger booth, a keynote slot, additional branding, media introductions and related event optics. I do not think the marginal return on that extra spend is clear enough.

The Cardano Summit is different. It is a Cardano controlled platform with a dedicated agenda and a clearer structure for converting attention into meaningful ecosystem outcomes. The revised Summit proposal is no longer tied to the TOKEN2049 sponsorship proposal and has been reduced by 22% while preserving the core two day structure. It also defines more direct outcome targets, including 250 enterprise MQLs, 50 strategic meetings within 45 days, 10 live demos/workshops, 200 developer participants, and 30 hackathon submissions/applications.

Just as importantly, prior Summits provide evidence that this format has already produced real value.

The official Cardano Summit 2025 results state that the event brought 1,460 in person attendees and 26,000 online viewers, while also recording strong participation from enterprises including Volvo, Wurth Group, Mastercard and many more. The same official recap reports that the Layer Up hackathon attracted 134 developers from 92 teams, resulting in 14 submitted projects.

It has acted as a meeting point for enterprise engagement and developer onboarding. There are also concrete examples from the ecosystem.

Example - At the 2022 Lausanne Summit, I presented on data compliance, privacy, security and GDPR. This speech was right before Charles' announcement of Midnight

At the 2025 Berlin Summit, the official agenda included "Iagon & Würth Group: Enterprise Adoption -A Cardano Case Study." This was a direct example of a real enterprise use case being showcased through the Cardano Summit format.

The Summit gives Cardano:

• a platform it controls
• an agenda aligned to its priorities
• a structured place for builders and enterprises to meet
• a more direct path from visibility to follow-up and adoption

That is why I was comfortable supporting the Summit, while not supporting the premium TOKEN2049 top-up

I voted NO on the TOKEN2049 Title Sponsorship top-up and YES on the Cardano Summit 2026 proposal.

The TOKEN2049 top-up is primarily an incremental spend on premium visibility - a larger booth, a keynote slot, additional branding, media introductions and related event optics. I do not think the marginal return on that extra spend is clear enough.

The Cardano Summit is different. It is a Cardano controlled platform with a dedicated agenda and a clearer structure for converting attention into meaningful ecosystem outcomes. The revised Summit proposal is no longer tied to the TOKEN2049 sponsorship proposal and has been reduced by 22% while preserving the core two day structure. It also defines more direct outcome targets, including 250 enterprise MQLs, 50 strategic meetings within 45 days, 10 live demos/workshops, 200 developer participants, and 30 hackathon submissions/applications.

Just as importantly, prior Summits provide evidence that this format has already produced real value.

The official Cardano Summit 2025 results state that the event brought 1,460 in person attendees and 26,000 online viewers, while also recording strong participation from enterprises including Volvo, Wurth Group, Mastercard and many more. The same official recap reports that the Layer Up hackathon attracted 134 developers from 92 teams, resulting in 14 submitted projects.

It has acted as a meeting point for enterprise engagement and developer onboarding. There are also concrete examples from the ecosystem.

Example - At the 2022 Lausanne Summit, I presented on data compliance, privacy, security and GDPR. This speech was right before Charles' announcement of Midnight

At the 2025 Berlin Summit, the official agenda included "Iagon & Würth Group: Enterprise Adoption -A Cardano Case Study." This was a direct example of a real enterprise use case being showcased through the Cardano Summit format.

The Summit gives Cardano:

• a platform it controls
• an agenda aligned to its priorities
• a structured place for builders and enterprises to meet
• a more direct path from visibility to follow-up and adoption

That is why I was comfortable supporting the Summit, while not supporting the premium TOKEN2049 top-up

My view is consistent with the position I took previously when these were bundled together. Now that the proposals have been separated, I can reflect my actual view more accurately

The reason is straightforward - even as a non-technical voter, I can clearly understand the strategic value of this proposal.

A production ready Cardano light node that runs in the browser is a unique and differentiated product. It improves onboarding, lowers access barriers and strengthens the decentralization story in a way that is easy to grasp even without deep technical expertise. It stands out as something that could be genuinely useful for wallets, dApps and end users, while also giving Cardano a clear point of differentiation. aka USP

I'm always a big fan of onboarding the 'regular joe'

This is not because I am against the proposal, nor because I believe it lacks value. My abstain is based on something much simpler:

I am not a technical expert and I do not feel confident enough to make a strong judgment on the technical merits of Pebble versus alternatives.

Pebble may very well be useful. The tooling maintenance portion may also be important. But unlike Gerolamo, where the value proposition is easier to understand at a strategic and product level, this proposal depends much more on technical assessment

So my abstain is an honest one. I am not rejecting the proposal. I am simply acknowledging that I do not have the technical depth required to judge it with conviction.

I do think separating this proposal from Gerolamo was the right decision. These are very different asks and they should not have been bundled together in a way that forced voters into one combined position.

The issue is that this proposal asks for ₳62,134,630 over roughly 9 months, while giving the community broad scope categories but no public line by line cost breakdown for those categories. The proposal lists nine functional areas but it does not show how much is being spent on bugfixing vs monitoring vs documentation vs release/security vs component maintenance. For a proposal of this size, that is not good enough.

The proposal's main argument is that "every proposal in this portfolio depends on one thing: a stable, reliable, operational Cardano network." That is directionally true. Security, incident response, release engineering and test infrastructure are real dependencies for other proposals. But that argument can also be used to justify almost anything if it is not tightly constrained.

Because other proposals already include their own readiness, integration, validation or ecosystem support work. For example:

• the Consensus/Leios proposal includes conformance testing, load testing, adversarial validation, stable client interfaces, tactical support for DB-Sync, Mithril, and Blockfrost, workshops, and hard-fork-enabling work.

• the Developer Experience proposal includes documentation, onboarding, outreach, reactive ecosystem work, and portal improvements.

• the Blockfrost proposal includes 24/7 incident response, ongoing maintenance, developer support, and infrastructure costs for the free tier.

So when the maintenance proposal also includes documentation, monitoring, release support, component upkeep, open source support, performance, QA, and incident management, it becomes very reasonable to ask - WHERE exactly does maintenance stop and other proposal scope begin?

There is BIG overlap RISK.

That is why I raised the Cardano Blueprint point. If maintenance is paying for Blueprint/documentation related work while there is also a separate documentation developer experience proposal, that starts to look like possible double dipping. And that is exactly the kind of thing voters are supposed to scrutinize.

A maintenance proposal should not become a catch-all bucket where adjacent workstreams get absorbed under the logic that "the network needs everything." That is not disciplined budgeting.

There is also a broader governance issue here.

IOG said it wanted dReps to ask questions. Fine. But when people show up with harder questions - especially around expenditure, FTEs, overlap and accountability - those questions should actually be addressed directly. Instead, they have thrown their own narratives without questions being allowed.

Another issue is that the proposal is structured as continuous support work, not sharply defined milestone based delivery. That makes some sense for maintenance but it also makes accountability harder. If the work is always ongoing, always essential and always broad, then it becomes much harder for the community to measure whether the cost is proportionate. And the cost is NOT small.

At the proposal's own reference rate, this is roughly $14.9 million USD for about 9 months of work. How many FTEs?

That is one of the most basic questions for a proposal of this size. Instead, one of the explanations given was essentially that long running systems accumulate technical debt and that some percentage of that naturally goes into maintenance/support, around 30-40%. I do not think that is the right way to look at it. If the product has 12 million $ADA in revenue, the technical debt shouldn't be more the 5x the revenue.

This proposal is too broad, too expensive, too aggregated and not transparent enough for the amount being requested.

This is why I voted NO

"without triggering a taxable disposal event" - is objectively one of the most concerning statements but there is more. It is probably a opportunity Cardano can pursue. The issue is structure. This proposal bundles three things together- a $BTC bridge, a credit market, a yield/RWA/private credit product

The bridge may be public infrastructure. The credit and yield products look like a commercial venture.

This is an IO Venture Studio style product - the Cardano treasury should not be used as non-dilutive startup capital without proper investment protections

The proposal does not clearly disclose -

• whether Pogun will have a token
• whether there will be future private raises
• whether IOG owns equity or Charles indirectly/direclty
• whether founders/advisors receive equity or token upside
• whether the treasury receives equity, tokens, warrants, or governance rights
• whether repayment obligations survive sale, spinout, rebrand or restructuring

The treasury is offered 20% of EBITDA until repayment and 5% EBITDA after that. But EBITDA is easy to reduce through costs, salaries, related-party fees, legal expenses, infrastructure charges or restructuring - I have not see ANY voters discuss this

That is not enough protection for public funds. There are also serious regulatory and legal risks - $BTC backed lending, transferable bond tokens, yield products, RWAs, private credit, institutional onboarding and tax claims around "same UTXO" recovery. These are NOT small issues.

The treasury should fund neutral public goods, not de-risk a commercial venture where private actors may capture most of the upside.

Split the proposal, remove IOG and disclose all parties on equity side.

Until then - NO.

Voted YES on Consensus Proposal - which also supports BLOCKFROST directly (I DO understand why IOG keeps supporting companies owned by Charles indirectly/directly but this is NOT how it should be). But not with blind optimism. This is one of the few proposals in this cycle that I see as genuinely core infrastructure for Cardano's long term base layer competitiveness. If Cardano wants a credible path toward its own 2030 transaction ambitions, stronger L1 throughput,and better fee-generation capacity over time, then some version of Leios is likely necessary.

Cardano's own public materials make that case clearly -Leios is the planned path from Praos toward materially higher throughput, with public targets in the 10x or more range and roadmap work focused on moving from testnet/prototype toward release candidate and hard fork readiness.

There are real negatives here.

The proposal is much more specific than that. It funds:
a mainnet ready "release candidate"

It explicitly does not promise that the mainnet hard fork itself will happen within the proposal scope. That depends on additional ecosystem readiness, governance timing and external dependencies. Voters should be aware about that.

Second, there is clear continuity with prior Leios funding. This is not Leios starting from zero. In prior budget cycles, IO already had Leios related funding in both core engineering and research streams. So this ask should be understood as a continuation of a multi-cycle effort, not a brand-new initiative. It means the community should expect strong carry over accountability from earlier phases into this one.

Third, the proposal is expensive. At the proposal's own reference pricing, the ask is about $6.65 million USD. Added to previously visible Leios specific funding, the known minimum spend is already substantial. That raises valid questions around total cumulative cost, staffing efficiency, and whether proposal level FTE and rate transparency should be better than it currently is.

Fourth, this is still a HIGH risk engineering program.
Even the proposal acknowledges risks around parameter assumptions, integration timing, Dijkstra-era timing, ecosystem readiness, and downstream dependencies. The implementation plan is mature but this is still cutting-edge protocol engineering - and this is not simple

Fifth, there is downstream complexity for the wider ecosystem. Leios is not just "more throughput." It affects client interfaces, tooling and supporting infrastructure. That is why the proposal explicitly includes support for things like dBsync, Mithril and Blockfrost. This is another reason the community should NOT oversell the timeline or pretend the work ends when the core protocol code is ready.

So why did I still vote YES?

Because despite those negatives, this is one of the few proposals where the downside of not doing it is larger than the discomfort of funding it.

If the base layer does not materially improve throughput capacity, the chain risks falling behind its own ambitions and losing credibility as a platform for serious growth. Leios is not a nice to have. It is part of the core scaling path Cardano has already signaled publicly and architecturally.

Developer experience, onboarding, and documentation are important. They absolutely matter and I fully agree Cardano needs to make it easier for builders to get from zero to MVP faster.

I voted no because I do not believe spending ₳3.6M is a proportionate, disciplined or well-structured response to the actual problem.

The proposal frames the issue as fragmented documentation, tooling friction, weak onboarding and lack of coordination. But the uncomfortable truth is this:

A large part of the fragmentation being described is self-inflicted and much of it comes from IOG's own publishing habits. We already have:

developers.cardano.org maintained by the Cardano Foundation

And if we are being honest, the strongest evidence in this discussion points to the fragmentation being driven not by some mysterious ecosystem wide failure but by IOG itself publishing across too many places, with too little consolidation.

They keep docs on docs.cardano.org which is widely seen as under-maintained. They spin up Blueprint sections which then stall, not necessarily because of bad intent but because key people get pulled into other priorities and time becomes limited. Then instead of completing the agnostic version in the shared documentation flow, fresh technical specs get published as separate PDFs on Intersect subdomains.

Even when an IOG team lead does the right thing and puts important documentation like the new Tracer docs into the CF Developer Portal, other teams continue creating new locations. That is the fragmentation.

So before asking Treasury for millions more, the first question should be:

• Why hasn't this already been consolidated into one clear, neutral, community open source of truth?

Onboarding and dev experience absolutely matter - no disagreement there. But if the main sources of scattered and outdated information are coming from one org’s uncoordinated output, then the fastest and most rational way to improve things is not a large new Treasury ask.

The fastest fix is - better internal coordination + routing everything toward the one neutral, community open hub.

Because it is not asking Treasury to solve some entirely external problem. It is, in part, asking Treasury to pay millions to help fix a documentation and onboarding situation that IOG itself has meaningfully contributed to creating.

All other development proposals should already come with proper documentation. That should not be some optional extra or future clean-up item. If Treasury is funding work across the ecosystem, documentation should already be part of delivery standards and that documentation should already be pushed toward the Developer Portal managed by CF as the neutral entry point.

The good news is that this is actually fixable in a pretty straightforward way without needing a big new parallel effort. A more rational approach would have been -
fully back developers.cardano.org as the single source of truth

• redirect or shut down overlapping documentation sites
• require IOG teams to publish there by default instead of opening new subdomains or standalone PDF flows
• add targeted bounties only for the highest-value missing gaps

And there is a bigger principle here - Treasury should not be used to pay millions to solve problems that were, at least in meaningful part, created by a lack of internal coordination from the same entities now proposing the solution.

IOG and CF are here to work on Cardano. There should be no other priority than making Cardano easier to build on.

If documentation is fragmented because teams keep publishing in fragmented ways, then the first step is not a multi-million $ADA proposal.

So do we really need to spend ₳3.6 million $ADA to solve this problem?

Or can IOG simply start practicing proper organization of documentation, proper consolidation of outputs and proper support for the Developer Portal that already exists?

For me, the answer is obvious. That is why I voted NO.

Updating rationale (reason from changing NO to ABSTAIN to NO):

Blockfrost: Cardano Treasury should not be used to subsidize a profitable private company without a clear public return.

We've already seen other private entities held to a different standard. In previous rounds, projects like Snek were pushed toward a loan structure because they were considered a private company. So why is Blockfrost being treated differently?

Blockfrost is also being framed by some as "critical infrastructure." I don't agree with that characterization.

Cardano builders use many alternatives: Maestro, Koios, Dandelion, Cardanoscan API, Iagon Insights, Dolos, Ogmios, Yaci Store and others. This is not a one-provider ecosystem

I even ran a builder poll. At the time of writing, the results were:

• 8% use Blockfrost paid
• 8% use Blockfrost free tier
• 59% use multiple API tools
• 25% don't use Blockfrost at all

That does not support the narrative that Blockfrost is some irreplaceable backbone for Cardano.

Another issue - the proposal leaned on claims around usage and traffic concentration, including the idea that ~90% of traffic flows through Blockfrost. That claim was later deleted after basic questions were asked. The reality is simple - there is no credible public way to verify how many dapps depend on Blockfrost or what percentage of ecosystem traffic runs through it.

That makes the "critical infrastructure" argument look more like marketing than governance-grade evidence

If Treasury funds a private company, there should be a clear benefit flowing back to Treasury and the ecosystem. Equity, tokens, revenue share, hard guarantees, something tangible. We cannot keep socializing cost while privatizing upside

And if the standard is that ecosystem builders should give something back, then that standard should apply equally to EVERYONE - not only to some teams while exceptions are made for companies with the right connections.

We need consistent rules, evidence based claims, and better stewardship of Treasury

That's why I voted NO on Blockfrost.

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

I'm voting NO on this treasury proposal. Not because Summit or TOKEN2049 are bad ideas.

I'm voting No because this proposal asks the ecosystem to fund a premium visibility strategy without giving enough clarity, accountability or direct ecosystem return for the size of the ask

The idea is not the problem.

Co-locating Cardano Summit with TOKEN2049 in Singapore is strategically smart on paper. It can - capture existing traffic bring Cardano outside its echo chamber, create access to media, institutions, exchanges, funds and enterprise.

That part I understand.

But good strategy alone is not enough.

What exact value comes back to the ecosystem? Who benefits? How is success measured? How do we know this wasn't mostly branding spend?

This proposal does not answer those questions well enough.

They are not strong enough primary justifications for spending $3.66M of treasury funds.

Some of the KPIs are especially weak. Examples:

• Digital reach >1B
• 50% increase in positive sentiment
• 50% increase in share of voice
• 700 earned media pieces
• 900 merch distributions

That may sound impressive in a deck but in reality it isn't, examples that could improve KPIs

• enterprise deals progressed
• integrations initiated
• ecosystem projects onboarded into real opportunities
• investor meetings
• follow-up outcomes

The proposal does include some better KPIs like:
-enterprise MQLs

• strategic meetings
  -collaborations

Need better clarity on them as well.

What counts as a qualified lead? What counts as a collaboration? Who verifies it? What happens 90 days later? Without attribution and follow-up, the KPI system is too soft

Another issue - The proposal still reads too much like: "big event + premium sponsorship = ecosystem value"

That is not automatically true. A large booth, a keynote, signage, merch, press mentions and social impressions do not by themselves justify treasury deployment.

The burden is on the proposers to prove durable, distributed value.
Now let's talk about the expenditure.

TOKEN2049 staffing/management. The $699.9k TOKEN2049 title sponsorship is the easiest line item to understand - as it's actually the cost. But it is also the line item that most needs ROI discipline.

The proposal leans on prestige - mainstage, premium booth, media, app visibility, signage, access. But what is the measurable downstream value to Cardano builders and the ecosystem?

That case is not strong enough.

The $200k project management/staffing /delivery for the TOKEN2049 side especially needs more clarity. For 2 day event, this seems a bit overblown.

As an ecosystem builder, I want Cardano in the rooms that matter. I want us at the biggest stages. I want us meeting institutions, enterprises, media and capital.

But I also want treasury proposals to be built in a way that clearly returns value to the people actually building in this ecosystem.

Cardano should absolutely think globally. But treasury spending must be - credible, measurable and fair

These are the reasons why I'm voting NO.
I also hope that Emurgo and YoroiWallet will ABSTAIN from this vote, seeing as they are the proposer. I'd also like this to become a standard in governance, proposer should not be able to vote on their own proposal

I wanted to add a rational. Wasn't able to do this without changing my vote from Abstain to No. I will change to Abstain again

I can the advantage Gerolamo for non-tech people, easy onboarding for a light node. Different from other proposals. I would vote Yes if it was only for Gerolamo.

I cannot say (as I'm not a developer) Pebble, is advantageous or not. This is why I would prefer that the proposals be separated. I would vote Abstain on Pebble and Yes for Gerolamo.

I applaud CF for using governance and putting this to a vote.

I want to make it clear however that Catalyst is a broken system and needs to be removed completely from Cardano governance. We need to pave way for KPI based proposals like CB DAO.

I'm impressed with how Samiz (Draper) has helped bring the Orion Fund proposal to Cardano. This is not an easy initiative - it has real challenges around regulation, compliance, structure and coordination

I'll be honest: I was skeptical at first. But Samiz has been willing to engage directly and answer the tough questions that were raised with clear, confident explanations.

A few key clarifications Samiz has shared that mattered to me:

1. 'Cardano-integrated' - will be tied to measurable KPIs like TVL, on-chain transactions and real usage on Cardano (not just "we support multiple chains"). He states that projects coming to Cardano will have meaningful KPIs that they have to bring, not sure we support Cardano.

2. Cardano ecosystem dApps will be contacted soon - outreach and pipeline building will be actively pursued. This has not happened yet. My vote is a Yes because of above 2 points and how they were answered by Samiz

Overall: the proposal is solid. It introduces a more institutional-style capital deployment model, aims to generate ROI back to the Treasury and commits to tracking ecosystem outcomes via on-chain/ecosystem metrics (TVL, liquidity, users, transactions..etc)

For those reasons, I'll be voting Yes on this proposal.

We already have Amaru proposal for node diversity. There is no urgent need for multiple proposals of a similar nature. It would be better to wait until next year

The budget is too high for creating a company.

Marshall Islands or BVI is a more cost effective approach. Caymans is a very expensive jurisdiction and there are little to no advantages of opening in Caymans over the others

Amaru has been transparent with their funding and expenditure. Although I believe the ask is high, node diversity is a very important need in Cardano.

I encourage more treasury proposals that are transparent as this.

The budget in opinion should be lower. We have to really think of being net positive and not over spend. I think the net change limit should be lower.

This is an unnecessary expense for the ecosystem.

1. The budget is extremely high to setup a company in the first place. In contrast, you can setup a business in the BVI for less than 10k - all inclusive.
2. The jurisdiction chosen is not best jurisdiction for DeFi.

I'm failing to see how this was concluded and selected.

This needs much improvement and better timing

I voted for Christina prior to this. She deserves to be included

This is much needed in Cardano. Iagon would be directly benefit from this by getting the Fireblocks integration reimbursed, this is the reason for the Abstain vote.

However, I would ask others to ask more details about the 3.5M ADA for legal, compliance and admin costs. This is in my view way too much for this. At worst, one contract would cost potentially 30-50k USD. I don't see how this can be 3.5M ADA.

Need to get governance restored

Conditional Yes - Cardano ecosystem could really benefit from this proposal. However, there is a lot of detail missing and I expect this to change.

Which vendors are you targeting in each category? What is the estimate cost in USD for each (category budget)?

There is also some overlap in oversight committee, this is for me a conflict of interest, I hope there will be more detail later. A lot of changes need to happen to showcase more transparency to the community

I think it's important to compensate people for their work.

Congrats on Snek on getting this passed! Two reasons I abstain. One is because there are no standards in place for future CNT listings to also get a similar grant. We (Iagon) even reached out to offer a collective loan grant but Snek decided to do it on it's own. I think a standard is important, so no favoritisms are given when voting through on grant proposals. Two (smaller reason) - there is no "playbook" to getting listings and the fact that introductions to Kraken, crypto.com were done through Iagon, doesn't tell the community the full story of the so called "playbook"

Seems reasonable ask. Although I think that 3k ADA shouldn't be included.

I want this to pass because Cardano needs liquidity but at the same time my reservations about the team managing the funds and how there are multiple conflicts of interest.

With these conflicts of interest, it is entirely possible that some of these members make money off who is selected from the DEXs, the ada delegation and possibly votes. There are multiple areas where there is no thought out plan and no answers given on the timeline, even after repetitive questions.

I want to vote yes and will but I will highly consider voting no, if they don't consider changes that are necessary.

I have confidence in the process taken and changes made. Slight adjustment needed in the grammar

I have confidence in the elected members and believe they will do a great job