Update Plutus Cost Models

139 DReps voted · 47 with a rationale · 7 changed their vote

Open a row to read the rationale.

• Yoroi W₳llet

  Yes584.2M ₳Rationale

  Summary
  Yoroi DRep votes YES on "Update Plutus Cost Models", supporting this parameter change as a necessary and well-validated step in preparing Cardano for the van Rossem hard fork.

  Rationale

  A required update ahead of the van Rossem hard fork This action provides the cost model settings needed to activate new Plutus primitives following the upgrade to Protocol Version 11. Without this update, the new primitives introduced across five CIPs covering cryptography, list operations, array builtins, and value manipulation would not be usable after the hard fork.

  Properly benchmarked and validated All new and updated cost model values have been benchmarked against the standard reference architecture and validated through enactments on SanchoNet, Preview, and Preprod testnets. The changes are consistent with all three relevant constitutional guardrails, no values are negative, and the process followed Intersect's Parameter Committee and Technical Steering Committee review.

  Consistency improvements across Plutus versions The action also ensures that primitives previously limited to Plutus V3 are made available in V1 and V2, improving consistency across versions and reducing friction for developers working across different contract environments.

  Conclusion
  Yoroi supports this parameter change as a technically sound and procedurally well-governed update that is necessary for the van Rossem hard fork to proceed as intended, and votes

• YUTA

  Yes435.8M ₳Rationale

  Voting YES on "Update Plutus Cost Models." This enhances functionality without sacrificing security.

  ---

  「Update Plutus Cost Models」にYESを投票します。これはセキュリティを犠牲にすることなく、機能を強化します。

• Blockdaemon

  Yes332.2M ₳No rationale
• EMURGO

  Yes293M ₳Rationale

  Summary

  EMURGO as a DRep votes YES on the parameter change titled "Update Plutus Cost Models", with rationale outlined below.

  Rationale

  This governance action updates the Plutus cost models across V1, V2, and V3 to prepare for the van Rossem hard fork and Protocol Version 11. The changes serve three purposes: providing cost model settings for new Plutus primitives that will become available after the hard fork, ensuring consistency by making previously V3-only primitives available in V1 and V2, and updating existing primitive settings based on benchmarking data.

  The new primitives introduced span cryptographic operations, list and array manipulation, and value handling, covering modular exponentiation, multi-scalar multiplication over BLS12-381, array builtins, and MaryEraValue operations. These additions expand the capabilities available to smart contract developers and enable more efficient on-chain computation, particularly for cryptographic and cross-chain use cases.

  EMURGO is satisfied that the process behind this change is sound. The changes were recommended by Intersect's Parameter Committee in March 2026, confirmed by the Technical Steering Committee in May 2026, and validated through equivalent enactments on SanchoNet, Preview, and Preprod testnets prior to this mainnet proposal. All cost model values have been benchmarked against the reference architecture, no values are negative, and the action is consistent with constitutional guardrails PCM-01, PCM-02, and PCM-03. For these reasons, EMURGO votes YES.

• Sebastien Guillemot セバ

  Yes174.6M ₳No rationale
• Cardano Foundation

  Yes120.2M ₳Rationale

  The Cardano Foundation votes YES. We support updating the Plutus V3 Cost Model to enable the new Plutus primitives that will be available following the van Rossem hard fork. The provided reference materials and socialization proofs satisfy our requirements for this parameter change.
• JAZZ

  Yes92.2M ₳No rationale
• CardanoYoda (MANDA Pool)

  Yes91.5M ₳Rationale

  As a DRep, I decided to vote YES for proposal: Update Plutus Cost Models

  My rationale:

  This is a technical parameter update that enables the new Plutus primitives that will become available after the van Rossem hard fork to Protocol Version 11. It extends relevant primitives consistently across Plutus V1, V2, and V3, and updates some existing primitive costs based on benchmarking.

  For this kind of highly technical parameter change, DReps cannot reasonably be expected to independently verify every cost-model coefficient. The important question is whether the process was credible, reviewed, tested, and consistent with the constitutional guardrails.

  In this case, the proposal states that the changes were recommended by Intersect's Parameter Committee, confirmed by the Technical Steering Committee, benchmarked against the reference implementation, and already enacted on SanchoNet, Preview, and Preprod testnets.

  I trust Intersect's Parameter Committee and the process followed here. Cost model updates are exactly the kind of work where the ecosystem needs a competent technical body to review benchmarks, assess consistency with guardrails, and recommend safe parameter changes.

  Approving this action is basically essential. Without the appropriate cost model settings, the new Plutus functionality introduced with Protocol Version 11 cannot be properly enabled and used. This would unnecessarily limit developer capabilities and reduce the value of the upcoming hard fork.

  My support should be understood as support for the technical process, the committee recommendation, and the need to keep Plutus cost models aligned with protocol upgrades.

  Unless credible technical objections are raised by qualified Plutus or ledger engineers, I believe this action should be approved.

  If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.

  MANDA Pool ID:
  pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

  My DRep ID:
  drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

• BTBF_XSP

  Yes88.6M ₳Rationale

  I support this governance action.

  This proposal is a necessary technical update to make Cardano ready for Protocol Version 11 and the van Rossem hard fork. By updating the Plutus cost models, Cardano can enable the new Plutus primitives that will become available after the hard fork, while also expanding access to certain primitives across Plutus V1, V2.

  For these reasons, I support this proposal.

• SIPO

  Yes86M ₳Rationale

  SIPO DRep votes YES on Update Plutus Cost Models.

  Governance Action ID: gov_action1eqhnsdyf3exhp5mqt7sdjtl7xy69wqg8tvg854psns2jt72cra3qqrcnr8r
  Legacy Governance Action ID (CIP-105): c82f3834898e4d70d3605fa0d92ffe31345701075b107a54309c1525f9581f62#0
  DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
  Date: 2026-06-10

  This parameter-change action, proposed by Intersect's Parameter Committee and confirmed by the Technical Steering Committee, updates the Plutus cost models across Plutus V1, V2, and V3. It does three things: it sets the cost-model parameters for the new Plutus primitives that become available after the van Rossem hard fork to Protocol Version 11 — including modular exponentiation (CIP-0109), multi-scalar multiplication over BLS12-381 (CIP-0133), dropList (CIP-0132), the Array builtin type (CIP-0138), and MaryEraValue (CIP-0153); it makes primitives previously limited to Plutus V3 available in V1 and V2; and it adjusts the settings of some existing primitives based on published benchmarking data, with those adjustments taking effect on enactment.

  SIPO supports this action for four reasons. First, it follows the proper institutional route: recommendation by the Parameter Committee in publicly minuted meetings, confirmation by the Technical Steering Committee, and a fully published evidence trail — benchmarking workflows, measurement data, methodology documentation, and a parameter diff — that any DRep can verify. This is the standard process that has accompanied cost-model updates at previous protocol upgrades without incident. Second, it is the enabling switch for capabilities SIPO has consistently supported: without these settings, the post-quantum- and zero-knowledge-relevant primitives arriving with Protocol Version 11 — the foundations for ZK rollups, proof aggregation, and cryptographic verification on Cardano — would remain unusable even after the hard fork. This action is the technical substrate beneath research and platform work SIPO has voted to fund this cycle. Third, the risk profile is acceptable and well mitigated: the principal risk of a cost model — underpricing that lets scripts consume more resources than they pay for — is addressed by the published benchmarking process, while overpricing is correctable by a subsequent parameter update; the immediate repricing of existing primitives is routine, benchmark-driven recalibration of the kind performed at every recent upgrade. Fourth, the sequencing logic favours approval: enacting this action before the mainnet hard fork is harmless if the hard fork is delayed, while rejecting it would leave new primitives unusable when the hard fork arrives.

  SIPO notes two expectations: that the Parameter Committee continues to publish benchmarking data and parameter diffs at this standard for future cost-model changes, and that post-enactment behaviour of the repriced primitives is monitored, with prompt corrective parameter actions if anomalies emerge. This action requests no treasury funds, raises no conflict of interest, and presents no recusal grounds for SIPO. This vote is SIPO DRep's recorded position.

  ---

  SIPO DRep として、本提案「Update Plutus Cost Models」に賛成（YES）を投じます。

  Governance Action ID: gov_action1eqhnsdyf3exhp5mqt7sdjtl7xy69wqg8tvg854psns2jt72cra3qqrcnr8r
  Legacy Governance Action ID (CIP-105): c82f3834898e4d70d3605fa0d92ffe31345701075b107a54309c1525f9581f62#0
  DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
  Date: 2026-06-10

  本パラメータ変更アクションは、Intersect の Parameter Committee が提案し Technical Steering Committee が確認したもので、Plutus V1・V2・V3 の cost model を更新します。内容は 3 つです。第一に、van Rossem ハードフォーク（Protocol Version 11）後に利用可能になる新しい Plutus プリミティブ — べき剰余（CIP-0109）、BLS12-381 上の multi-scalar multiplication（CIP-0133）、dropList（CIP-0132）、Array 組込型（CIP-0138）、MaryEraValue（CIP-0153）— の cost model パラメータを設定すること。第二に、これまで Plutus V3 に限定されていたプリミティブを V1・V2 でも利用可能にすること。第三に、公開されたベンチマークデータに基づき既存プリミティブの設定を調整することです（この調整は可決と同時に発効します）。

  SIPO は 4 つの理由で本アクションを支持します。第一に、正規の制度ルートを踏んでいることです。公開議事録のある Parameter Committee の勧告、Technical Steering Committee の確認、そして誰でも検証できる完全公開のエビデンス — ベンチマークワークフロー・計測データ・手法文書・パラメータ diff — が揃っています。これは過去のプロトコルアップグレードでも事故なく実施されてきた標準プロセスです。第二に、本アクションは SIPO が一貫して支持してきた能力群の「有効化スイッチ」です。これらの設定がなければ、Protocol Version 11 とともに届くポスト量子・ゼロ知識関連のプリミティブ — Cardano 上の ZK rollup・証明集約・暗号検証の土台 — はハードフォーク後も使えないままです。本アクションは、SIPO が今期資金面で支持してきた研究・プラットフォーム群の下にある技術的基盤です。第三に、リスクプロファイルが許容範囲で、よく緩和されています。cost model の本質的リスク — スクリプトが課金以上のリソースを消費する過小課金 — は公開ベンチマークプロセスで対処され、過大課金は後続のパラメータ更新で修正可能です。既存プリミティブの即時再価格化は、直近のアップグレードごとに行われてきたベンチマーク準拠の定常的な再調整です。第四に、順序の論理が承認を支持します。メインネットのハードフォークより先に本アクションが発効しても、ハードフォークが遅延すれば無害である一方、否決すればハードフォーク到来時に新プリミティブが使えなくなります。

  SIPO は 2 つの期待事項を記します。Parameter Committee が今後の cost model 変更でも本件と同水準のベンチマークデータとパラメータ diff の公開を継続すること、そして再価格化された既存プリミティブの発効後の挙動を監視し、異常があれば速やかに修正のパラメータアクションを講じることです。本アクションは Treasury 資金を要求せず、利益相反はなく、SIPO に recusal 事由もありません。本投票は SIPO DRep の記録上の立場表明です。

• Army of Spies

  Yes84.3M ₳Rationale

  Voting "yes" in full reliance on the expertise of the Intersect Parameter and Technical Steering Committees.

• Dumpling🥟

  Yes77.7M ₳No rationale
• Phil UPLC

  Yes76.8M ₳Rationale

  This is strictly a good change for the future maintainability of the ecosystem.

  A PDF version of this rationale is also made available.

  This is strictly a good change for the future maintainability of the ecosystem.

• ranket

  Yes75.2M ₳No rationale
• SASA_nagamaru_ながまる

  Yes74.5M ₳Rationale

  I have decided to vote YES on this proposal.

  This proposal enables the new Plutus primitives introduced with Protocol Version 11 and extends certain capabilities previously limited to Plutus V3 so they can also be used in Plutus V1 and V2.

  I believe this is an important technical upgrade that expands Cardano’s smart contract capabilities and supports future application development.

  For these reasons, I am voting YES.

  僕はこの提案にYESで投票します。

  この提案は、Protocol Version 11で導入される新しいPlutusプリミティブを利用可能にするとともに、これまでPlutus V3に限定されていた一部の機能をPlutus V1およびV2でも利用可能にするものです。

  Cardanoのスマートコントラクト機能を拡張し、将来のアプリケーション開発を支える重要な技術アップグレードであると考えています。

  そのため、YESで投票します。

• Dave

  Yes73.1M ₳Rationale

  I am voting YES. This update safely optimizes the cost model for Plutus V1, V2, and V3 in preparation for the van Rossem hard fork. It expands critical cryptographic and data primitives, has been thoroughly benchmarked, and has successfully passed SanchoNet, Preview, and Preprod testnet deployments.

  A PDF version of this rationale is also made available.

  I am formally registering a YES vote on the Plutus V3 Cost Model Parameter Update proposal.

  This update represents a critical step forward for Cardano's smart contract ecosystem, introducing vital new primitives for cryptography, list manipulation, array operations, and value or data manipulation. Standardizing and enabling these primitives across Plutus V1, V2, and V3 ensures technical consistency and significantly enhances inter chain capabilities.

  The proposal demonstrates exemplary governance and technical diligence. These changes are fully recommended by Intersect's Parameter Committee and confirmed by the Technical Steering Committee. Furthermore, identical updates have already been successfully enacted across the SanchoNet, Preview, and Preprod testnets. Finally, the benchmarking adheres strictly to the reference architecture and satisfies all constitutional guardrails including PCM-01, PCM-02, and PCM-03. I am fully supportive of this upgrade as we prepare for the van Rossem hard fork.

• Martin Lang

  Yes69.4M ₳No rationale
• Dori

  Yes53.8M ₳Rationale

  I'm voting Yes on the Update Plutus Cost Models proposal.

  This parameter update is what actually enables the new Plutus primitives that come with the van Rossem hard fork. The key items being activated are BLS12-381 multi-scalar multiplication (CIP-0133), the Array type (CIP-0138), Mary-era Value operations (CIP-0153), and modular exponentiation (CIP-0109).

  If this passes, I think Cardano builders will be able to ship things on mainnet that have been off the table due to cost limits. ZK-based privacy dApps become viable at practical cost, and DeFi contracts will use less budget for more complex logic thanks to native Value operations, raising the performance ceiling for DEX, AMM, and lending products.

  and I think Index-based contracts like oracles, Merkle proofs, and lookup tables become practical with the Array type, and legacy crypto verification opens up real integration with Web2 systems and external chains as well.

  This is the activation step that turns the ZK, Array, and Value work Cardano has been researching and building into actual products. That's why I'm voting Yes.

• Goofycrisp

  Yes50.5M ₳Rationale

  This proposal is a necessary technical update to support the upcoming Plutus improvements after the van Rossem hard fork. It enables new primitives, expands compatibility across Plutus V1, V2, and V3, and updates cost model settings based on benchmarking data.

  These changes help keep Cardano’s smart contract platform efficient, consistent, and ready for future development. For that reason, I will vote YES.

• AdaStat

  Yes50M ₳Rationale

  I definitely want to see these Plutus primitives on the mainnet.

• Chris-O

  Yes49.5M ₳No rationale
• PoolTool

  Yes47.6M ₳No rationale
• Patrick_Tobler

  Yes40.1M ₳No rationale
• drep1yffcjs0njfe...

  Yes38.1M ₳Rationale

  why not

• MUEN

  Yes34.6M ₳Rationale

  技術的には否決する理由がほとんどない必須のアップデートだと思います。

• Aichi/Tokai_DRep

  Yes31.4M ₳No rationale
• NEDSCAVE.IO

  Yes30.7M ₳No rationale
• TERA DRep

  Yes27.9M ₳No rationale
• Blockjock (James Meidinger)

  YesChanged26.1M ₳History

  Earlier votes

  No1mo agoSuperseded

  Yes1mo agoSuperseded

  New primitives don’t matter if they are unusable, overpriced, or inconsistent across versions.

  1. Constitutional Gate (2.4(a)(d))

  Assessment: PASS

  Supports:
  ecosystem growth
  developer capability expansion
  protocol efficiency
  Clearly scoped governance action:
  parameter update with defined technical objectives
  Backed by:
  benchmarking data
  committee review
  reproducible methodology

  This is a justified protocol maintenance and capability expansion action.

  1. Decision Declaration

  Vote: YES (Necessary Protocol Progression)
  This is a low-drama but important protocol upgrade enabling future smart contract capability and consistency.

  1. Context Framing

  This governance action updates the:

  Plutus V3 Cost Model

  To accomplish 3 things:

  Enable new primitives after Protocol Version 11 (van Rossem HF)
  Enable Plutus V3 primitives in:
  V1
  V2
  Recalibrate costs for certain existing primitives based on benchmarking data

  Core issue:

  New capabilities are meaningless unless execution pricing is accurate and usable.

  1. Core Evaluation
     4A. Strategic Alignment

  Directly aligned with:

  Smart contract evolution
  Developer flexibility
  Future scalability improvements

  Supports:

  Better cryptographic operations
  More efficient contract design
  Cross-version compatibility

  This is:

  execution-layer refinement necessary for ecosystem maturity

  4B. Economic / Market Impact

  Positive Effects:

  More efficient smart contract execution
  Potentially lower execution costs for advanced operations
  Better support for:
  ZK systems
  BLS operations
  advanced cryptography
  modular applications

  Important:
  This proposal does not directly create:

  TVL
  users
  revenue

  But it improves:

  the economic efficiency of applications built later
  4C. Execution & Accountability

  Strengths:

  Extensive benchmarking data published
  Transparent methodology provided
  Reviewed through:
  Intersect Parameter Committee
  Backed by:
  CIP references
  benchmarking repositories
  reproducible datasets

  Notable Strength:
  This is:

  parameter tuning grounded in empirical measurement, not arbitrary governance preference

  4D. Risk Assessment

  Primary Risks:

  Incorrect cost calibration:
  underpricing → resource abuse
  overpricing → poor developer adoption

  Secondary Risks:

  Unexpected performance edge cases post-HF
  Compatibility assumptions across V1/V2/V3 usage

  Mitigation:

  Benchmarking process
  Committee review
  Gradual activation via Protocol Version 11
  4E. End-User Impact

  Builders:

  More primitives available across versions
  Better cryptographic tooling
  Improved flexibility in contract design

  Users:

  Indirect benefit through:
  cheaper or more capable applications

  Capital Providers:

  More sophisticated financial primitives possible over time
  5. Governance Quality Signal

  This is a strong example of:

  technically grounded governance
  measurable parameter governance
  transparent benchmarking process

  Positive signal:

  governance handling protocol economics through evidence rather than politics

  1. Decision Justification

  This decision is based on:

  Necessary support for upcoming Protocol Version 11 features
  Strong technical validation and benchmarking transparency
  Improved consistency across Plutus versions and primitives
  7. Conditions to Change Vote
  Discovery of:
  inaccurate benchmarking
  exploitability through underpricing
  Major unforeseen execution regressions post-deployment
  8. Forward Impact

  If successful:

  Developers gain:
  broader primitive access
  improved execution economics
  Ecosystem gains:
  stronger cryptographic capabilities
  more efficient application design

  If unsuccessful:

  Potential:
  execution inefficiencies
  resource abuse
  degraded developer experience
  9. Stablecoin Utilization

  Not applicable directly.

  This proposal:

  does not involve treasury operational budgeting
  does not involve long-duration vendor execution risk

  Assessment:

  Neutral / N/A
  10. End-User Lens

  This matters because:

  Applications become:
  more capable
  potentially cheaper
  more secure

  Even though users won’t directly notice this change, developers will.

  Assessment Summary
  Category: Protocol Parameter / Execution Layer
  Strength: Empirically benchmarked capability expansion
  Weakness: Limited visibility to average users
  Risk Level: Low–Medium
  Conviction: Positive

• wolf31o2 (Chris Gianelloni)

  Yes23.5M ₳Rationale

  You updated your code with preview and preprod? Right?

• DINO

  Yes21.5M ₳No rationale
• Hephaestus Stake Pool [HEPHY]

  Yes21.5M ₳No rationale
• Ha-Nguyen

  Abstain21.4M ₳No rationale
• Moonstake

  Yes20.4M ₳No rationale
• CTEC-Stake-Pool

  Yes20.3M ₳No rationale
• Chris [STR8] - Straightpool

  Yes19.9M ₳Rationale

  Let's get those new Plutus features activated with the next hardfork.

• drep1ytf9f78k7rk...

  Yes17.4M ₳No rationale
• Rodrigo-[CHIL]

  Yes17.3M ₳Rationale

  Update Plutus Cost Models

• Cardanians

  Yes16.7M ₳Rationale

  This is a highly technical protocol-parameter proposal, so we rely heavily on the review process and technical validation behind it. The change was proposed by experts through Intersect’s Parameter Committee, reviewed and confirmed by the Technical Steering Committee, benchmarked against the reference implementation, and already enacted on SanchoNet, Preview, and Preprod testnets. Unless we hear negative technical feedback from qualified reviewers, we consider this parameter change to be as well validated as reasonably possible.

• RCADA

  Yes13.3M ₳Rationale

  RCADA votes YES on Update Plutus Cost Models.

  RCADA supports this parameter update because it is a necessary technical step to prepare Cardano for the new Plutus primitives that become available after the van Rossem hard fork to Protocol Version 11. The proposal also improves consistency by making Plutus primitives available across Plutus V1, V2, and V3, and it updates costs for some existing primitives based on benchmarking data.

  This is not a Treasury withdrawal and does not fund a project or vendor. It is a technical parameter update intended to ensure that Plutus script execution is priced correctly and safely as the platform gains new capabilities. Cost models are important because they determine how much CPU and memory a script operation is expected to consume. Without accurate cost models, new primitives cannot be responsibly enabled on mainnet.

  RCADA views this as important developer and infrastructure maintenance. The new primitives support areas such as cryptography, list manipulation, array operations, and value/data manipulation. These improvements can make smart contracts more capable, efficient, and predictable, especially for more advanced applications and future interoperability use cases.

  The process behind this update appears strong. The proposal states that the changes were recommended by Intersect’s Parameter Committee, confirmed by Intersect’s Technical Steering Committee, and tested through equivalent changes on SanchoNet, Preview, and Preprod before being submitted for mainnet approval.

  RCADA also notes that the proposal directly addresses the relevant constitutional guardrails. The metadata states that cost model values were benchmarked on the reference architecture, that the update is required because new Plutus primitives are being introduced, and that none of the new cost model values are negative.

  The main caution is timing and communication. The new primitives will only become available after the Protocol Version 11 hard fork, while some changes to existing primitives take effect immediately when this parameter update is enacted. Developers should be aware of that distinction and should review whether any existing scripts are affected by updated costs for current primitives.

  Overall, this appears to be a well-scoped, benchmarked, reviewed, and testnet-deployed technical update. It supports Cardano’s smart contract roadmap without creating Treasury spend or broad governance risk.

  For these reasons, RCADA votes YES.

  RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."

• concon

  Yes10.9M ₳No rationale
• Paul Ko

  YesRevoted10.8M ₳History

  Earlier votes

  Yes1mo agoSuperseded

• Dr. Navjit Dhaliwal

  Abstain10.4M ₳No rationale
• Cheeky Crypto (CHEEK)

  Yes9.2M ₳No rationale
• AKYO

  Yes8.8M ₳Rationale

  私はこの提案に賛成します。本提案は、Protocol Version 11（van Rossem ハードフォーク）に向けてPlutusコストモデルを更新し、新しいPlutusプリミティブの有効化とPlutus V1・V2・V3 間の整合性向上を行うものであり、Parameter Committeeの推奨、Technical Steering Committeeの確認、複数のテストネットでの展開、およびベンチマーク結果に基づく評価が実施されていることから、Cardanoの継続的な技術発展に資する提案であると考えるため、支持します。\n\nI support this proposal. This proposal updates the Plutus cost model in preparation for Protocol Version 11 (the van Rossem hard fork), enabling new Plutus primitives and improving consistency across Plutus V1, V2, and V3. Given that it has been recommended by the Parameter Committee, confirmed by the Technical Steering Committee, deployed on multiple testnets, and evaluated based on benchmarking results, I believe it will contribute to the continued technical development of Cardano; therefore, I support this proposal.

• drep1yt37s3z3ddz...

  Yes8.1M ₳No rationale
• InputEndorsers

  AbstainChanged7.6M ₳Rationale

  Changing my vote to ABSTAIN for the time being as there are seemingly some changes that are not backwards-compatible, according to votes from other DReps.

  This means I need to look into what this means as a precedent - in more detail instead of relying only on a technical assessment by the Intersect Parameter Committee as I did in my original YES vote.

  TL;DR: I don't want to help adopt of this proposal until I look at the circumstances in more detail. If I am unable to come to a different decision, my ABSTAIN will remain in effect.

  Earlier votes

  Yes1mo agoSuperseded

  Voting YES.
  The upgrade introduces new Plutus primitives for:
  cryptography
  list manipulation
  array operations
  value and data manipulation
  These upgrades enhance the capabilities of Plutus scripts, allowing more efficient computation and inter-chain working.
  No specific security concerns are raised by this change.
  If any new security concerns emerge in the meantime, I may change this vote.

• Chris Cata

  Yes5.9M ₳Rationale

  I am voting Yes.

  Although this is a highly technical parameter, I see sufficient benefit to parts of the ecosystem to support the change. It appears to be a measured adjustment that improves usability and flexibility without materially altering Cardano's core principles or security assumptions.

• drep1y2fhyudw8ju...

  Yes5.8M ₳No rationale
• ATLAS_Wolfgang

  Yes5.5M ₳No rationale