CardanoLeo

Vote: No

Rationale:
The proposal’s own Section 7 correctly identifies a fundamental limitation: raising $k$ to 1000 cannot enforce whether redelegated stake moves to a genuinely independent operator or merely shifts to another pool managed by the same entity. What the proposal fails to address — and what warrants strict scrutiny — is which of these two outcomes is actually more likely.

Consider a multi-pool operator (MPO) currently running several pools near saturation. Halving the saturation threshold effectively doubles the required number of pool nodes, relays, and monitoring systems to retain the same total stake. This creates a tangible operational and financial burden, absorbed entirely by the SPO rather than the protocol. Meanwhile, when delegators receive an oversaturation warning, behavioral friction and brand familiarity strongly disincentivize them from researching unfamiliar, independent micro-pools. Instead, delegators will naturally follow the existing operator to their newly launched sibling pool.

If this friction-free transition is the default delegator response, lowering the saturation threshold fails to achieve the entity-level decentralization the proposal purports to deliver. It simply forces existing MPOs to shoulder higher infrastructure costs and subjects delegators to unnecessary redelegation friction, while leaving entity-level control fully concentrated.

This is not a hypothetical counterargument; it is the direct, predictable outcome of an inherent protocol design constraint acknowledged in the proposal itself: the ledger cannot natively trace common entity control across distinct pool IDs. A purely saturation-driven parameter change cannot mitigate this substitution effect.

If multi-pool concentration is the true structural problem, it must be targeted directly — whether through formal MPO identification frameworks, mandatory disclosure requirements, or margin and fee structures tied to an operator’s total aggregated stake rather than per-pool ID resets. Lowering the saturation threshold without addressing these underlying dynamics asks the ecosystem to absorb definitive costs (in operator overhead and user friction) for a decentralization benefit that cannot be verified and, in the case of MPOs, will not materialize.

I remain open to supporting future proposals that couple $k$ parameter adjustments with concrete, enforceable mechanisms designed to explicitly address multi-pool concentration.

---

DRep Delegation Info

• CIP-1694 DRep ID: drep1y28xhrjxe496rnle8ln3slpggnp8leu3mn244ujrhwet0cc2vmte4
• Legacy DRep ID (CIP-105): drep13e4cu3kdfwsul7fluuv8c2zycfl70ywu64d0ysamk2m7xrv7rsv

---

投票：反對

反對理由：
提案文件第 7 節已明確指出其核心局限：將 $k$ 值調升至 1000，並無法機制性地決定重新委託的權益會流向真正獨立的營運者，還是僅轉移至同一營運集團旗下的其他權益池（Pool）。然而，提案未能對這兩種情境的發生機率進行評估，而這恰恰是本次參數調整最應被嚴格審視之處。

試想一個現狀下有多個權益池接近飽和的多池營運商（MPO）。當飽和門檻減半，營運商若要維持相同的質押總量，所需維持的節點、Relay 與監控維運成本將近乎翻倍——此硬性成本完全由營運商吸收，協議本身並不承擔。另一方面，當委託人收到飽和警告時，受限於資訊不對稱與轉換摩擦，實務上極高機率會直接跟隨原營運商開設的新池，而非花費心力去研究並轉向陌生的獨立小池。品牌熟悉度與最低操作阻力，均指向同一個行為路徑。

若上述行為成為市場常態，單純調低飽和門檻便無法達成提案所訴求的「實體層級去中心化」（Entity-level Decentralization）；相反地，它僅是徒增既有多池營運商的維運負擔，並給予委託人一次不必要的重新委託操作，而實質控制權依然高度集中於同一實體手中。

這並非推測性的疑慮，而是提案自身提及卻未解決之缺口的直接且可預期後果：鏈上帳本無法可靠地辨識跨 Pool ID 的共同控制關係，因此純粹依賴飽和度的機制設計，根本無法阻止上述「同集團內替代效應」的發生。

若多池營運導致的集中化才是真正欲解決的痛點，應當採取直接對症下藥的配套措施——例如建立明確的多池識別機制、資訊揭露規範，或是讓成本與費率結構與營運商控制的「總質押量」掛鉤，而非以單一 Pool ID 為單位重複重置計算。在缺乏相關配套的情況下單純調低飽和門檻，無異於要求整個生態系吸收明確的真實成本（營運商的基礎設施支出與委託人的操作摩擦），去換取一個無法被保證、且在多池情境下極可能根本無法實現的去中心化幻象。

未來若有提案能將 $k$ 值的調整，與直接應對多池集中化問題的具體配套機制結合，我將樂於支持。

---

DRep 委託資訊

• CIP-1694 DRep ID: drep1y28xhrjxe496rnle8ln3slpggnp8leu3mn244ujrhwet0cc2vmte4
• Legacy DRep ID (CIP-105): drep13e4cu3kdfwsul7fluuv8c2zycfl70ywu64d0ysamk2m7xrv7rsv

Vote: YES

I support reducing minPoolCost from 170 ada to 75 ada.

---

1. Core Incentive & Arbitrage Mechanics

The strongest case for this change is not delegator yield — it's incentive design. A high fixed-fee floor rewards single-block pools disproportionately: as long as a pool produces at least one block in an epoch, it draws the full fixed fee out of that block's reward before anything is split with delegators. The fewer blocks a pool produces, the larger a share of its reward the floor consumes.

A well-capitalized operator can exploit this by splitting stake across many single-block pools rather than consolidating into fewer, better-performing ones, collecting the floor repeatedly instead of once. Lowering the floor directly weakens that arbitrage.

This matters more for genuine decentralization than pool count itself:

• Of the 1,614 active pools referenced in this proposal, 873 sit below the delegation threshold needed for consistent block production.
• Note: The underlying incentives report doesn't break that 873 down by cause. Some share reflects fee-farming of this kind, while some reflects other factors like sticky delegation or insufficient network-wide stake to saturate more pools. While I don't have a precise split, the incentive distortion itself is real regardless of the mix.

---

2. Impact on Small, Independent Pools

I don't think 75 ada meaningfully changes the survival odds of a small, genuinely independent pool. At current ada prices, that is roughly two days' worth of the fixed fee over a five-day epoch — well below the operating cost of a properly run node, regardless of where the floor sits.

The argument that this reduction "saves small pools" is weaker than the argument that it removes an outsized payout specifically for single-block operation.

---

3. Empirical Precedent (2023 Reduction)

The 2023 precedent (340 ada → 170 ada) is relevant evidence here:

• The feared "race-to-the-bottom" in operator pricing didn't materialize.
• 340 ada remained the dominant fee setting among established pools.

This history gives the current reduction an empirical basis rather than a purely theoretical one.

---

4. Key Reservation & Structural Timeline

My one reservation: this reduction is explicitly framed as an interim step ahead of a proportional minPoolMargin (CIP-0023), which by current sequencing is still roughly two hard forks away.

I would like to see Intersect and the Technical Steering Committee (TSC) commit to a concrete timeline for that structural work, ensuring this floor doesn't become a permanent substitute for the more complete fix it is meant to bridge toward.

---

Conclusion

I am voting YES on the substance of the case as submitted, with the expectation of a clear CIP-0023 timeline noted for the record.

---

DRep Delegation Info

• CIP-1694 DRep ID:

drep1y28xhrjxe496rnle8ln3slpggnp8leu3mn244ujrhwet0cc2vmte4

• Legacy DRep ID (CIP-105):

drep13e4cu3kdfwsul7fluuv8c2zycfl70ywu64d0ysamk2m7xrv7rsv

Vote: NO

I support OpenZeppelin coming into Cardano. A reusable, audited contracts library would raise the baseline quality of what gets shipped here, and the trust OpenZeppelin already has with EVM developers is not something Cardano can create on its own. I am voting against this proposal, not against the firm, and not against the work itself.

---

1. Overlap with work already funded

The treasury is not choosing between two sketches. IO’s Developer Experience Initiative (₳3,601,926) was enacted on May 29, 2026. The Q3 2026 deliverable is explicit: a ContractsLibrary "inspired by OpenZeppelin’s role in the EVM ecosystem," with at least five ready-to-audit contracts. The public repo (input-output-hk/contracts-library) says the same thing.

• About 3.6 million ada is already committed to an OpenZeppelin-style library.
• This proposal asks for another 11,787,063 ada for a second library of similar scope.

The text mentions working with IO, but it does not publish a gap analysis, nor does it specify which library teams should treat as the standard. Q3 2026 is when the first library is due. The sensible order is to evaluate what that grant actually delivered, then decide whether a second library is worth buying. Until those questions are answered, this is not complementary work so much as the risk of paying twice.

---

2. The smart contract language is still unset

Workstream B states that the specific smart contract language will be decided during the initial evaluation phase. For a contracts library, that choice is close to the core product itself — it determines who can import the code and whether it fits the toolchain teams are actively using.

The proposal requests USD $1,831,000 upfront while leaving the language selection until after funding is secured. With the language unset, there is no reliable way to assess whether the library will align with what developers are actually building.

---

3. Surplus from the stablecoin conversion is not addressed

The budget uses USD $0.16 per ada as a reference rate. The full delivery amount of 11,443,750 ada converts at contract signature, rather than converting only the necessary amount to reach USD $1,831,000. At a recent spot price near USD $0.196, that conversion yields approximately USD $2.24 million — roughly USD $410,000 (22%) above the stated delivery budget.

A conservative reference rate is reasonable, but converting the entire ada amount regardless of spot price is a distinct financial choice that the proposal fails to explain. It specifies only two mechanics:

1. The full delivery amount converts at signature.
2. Unused funds sweep back to the treasury at expiry.

Sweep simply means the smart contract returns remaining funds when the term ends — it is not an immediate swap or return mechanism. What happens to the surplus generated at conversion (returned immediately, retained in the contract, or made accessible to the vendor) is completely unwritten. Until this gap is closed, the treasury is being asked to approve an over-provision with no formal rule governing the extra capital.

---

4. The security retainer is a vendor self-review

Workstream C is scoped exclusively to OpenZeppelin-produced code. Audit costs sit within overhead, pointing to Intersect’s administration fee as oversight. However, Intersect handles disbursement and milestone verification — not an independent technical review of the contracts. This withdrawal sets aside no dedicated capital for a third-party code audit.

Note: This point does not rest on Article II.7.4 (which governs periodic financial/fund-use audits). My view is distinct: for a USD $1.83 million library intended for ecosystem-wide adoption, vendor self-review is insufficient. Independent technical audits should be scoped and funded separately, rather than folded into the vendor's internal security retainer.

---

Conclusion & Next Steps

OpenZeppelin has explicitly stated that if this proposal does not pass, they will gather community feedback and submit a revised version. A NO vote is therefore inexpensive — it requests a clearer scope and a tighter financial/technical structure without asking OpenZeppelin to leave Cardano.

I welcome a revised submission. At a minimum, a revised text should:

• Spell out the division of scope with the already-funded IO ContractsLibrary, specifying which standard teams should adopt.
• Finalize the smart contract language prior to requesting funds.
• Convert only the ada required at spot rates upon milestone release, returning any conversion surplus immediately.
• Fund an independent third-party technical audit separately from the vendor's internal security review.
• Stage the three workstreams sequentially rather than bundling them into a single all-or-nothing engagement.

Vote: YES

I support reimbursing the original 100,000 ADA deposit. The loss was caused by a node-level bug that allowed an unregistered stake key to submit a governance action — not by any error on the submitter's part. Reimbursing a loss caused by a protocol defect is a reasonable use of the treasury, and the submitter's status as an early participant in on-chain governance only strengthens the case.

I have reservations about the additional 3,000 ADA proposed as compensation for lost staking rewards. My concern isn't the amount, but the precedent: once the treasury begins compensating opportunity cost alongside principal, future proposals will have grounds to claim similar time-value losses from any bug-related delay, with no clear boundary on how far that logic extends.

I'd have preferred to vote on the principal and the opportunity-cost compensation separately. Since that option isn't available here, I'm voting YES on the strength of the principal reimbursement, while registering that I don't think opportunity-cost compensation should become a standing practice without a clearer, bounded policy for when it applies.

---

DRep Delegation Info

• CIP-1694 DRep ID:
  drep1y28xhrjxe496rnle8ln3slpggnp8leu3mn244ujrhwet0cc2vmte4
• Legacy DRep ID (CIP-105):
  drep13e4cu3kdfwsul7fluuv8c2zycfl70ywu64d0ysamk2m7xrv7rsv

Feedback on the "Governance Incentives Framework 2026" Proposal

Thank you to the proposal team for introducing the Governance Incentives Framework 2026. I fully agree that the increasing concentration of voting power is an important governance topic that warrants thoughtful attention. However, after carefully reviewing the proposal details and the publicly available completion reports of the team's past projects, I remain hesitant to support this treasury withdrawal of ₳4,207,967 at this stage.

Public Completion Records and Verifiable Limitations of Past Projects

To ground this discussion in objective reference points, I reviewed the public pages and completion reports for the team's relevant completed Catalyst projects:

1. Smart Pack: parcels damage verification system on Cardano

• Project ID: 1100259｜Catalyst Project Page
• Project Managers: Eric den Boer & Sebastian Pereira
• Timeline: 04/24/2024 – 02/15/2025
• Status: Marked as Complete; fully funded.
• Key Completion Details: Deliverables included freight calculation sheets, an AI photo database, ChatGPT damage evaluation demo videos, backend screenshots, test transaction hashes, UI mockups, workflow recordings, LiDAR tests, early app store links, and web demos.
• Reported Limitations: The “Next Steps” section explicitly notes: “We are in contact with a few agricultural producers in the US... These discussions are in a very early phase, so for now we do not have concrete plans to deploy this solution in a more realistic environment.” The team also thoughtfully pointed out: “Cardano is not very friendly to mobile devices... very slow... In a mass commercial production environment, this will be a severe problem.”

1. Littlefish - Coordinating Action

• Closeout Video: Watch on YouTube
• Status: Marked as Complete.
• Verifiable Limitations: The closeout video has recorded approximately 87 views. The disclosed community size at the time was on the order of around 100 members, and subsequent public sources do not indicate significant transition into a widely adopted coordination platform.

1. Cardano Smart (AI Documentation & Developer Assistant)

• Milestone Page: Catalyst Milestones
• Verifiable Limitations: Although successfully closed out with open-source deliverables, publicly visible GitHub activity remains quiet, with limited records of ongoing user traction or broad integration into mainstream developer workflows.

These projects were all officially marked as completed within the Catalyst system, demonstrating that milestone deliverables were fully satisfied. However, information in the public completion reports suggests that evidence of subsequent real-world adoption and sustained long-term usage remains relatively modest. This leads me to remain prudent regarding whether allocating over 4.2 million ADA toward another extensive research and framework initiative will seamlessly translate into real-world governance adoption and long-term, measurable value.

Perspective on Problem Diagnosis

The proposal highlights that “one Constitutional Committee consortium retired due to lack of compensation” and that “there is no systematic, data-driven approach to determine how to incentivize governance participants.”

I fully acknowledge that appropriate incentives play a crucial role in sustaining active participation. However, I am not entirely convinced that this necessitates an immediate “investment of ₳4.2M into a comprehensive research framework.” A more direct and pragmatic approach might involve substantive refinements to the Constitution or Guardrails, or the rollout of clear, actionable incentive mechanisms.

Preferred Direction for Governance Incentives

I strongly favor establishing an incentive mechanism for DReps, but I gently advocate that incentives should ideally stem from sustainable non-Treasury models. For instance, delegators could consider allocating a small, fixed, or dynamic percentage of their own staking rewards to compensate their chosen DReps.

This operates similarly to a "delegation service fee": delegators receiving rewards from the ecosystem reasonably support the operational costs of their elected representatives. Linking rewards to engagement, dialogue quality, and voting participation creates a healthy feedback loop—allowing dedicated DReps to receive fair compensation while allowing natural delegation choices to optimize resource allocation. This approach minimizes reliance on the Treasury while fostering an active and accountable governance culture.

Conclusion

Given the finite nature of Treasury resources, the modest long-term adoption observed in past similar projects, and the ability of existing tools to cover foundational needs, I believe allocating ₳4.2 million ADA to this research framework may not represent the highest priority at this time.

I look forward to seeing concrete proposals that directly address structural challenges (such as voting power concentration and silent non-voting dynamics) through sustainable incentive models that do not depend primarily on treasury funding.

Based on publicly verifiable records and the available information, I am unable to support this proposal at present. However, if the project team can provide additional context regarding the ongoing adoption of previous initiatives, or demonstrate why alternative lower-cost pathways are insufficient, I would be very open to re-evaluating my perspective.