거버넌스 제안 상세
제안서 상세 내용과 투표 현황을 확인하세요.
한글 버전
- Intersect의 Parameter Committee는 이전에 권장된 두 가지 독립적인 프로토콜 파라미터 변경 사항을 하나로 묶은 단일 파라미터 업데이트 거버넌스 안건을 제안했음.
- minPoolCost: minPoolCost를 170,000,000 Lovelace(170 ₳)에서 75,000,000 Lovelace(75 ₳)로 약 55.9% 인하함.
- Plutus 메모리 유닛 제한(파트 2/2): maxTxExecutionUnits[memory]를 16,500,000에서 17,500,000 유닛으로(+6.1%) 늘리고, maxBlockExecutionUnits[memory]를 72,000,000에서 77,500,000 유닛으로(+7.6%) 늘려 연계된 파트 1 안건에서 시작된 두 단계 누적 25% 인상을 완료함.
- 이 두 변경 사항은 서로 무관함.
- 하나는 스테이크 풀 고정 수수료 하한선을 낮추고, 다른 하나는 Plutus 스크립트 실행 여유 공간을 늘림.
- 제출 효율성을 높이고 SPO들이 minPoolCost에 대해 의견을 제시할 수 있도록 이 안건에 함께 묶였음.
- 이 안건으로 인해 다른 프로토콜 파라미터나 Plutus 비용 모델 설정은 변경되지 않음.
■ 주석
*minPoolCost: 스테이크 풀 운영의 최소 고정 비용
***SPO: 스테이크 풀 운영자(Stake Pool Operator)
- minPoolCost: minPoolCost는 2023년(PCP-001)에 340 ₳에서 170 ₳로 인하되었으나, 준비금 기반 블록 보상의 지속적인 감소로 인해 그 혜택이 크게 약화되었음.
- 2023년 변경 이후 ~28.3%로 떨어졌던 단일 블록 풀에 대한 위임자 페널티는 그후 ~52.8%로 다시 올랐으며, 해결되지 않을 경우 2028년 2월(에포크 758경)에 100%에 이를 것으로 예상됨.
- IO Research의 최신 인센티브 보고서는 높은 고정 수수료 하한선이 대형 운영자에 의한 시빌(Sybil) 스타일의 스테이크 단편화를 억제하기보다 오히려 선호하게 만든다는 입장으로 선회했음.
- PCP-006(Cerkoryn, 2026)은 비례적인 minPoolMargin(CIP-0023)이라는 보다 구조적인 해결책을 기다리며 증거 기반의 중간 단계로서 75 ₳로의 추가 인하를 제안함.
- Plutus 메모리 유닛 제한: 이 2단계 변경의 파트 1은 가이드라인 MTEU-M-04 및 MBEU-M-03에 따라 허용되는 최대 단일 에포크 금액만큼 maxTxExecutionUnits[memory]와 maxBlockExecutionUnits[memory]를 늘렸음.
- Intersect Parameter Committee가 권장하고 Technical Steering Committee가 비준한 전체 25% 인상을 단일 에포크 내에서 개별 안건이 maxTxExecutionUnits[memory]는 2,500,000 유닛, maxBlockExecutionUnits[memory]는 10,000,000 유닛을 초과하여 늘릴 수 없기 때문에 파트 1 단독으로는 달성하지 못했음.
- 본 안건은 나머지 부족한 부분을 채워 두 파라미터를 원래 권장된 목표 값으로 맞추고, 이전 제한으로 인해 제약을 받던 DApp 개발자의 애로사항을 줄여줌.
■ 주석
*Sybil: 한 개인이 여러 개의 신원을 만들어 네트워크를 조작하려는 공격 방식
***DApp: 탈중앙화 애플리케이션
- minPoolCost 기술 평가 및 위원회 절차: 현재 170 ₳ 설정은 2023년 Intersect Parameter Committee가 권장하고 CIP-1694에 따른 온체인 파라미터 업데이트 거버넌스 안건이 도입되기 전인 에포크 445(2023년 10월)에 제정되었음.
- 75 ₳로의 추가 인하 제안은 Cerkoryn이 작성하여 2026년 3월 30일 Cardano Forum에 게시한 PCP-006의 주제이며, 수락 기준의 일환으로 Intersect Technical Steering Committee(TSC)의 승인을 명시적으로 요청했음.
- TSC는 2026년 7월 9일 이 인하를 비준했으며, 본 거버넌스 안건과 아래의 증거 기록은 해당 승인 절차와 후속 온체인 투표를 지원하기 위한 것임.
- minPoolCost 인플레이션 모델 및 보상 경제 하락: 셸리(Shelley) 출시 시점에 minPoolCost는 당시의 ₳ 가격, 인플레이션 일정, 예상 SPO 운영 비용을 기준으로 산정되었음.
- 준비금이 고갈됨에 따라 블록당 보상이 블록당 약 1,800 ₳에서 약 300 ₳로 떨어졌으며, 인프라 비용은 전반적으로 상승하여 2020년 이후 세 가지 입력값이 모두 크게 변동했음.
- PCP-001 부록 데이터를 보면 minPoolCost는 에포크당 한두 개의 블록만 생성하는 소규모 풀의 전체 보상에서 지나치게 큰 비중을 차지함.
- minPoolCost 경쟁 다이내믹스 및 트레저리 영향: 위임자는 풀의 예상 스테이킹 수익률(RoS)을 확인할 수 있으므로 minPoolCost 하한선에서 운영되는 소규모 풀은 대규모 풀에 비해 구조적으로 불리함.
- minPoolCost를 낮춘다고 해서 특정 SPO가 수수료를 낮추도록 강제되는 것은 아니지만, 하한선에 있는 소규모 풀들이 새로운 낮은 하한선을 채택하여 경쟁력이 향상될 것으로 기대됨.
- 이는 stakePoolTargetNum(k)과 직접적으로 관련이 있으며, 향후 k를 인상하기 전에 소규모 풀의 건강한 생태계가 경제적으로 생존 가능해야 하므로 이번 인하를 통한 소규모 풀 경제성 개선은 대안이 아닌 선행 필수 단계임.
- minPoolCost 인하는 트레저리 유입을 미미하게 감소시키며, Parameter Committee 경제 실무 그룹은 2023년 인하와 관련하여 트레저리 잔액이 예상치를 상회하므로 장기적인 경제 안정성에 위험이 없다고 평가했음.
- minPoolCost 시빌 공격 고려사항: 손실을 보면서 풀을 운영하여 지배적 지분을 확보하려는 공격자에게 최소 비용 하한선을 부과하는 것이 시빌 완화를 위한 minPoolCost의 원래 근거였음.
- PCP-001의 2023년 분석에 따르면 비근시안적 게임 이론 균형 하에서는 시빌 공격을 방지하는 데 minPoolCost가 엄격히 필요하지는 않지만, 악의적 행위자 모델 하에서는 실질적인 비용을 부과함.
- IO Research의 최신 보고서는 높은 고정 수수료 하한선이 고정 수수료를 반복 수취하기 위해 지분을 여러 풀로 쪼갤 수 있는 대자본 운영자의 시빌 스타일 지분 단편화를 억제하기보다는 오히려 선호하게 만든다고 결론지었음.
- 이에 따라 보안을 이유로 높은 하한선을 유지하는 주장이 약화되었으므로 0으로 즉시 이동하는 대신 75 ₳로의 추가 단계적 인하를 권장함.
- 2023년 이후의 실증적 증거: PCP-001 당시에는 없었던 2년간의 2023년 이후 데이터를 사용할 수 있게 되었음.
- 2023년에 제기된 '바닥으로의 경쟁(race to the bottom)' 우려와 달리 시장은 새로운 하한선으로 무너지지 않았으며, 340 ₳는 축소 후에도 여전히 주요 고정 수수료 설정으로 남았고 소규모 및 경쟁력 있는 풀만 낮은 하한선을 채택했음.
- IOR 보고서는 활성 풀 1,614개 중 873개 운영자(54%)가 일관된 블록 생성을 위한 약 3백만 ₳ 위임 임계값 아래에 머물러 있는 생태계 계층화를 기록하고 있으며, 이는 2023년 인하만으로는 근본적인 구조적 압력을 해결하지 못했음을 나타냄.
- 라이브 안건 PCP-006 및 향후 방향: 2026년 3월 30일 기준 PCP-006(Cerkoryn)은 단일 블록 풀에 대한 위임자 페널티를 초기 셸리 수준으로 회복하도록 170 ₳에서 75 ₳로 인하할 것을 요청하며, 이는 minPoolMargin 파라미터(CIP-0023)와 같은 구조적 해결책이 구현될 때까지의 임시 방편임.
- minPoolCost의 장기적 궤적은 파라미터 업데이트의 점진적 인하(CIP-0074)나 CIP-0023을 통한 구조적 교체를 통해 0 또는 기능적 무의미함을 향하고 있음.
- CIP-0082는 이러한 순서와 일치하는 minPoolCost 및 stakePoolTargetNum(k) 전반의 단계적 결합 로드맵을 제시함.
- 본 제안은 장기적인 구조적 프로세스와 독립적으로 지금 당장 이용할 수 있는 단기적이고 저위험인 단계임.
- minPoolCost 제안된 파라미터 변경: minPoolCost는 현재 설정인 170,000,000 Lovelace(170 ₳)에서 75,000,000 Lovelace(75 ₳)로 약 55.9% 감소함.
- 가이드라인과의 일치성: PARAM-05(거버넌스 핵심 파라미터에 대한 DRep 투표)에 따라 minPoolCost는 거버넌스 시스템에 핵심적인 파라미터에 포함되며, 원장의 비준 규칙에 의해 자동으로 강제되는 표준 DRep 과반수 임계값(활성 투표 지분의 50% 초과)의 대상이 됨.
- PARAM-06(3개월 통지): PCP-006은 2026년 3월 30일 Cardano Forum에 게시되었으며, 본 거버넌스 안건은 2026년 6월 30일 이전에 제출되지 않으므로 통지 기간을 충족하고 PCP-001(2023) 및 2022년 이후의 커뮤니티 주도 논의를 바탕으로 함.
- MPC-01: 제안된 설정(75,000,000 Lovelace)은 양수임.
- MPC-02: 제안된 설정은 500,000,000 Lovelace 상한선보다 훨씬 낮음.
- MPC-03: 제안된 75 ₳ 설정은 PCP-006에 따라 단일 블록 풀에 대한 위임자 페널티를 초기 셸리 수준에 가깝게 복원하도록 보정되었음.
- Plutus 메모리 제한 기술 평가: 두 Plutus 메모리 파라미터에 대한 전체 25% 인상은 2025년 5월 8일 Intersect의 Parameter Committee가 권장하고, 2025년 10월 1일 Intersect의 Technical Steering Committee가 비준했음.
- 이 권장과 비준은 전체 2단계 변경을 다루므로, 승인된 계획의 후반부를 구현하는 본 안건은 별도의 위원회 권장을 요구하지 않음.
- Plutus 메모리 제한 테스트넷 배포: 연계된 두 안건 전반에서 제안된 전체 목표 값(maxTxExecutionUnits[memory] 17,500,000 및 maxBlockExecutionUnits[memory] 77,500,000)은 2026년 7월 프리뷰(Preview) 테스트넷에서 함께 시험되었음.
- Plutus 메모리 제한 기능, 보안 및 성능: 본 안건의 효과는 단일 블록 내에서 Plutus 스크립트가 더 많은 작업을 수행할 수 있도록 하여 DApp 개발자와 사용자의 애로사항을 줄이는 것임.
- Praos 타이밍 보장이 유지되므로 특정 보안 우려는 제기되지 않음.
- maxTxExecutionUnits[memory]를 늘려도 성능에 영향이 없으며, maxBlockExecutionUnits[memory] 인상의 영향은 노드 버전 10.2 및 10.3을 사용하여 IOE의 Performance and Tracing 팀이 평가한 결과 중요한 타이밍 지표에서 적절한 여유 공간이 있음을 나타냄.
- Plutus 메모리 제한 제안된 파라미터 변경: 시작점 maxTxExecutionUnits[memory] 14,000,000, maxBlockExecutionUnits[memory] 62,000,000에서 파트 1은 각각 16,500,000(+17.9%), 72,000,000(+16.1%)으로 인상되었고, 파트 2(본 안건)는 각각 17,500,000(+6.1%), 77,500,000(+7.6%)으로 인상되어 누적으로는 둘 다 25.0% 인상됨.
- 이는 단일 블록에 들어갈 수 있는 최대 크기 트랜잭션 수(4개)에 대한 용량을 유지함.
- Plutus 메모리 제한 가이드라인과의 일치성: PARAM-03a(핵심 운영 파라미터에 대한 SPO 투표 필요)에 따라 maxBlockExecutionUnits[memory]는 블록체인 운영에 핵심적이므로 DRep 투표 외에도 활성 블록 생성 지분의 50% 초과라는 SPO들의 집단적 찬성이 필요하며, 이는 원장에 의해 자동으로 강제됨.
- PARAM-04a(3개월 통지): 25% 전체 목표를 다룬 2025년 7월 7일의 오프체인 게시를 통해 충족되었으므로 이 두 번째 단계를 위해 새로운 통지 기간이 필요하지 않음.
- NETWORK-01(2에포크당 1개 이하의 변경): 동일한 두 파라미터를 변경한 파트 1 이후 2에포크 이상 지나서 본 안건이 제정됨.
- NETWORK-02(상관관계가 없는 한 에포크당 1개의 네트워크 파라미터): maxTxExecutionUnits[memory]와 maxBlockExecutionUnits[memory]는 직접적인 상관관계를 가지며 본 안건에 의해 변경되는 유일한 네트워크 파라미터임.
- MTEU-M-01/02/03/04: 17,500,000은 40,000,000 상한선 미만이고, 양수이며, 이전 설정인 16,500,000보다 크고, 1,000,000 유닛 증가를 나타내며, 이는 에포크당 최대치인 2,500,000 유닛 이내임.
- MBEU-M-01/02/03/04a: 77,500,000은 120,000,000 상한선 미만이고, 양수이며, 5,500,000 유닛 증가를 나타내고, 이는 에포크당 최대치인 10,000,000 유닛 이내임.
- MEU-M-01: maxBlockExecutionUnits[memory]는 maxTxExecutionUnits[memory]보다 작지 않아야 하며 77,500,000은 17,500,000보다 현저히 큼.
- 결합된 가이드라인 참고: 본 안건은 minPoolCost(거버넌스 시스템에 핵심적, PARAM-05)를 maxBlockExecutionUnits[memory](블록체인 운영에 핵심적, PARAM-03a)와 함께 변경하므로 표준 DRep 투표 외에 SPO 투표를 유발함.
- 두 임계값 모두 특별다수제가 아닌 단순 과반수이며, SPO는 활성 블록 생성 지분의 50% 초과라는 집단적 지원으로 찬성해야 하고 보안 관련 파라미터 변경에 대한 온체인 곤잘레스(Conway) 제네시스 파라미터는 0.51(51%)로 설정됨.
- SPO들은 PARAM-05 자체의 요구사항이라기보다는 번들링의 결과로 minPoolCost를 포함하여 번들링된 안건 전체에 대해 투표함.
- DRep 임계값은 CIP-1694의 프로토콜 파라미터 그룹 규칙을 따르며, 안건이 여러 그룹에 걸쳐 있는 경우 두 그룹의 DRep 임계값 중 더 높은 값이 전체 안건에 적용됨.
- minPoolCost는 네트워크 파라미터가 아닌 경제/거버넌스 파라미터이므로 상관관계가 있는 메모리 제한 쌍과 함께 포함된다고 해서 여러 네트워크 파라미터의 번들링을 제한하는 NETWORK-02가 적용되지 않음.
- 복원 계획: minPoolCost는 보상 분배에만 영향을 미치고 블록 생성, 전파, 실행 제한과는 무관하므로 0으로 줄어들지 않은 이상 보안이나 성능 위험이 미미함.
- 모니터링을 통해 낮은 하한선을 악용하는 시빌 스타일 지분 단편화나 예상치 못한 트레저리 영향 등의 부작용이 발견되면 후속 안건을 통해 minPoolCost를 170 ₳로 복원할 수 있음.
- 그러나 minPoolCost는 풀이 인증서를 등록하거나 업데이트할 때만 강제되므로 온체인에 이미 있는 인증서에 소급 적용되지 않음.
- 결과적으로 하한선이 75 ₳인 동안 선언된 비용을 170 ₳ 미만으로 낮춘 SPO는 파라미터가 나중에 복원되더라도 170 ₳로 다시 올리도록 강제될 수 없으며 기존 등록은 다음에 새 인증서를 제출하기로 선택할 때까지 유효함.
- 따라서 복원은 새로운 풀 등록과 복원 후 자발적으로 재등록하는 풀에만 제한되며, DApp이나 스크립트 재작업을 강제하지 않음.
- Plutus 메모리 제한: 이 변경은 전반적인 네트워크 성능에 미치는 영향이 미미하거나 없으며 복원될 필요가 없을 것임.
- 후속 파라미터 업데이트 안건을 통해 maxTxExecutionUnits[memory]를 파트 1 이후 설정인 16,500,000으로, maxBlockExecutionUnits[memory]를 파트 1 이후 설정인 72,000,000으로 복원할 수 있으나 그렇게 하면 더 높은 제한을 활용해 온 DApp 개발자와 사용자에게 지장을 줄 수 있음.
- 둘 중 하나만 복원하면 단일 블록에 들어가는 전체 크기 Plutus 스크립트 트랜잭션 수가 변경되지만 해롭지는 않을 것임.
■ 주석
*RoS: 스테이킹 수익률(Return on Staking)
***Preview: 카르다노의 테스트넷 환경 중 하나
English
1. **minPoolCost:** decrease `minPoolCost` from 170,000,000 Lovelace (170 ada) to 75,000,000 Lovelace (75 ada), a decrease of approximately 55.9%.
2. **Plutus memory unit limits (Part 2 of 2):** increase maxTxExecutionUnits[memory] from 16,500,000 to 17,500,000 units (+6.1%) and maxBlockExecutionUnits[memory] from 72,000,000 to 77,500,000 units (+7.6%), completing the two-step, cumulative 25% increase to both parameters begun in the linked Part 1 action.
These two changes are otherwise unrelated: one lowers the stake pool fixed-fee floor, the other increases Plutus script execution headroom. The changes are bundled here for submission efficiency and to allow SPOs to give input on `minPoolCost`. No other protocol parameters or Plutus cost model settings are changed by this action.
**Plutus memory unit limits.** Part 1 of this two-step change increased `maxTxExecutionUnits[memory]` and `maxBlockExecutionUnits[memory]` by the maximum single-epoch amount permitted under guardrails MTEU-M-04 and MBEU-M-03. That step alone did not deliver the full 25% increase recommended by Intersect's Parameter Committee and ratified by the Technical Steering Committee, because no individual governance action may increase `maxTxExecutionUnits[memory]` by more than 2,500,000 units, or `maxBlockExecutionUnits[memory]` by more than 10,000,000 units, in a single epoch. This action makes up the remainder, bringing both parameters to their originally recommended target values and reducing pain points for DApp developers constrained by the pre-increase limits.
The current 170 ada setting was recommended by Intersect's Parameter Committee in PCP-001 (2023) and enacted in epoch 445 (October 2023), prior to the availability of on-chain Parameter Update governance actions under CIP-1694. The proposed further reduction to 75 ada is the subject of PCP-006, authored by Cerkoryn and published on the Cardano Forum on 30 March 2026, which explicitly requests Intersect Technical Steering Committee (TSC) endorsement as part of its acceptance criteria. The TSC ratified this reduction on 2026-07-09. This governance action, and the evidentiary record below, is intended to support that endorsement process and the subsequent on-chain vote.
### minPoolCost Inflation Model and Declining Reward Economics
At Shelley launch, `minPoolCost` was calibrated against prevailing ada price, the then-current inflation schedule, and estimated SPO operating costs. All three inputs have shifted materially since 2020: block rewards have fallen from roughly 1,800 ada to around 300 ada per block as the reserve depletes, while infrastructure costs have broadly risen. `minPoolCost` now represents a disproportionately large share of total rewards for small pools producing only one or a few blocks per epoch, as shown using PCP-001 appendix data (Epoch 415, approximate gross reward per block ~300 ada):
| Blocks/Epoch | minPoolCost (ada) | minPoolCost as % of Gross Reward |
| :---- | :---- | :---- |
| 1 | 340 | ~113% (no reward) |
| 1 | 170 | ~57% |
| 1 | 75 | ~25% |
| 2 | 340 | ~57% |
| 2 | 170 | ~28% |
| 5 | 340 | ~23% |
| 5 | 170 | ~11% |
### minPoolCost Competitive Dynamics and Treasury Impact
Because delegators can observe a pool's advertised Return on Staking (RoS), small pools operating at the `minPoolCost` floor are structurally disadvantaged relative to larger pools. Lowering `minPoolCost` does not force any SPO to reduce their fee, but market pressure is expected to lead small pools currently at the floor to adopt the new, lower floor, improving their competitiveness. This is directly relevant to `stakePoolTargetNum` (k): a healthy ecosystem of smaller pools must be economically viable before any future k increase is effective, so improving small-pool economics via this reduction is a prerequisite step, not an alternative. Separately, a reduction in `minPoolCost` marginally decreases treasury inflow at the margin; the Parameter Committee's economic working group assessed, in connection with the 2023 reduction, that treasury balance was above forecast projections and that a reduction posed no risk to long-term economic stability. No evidence has since emerged to change that assessment.
### minPoolCost Sybil Attack Considerations
The original rationale for `minPoolCost` as a Sybil mitigation rested on imposing a minimum cost floor on an adversary seeking to accumulate controlling stake by operating pools at a loss. PCP-001's 2023 analysis found that, under a non-myopic game-theoretic equilibrium, `minPoolCost` is not strictly necessary to prevent Sybil attacks, but under an adversarial-actor model (where an attacker is prepared to subsidise pool operation indefinitely to pursue consensus manipulation), it imposes a tangible cost. IO Research's updated incentives report has since revised this assessment, concluding that a high fixed-fee floor now more plausibly favours Sybil-style stake fragmentation by large, well-capitalised operators (who can split stake across many pools to harvest the fixed fee repeatedly) than it deters it, and recommends `minPoolCost` be lowered toward zero, ideally paired with a proportional `minPoolMargin` mechanism. This weakens, but does not eliminate, the case for preserving a high floor on security grounds, which is why this proposal recommends a further staged reduction to 75 ada rather than an immediate move to zero.
### minPoolCost Empirical Evidence Since 2023
Two years of post-2023 data are now available that were not available at the time of PCP-001. Contrary to "race to the bottom" concerns raised in 2023, the market did not collapse toward the new floor: 340 ada remained the dominant fixed-fee setting across pool sizes after the reduction to 170 ada, with only smaller, competitively-positioned pools adopting the lower floor so directly answering the empirical question PCP-001 left open. The IOR report also documents persistent ecosystem stratification: of 1,614 active pools, 873 operators (54%) remain below the roughly 3M ada delegation threshold associated with consistent block production, while only 289 pools could theoretically saturate given current delegated stake, indicating the 2023 reduction alone did not resolve the underlying structural pressure.
### minPoolCost Live Proposal PCP-006 and Future Trajectory
As of 30 March 2026, PCP-006 (Cerkoryn) requests a reduction from 170 ada to 75 ada, calibrated to restore the delegator penalty on single-block pools closer to the range experienced in early Shelley, and framed as a stopgap while the more complete structural solutions, such as a `minPoolMargin` parameter (CIP-0023), work toward implementation. Beyond this proposal, the long-term trajectory for `minPoolCost` points toward either zero or functional irrelevance: either via continued incremental Parameter Update reductions (as argued more aggressively by CIP-0074), or via structural replacement through CIP-0023's `minPoolMargin`, which scales proportionally with pool rewards and would eliminate the competitive distortion inherent in a fixed fee. CIP-0082 lays out a staged combined roadmap across `minPoolCost` and `stakePoolTargetNum` (k) consistent with this sequencing. This proposal is the near-term, low-risk step available now, ahead of and independent from that longer structural process.
### minPoolCost Proposed Parameter Change
`minPoolCost` will be decreased from its current setting of 170,000,000 Lovelace (170 ada) to 75,000,000 Lovelace (75 ada), a decrease of approximately 55.9%.
### minPoolCost Consistency with Guardrails
* **PARAM-05** (DRep vote for governance-critical parameters): `minPoolCost` is listed among parameters critical to the governance system; this action is subject to the standard DRep majority threshold (more than 50% of active voting stake), enforced automatically by the ledger's ratification rules.
* **PARAM-06** (3-month notice): PCP-006 was published on the Cardano Forum on 30 March 2026. This governance action is not intended for submission before 30 June 2026, satisfying the notice period; it also builds on public discussion dating back to PCP-001 (2023) and community advocacy since 2022.
* **MPC-01**: the proposed setting (75,000,000 Lovelace) is positive.
* **MPC-02**: the proposed setting is well below the 500,000,000 Lovelace ceiling.
* **MPC-03**: the proposed 75 ada setting is calibrated, per PCP-006, to restore the delegator penalty on single-block pools to a level closer to that experienced in early Shelley, reflecting current SPO operating costs and reward levels rather than the 2020 launch-era calibration.
### Plutus Memory Limits Technical Evaluation
The full 25% increase to both Plutus memory parameters (of which this action is the second and final step) was recommended by Intersect's Parameter Committee on [2025-05-08](https://forum.cardano.org/t/may-08-2025-parameter-committee-triweekly-meeting-notes/150392), and subsequently ratified by Intersect's Technical Steering Committee on 2025-10-01 (see [Recording](https://youtu.be/Gd7t52uh3m0?si=FIHpflP8yxH-xWqi&t=1110) or [Minutes](https://committees.docs.intersectmbo.org/intersect-technical-steering-committee/meeting-minutes/2025-tsc-meeting-minutes/meeting-minutes-october-01-2025#decisions-actions)). That recommendation and ratification covered the complete two-step change; this action does not require a separate committee recommendation, as it implements the second half of the same approved plan.
### Plutus Memory Limits Testnet Deployments
The full target values proposed across both linked actions (`maxTxExecutionUnits[memory]` of 17,500,000 and `maxBlockExecutionUnits[memory]` of 77,500,000) were exercised together on the Preview testnet during July 2026(`gov_action1m48mcctgp0tl508e0kq4hha02j7fsukjl5xx7h5mmwr0aupxp3gsqjwupe3`)
### Plutus Memory Limits Functionality, Security and Performance
The effect of this action is to enable more work to be done by Plutus scripts within a single block, reducing pain points for DApp developers and users. No specific security concerns are raised: Praos timing guarantees are maintained following the full 25% increase to both parameters. There is no performance impact from increasing `maxTxExecutionUnits[memory]`; the impact of the full increase to `maxBlockExecutionUnits[memory]` , inclusive of both Part 1 and Part 2, has been evaluated by IOE's Performance and Tracing team using node versions [10.2](https://updates.cardano.intersectmbo.org/reports/2025-03-execbudget-memory-10.2/) and [10.3](https://updates.cardano.intersectmbo.org/reports/2025-05-execbudget-memory-10.3/), which indicate adequate headroom in critical timing metrics for the complete proposed increase. More recent node versions provide further performance improvements.
### Plutus Memory Limits Proposed Parameter Change
| Step | maxTxExecutionUnits[memory] | Change | maxBlockExecutionUnits[memory] | Change |
| :---- | :---- | :---- | :---- | :---- |
| Starting point | 14,000,000 | — | 62,000,000 | — |
| Part 1 (enacted) | 16,500,000 | +2,500,000 (+17.9%) | 72,000,000 | +10,000,000 (+16.1%) |
| Part 2 (this action) | 17,500,000 | +1,000,000 (+6.1%) | 77,500,000 | +5,500,000 (+7.6%) |
| **Cumulative** | **17,500,000** | **+3,500,000 (+25.0%)** | **77,500,000** | **+15,500,000 (+25.0%)** |
This maintains capacity for the same number of maximally sized transactions (4) to fit into a single block.
### Plutus Memory Limits Consistency with Guardrails
* **PARAM-03a** (SPO vote required for critical operation parameters): `maxBlockExecutionUnits[memory]` is critical to blockchain operation, so this action requires SPOs to say "yes" with collective support of more than 50% of active block production stake, in addition to the DRep vote; this is automatically enforced by the ledger.
* **PARAM-04a** (3-month notice): satisfied by the [off-chain publication](https://forum.cardano.org/t/intention-to-changeplutus-script-memory-unit-limits-maxtxexecutionunits-memory-and-maxblockexecutionunits-memory/147270) of 2025-07-07, which covered the full 25% target; no fresh notice period is needed for this second step.
* **NETWORK-01** (no more than one change per two epochs): this action is enacted no less than 2 epochs after Part 1, which changed the same two parameters.
* **NETWORK-02** (one network parameter per epoch unless correlated): `maxTxExecutionUnits[memory]` and `maxBlockExecutionUnits[memory]` are directly correlated, as the guardrail itself notes, and are the only network parameters changed by this action.
* **MTEU-M-01/02/03/04**: 17,500,000 is below the 40,000,000 ceiling, positive, greater than the prior 16,500,000 setting, and represents a 1,000,000-unit increase; this is within the 2,500,000-unit per-epoch maximum.
* **MBEU-M-01/02/03/04a**: 77,500,000 is below the 120,000,000 ceiling, positive, and represents a 5,500,000-unit increase; this is within the 10,000,000-unit per-epoch maximum. Benchmarking (node 10.2, 10.3) confirms performance remains within stated bounds at this cumulative value.
* **MEU-M-01**: `maxBlockExecutionUnits[memory]` must not be less than `maxTxExecutionUnits[memory]` - 77,500,000 remains significantly greater than 17,500,000.
### Combined Guardrail Note
Because this action changes `minPoolCost` (critical to the governance system, PARAM-05) alongside `maxBlockExecutionUnits[memory]` (critical to blockchain operation, PARAM-03a), it triggers an SPO vote in addition to the standard DRep vote. Both thresholds are simple majorities, not supermajorities: per the Constitution's guardrail text, SPOs must say "yes" with collective support of more than 50% of active block production stake (PARAM-03a), and the on-chain Conway genesis parameter for this SPO threshold on security-relevant parameter changes is set at 0.51 (51%). SPOs will vote on the bundled action as a whole, including `minPoolCost`, as a consequence of bundling rather than a requirement of PARAM-05 itself. The DRep threshold follows CIP-1694's protocol-parameter-group rules: where an action spans multiple parameter groups — here, the Economic group (`minPoolCost`) and the Network group (the memory limits) — the higher of the two groups' DRep thresholds applies to the whole action; in this case both groups have the same current threshold. Finally, `minPoolCost` is an Economic/Governance parameter, not a Network parameter, so its inclusion alongside the correlated `maxTxExecutionUnits[memory]`/`maxBlockExecutionUnits[memory]` pair does not engage NETWORK-02, which restricts only the bundling of multiple Network parameters.
### Reversion Plan
**minPoolCost.** This change affects reward distribution only and has no bearing on block production, propagation, or execution limits, so since it has not been reduced to zero, it carries minimal security or performance risk. If monitoring reveals adverse effects, for example, evidence of Sybil-style stake fragmentation exploiting the lower floor, or unexpected treasury impact, then `minPoolCost` could be reverted to 170 ada via a subsequent action. However, `minPoolCost` is enforced only at the point a pool registers or updates its certificate; it is not retroactively re-applied to certificates already on-chain. Consequently, SPOs who lower their declared cost below 170 ada while the floor is 75 ada cannot be compelled to raise it back to 170 ada if the parameter is later reverted: their existing registration remains valid until they next choose to submit a new certificate. Reversion would therefore only constrain new pool registrations and any pool that voluntarily re-registers after the revert; it would not force any DApp, script, or transaction-level rework, nor would it force already-registered SPOs to change their pricing.
**Plutus memory limits.** This change has minimal or no effect on overall network performance and is unlikely to need to be reverted. `maxTxExecutionUnits[memory]` could be reverted to its post-Part-1 setting of 16,500,000, and `maxBlockExecutionUnits[memory]` to its post-Part-1 setting of 72,000,000, via a subsequent Parameter Update action, though doing so would disrupt any DApp developers and users who have taken advantage of the higher limits. Reverting one without the other would change the number of full-sized Plutus script transactions that fit in a single block but is unlikely to be harmful.
부가 정보
| 트랜잭션 해시 | ab474223d40e2e3540555364be27e161a809c33651408f43d84acff10c0ba306 |
|---|---|
| 블록 타임 | 1785432061 |
| Proposal ID | gov_action14dr5yg75pchr2sz42djtuflpvx5qnsek29qg7s7cft8lzrqt5vrqqtqntpk |
| Proposal Index | 0 |
minPoolCost를 75 ada로 줄이고 Plutus 메모리 제한 늘리기 (파트 2)에 대한 제안
현재 어디까지 왔나
📊 제안서 투표현황
DRep 투표현황
SPO 투표현황
헌법위원회 투표현황
📝 상세 설명
🇰🇷 한글 버전
- Intersect의 Parameter Committee는 이전에 권장된 두 가지 독립적인 프로토콜 파라미터 변경 사항을 하나로 묶은 단일 파라미터 업데이트 거버넌스 안건을 제안했음.
- minPoolCost: minPoolCost를 170,000,000 Lovelace(170 ₳)에서 75,000,000 Lovelace(75 ₳)로 약 55.9% 인하함.
- Plutus 메모리 유닛 제한(파트 2/2): maxTxExecutionUnits[memory]를 16,500,000에서 17,500,000 유닛으로(+6.1%) 늘리고, maxBlockExecutionUnits[memory]를 72,000,000에서 77,500,000 유닛으로(+7.6%) 늘려 연계된 파트 1 안건에서 시작된 두 단계 누적 25% 인상을 완료함.
- 이 두 변경 사항은 서로 무관함.
- 하나는 스테이크 풀 고정 수수료 하한선을 낮추고, 다른 하나는 Plutus 스크립트 실행 여유 공간을 늘림.
- 제출 효율성을 높이고 SPO들이 minPoolCost에 대해 의견을 제시할 수 있도록 이 안건에 함께 묶였음.
- 이 안건으로 인해 다른 프로토콜 파라미터나 Plutus 비용 모델 설정은 변경되지 않음.
■ 주석
*minPoolCost: 스테이크 풀 운영의 최소 고정 비용
***SPO: 스테이크 풀 운영자(Stake Pool Operator)
- minPoolCost: minPoolCost는 2023년(PCP-001)에 340 ₳에서 170 ₳로 인하되었으나, 준비금 기반 블록 보상의 지속적인 감소로 인해 그 혜택이 크게 약화되었음.
- 2023년 변경 이후 ~28.3%로 떨어졌던 단일 블록 풀에 대한 위임자 페널티는 그후 ~52.8%로 다시 올랐으며, 해결되지 않을 경우 2028년 2월(에포크 758경)에 100%에 이를 것으로 예상됨.
- IO Research의 최신 인센티브 보고서는 높은 고정 수수료 하한선이 대형 운영자에 의한 시빌(Sybil) 스타일의 스테이크 단편화를 억제하기보다 오히려 선호하게 만든다는 입장으로 선회했음.
- PCP-006(Cerkoryn, 2026)은 비례적인 minPoolMargin(CIP-0023)이라는 보다 구조적인 해결책을 기다리며 증거 기반의 중간 단계로서 75 ₳로의 추가 인하를 제안함.
- Plutus 메모리 유닛 제한: 이 2단계 변경의 파트 1은 가이드라인 MTEU-M-04 및 MBEU-M-03에 따라 허용되는 최대 단일 에포크 금액만큼 maxTxExecutionUnits[memory]와 maxBlockExecutionUnits[memory]를 늘렸음.
- Intersect Parameter Committee가 권장하고 Technical Steering Committee가 비준한 전체 25% 인상을 단일 에포크 내에서 개별 안건이 maxTxExecutionUnits[memory]는 2,500,000 유닛, maxBlockExecutionUnits[memory]는 10,000,000 유닛을 초과하여 늘릴 수 없기 때문에 파트 1 단독으로는 달성하지 못했음.
- 본 안건은 나머지 부족한 부분을 채워 두 파라미터를 원래 권장된 목표 값으로 맞추고, 이전 제한으로 인해 제약을 받던 DApp 개발자의 애로사항을 줄여줌.
■ 주석
*Sybil: 한 개인이 여러 개의 신원을 만들어 네트워크를 조작하려는 공격 방식
***DApp: 탈중앙화 애플리케이션
- minPoolCost 기술 평가 및 위원회 절차: 현재 170 ₳ 설정은 2023년 Intersect Parameter Committee가 권장하고 CIP-1694에 따른 온체인 파라미터 업데이트 거버넌스 안건이 도입되기 전인 에포크 445(2023년 10월)에 제정되었음.
- 75 ₳로의 추가 인하 제안은 Cerkoryn이 작성하여 2026년 3월 30일 Cardano Forum에 게시한 PCP-006의 주제이며, 수락 기준의 일환으로 Intersect Technical Steering Committee(TSC)의 승인을 명시적으로 요청했음.
- TSC는 2026년 7월 9일 이 인하를 비준했으며, 본 거버넌스 안건과 아래의 증거 기록은 해당 승인 절차와 후속 온체인 투표를 지원하기 위한 것임.
- minPoolCost 인플레이션 모델 및 보상 경제 하락: 셸리(Shelley) 출시 시점에 minPoolCost는 당시의 ₳ 가격, 인플레이션 일정, 예상 SPO 운영 비용을 기준으로 산정되었음.
- 준비금이 고갈됨에 따라 블록당 보상이 블록당 약 1,800 ₳에서 약 300 ₳로 떨어졌으며, 인프라 비용은 전반적으로 상승하여 2020년 이후 세 가지 입력값이 모두 크게 변동했음.
- PCP-001 부록 데이터를 보면 minPoolCost는 에포크당 한두 개의 블록만 생성하는 소규모 풀의 전체 보상에서 지나치게 큰 비중을 차지함.
- minPoolCost 경쟁 다이내믹스 및 트레저리 영향: 위임자는 풀의 예상 스테이킹 수익률(RoS)을 확인할 수 있으므로 minPoolCost 하한선에서 운영되는 소규모 풀은 대규모 풀에 비해 구조적으로 불리함.
- minPoolCost를 낮춘다고 해서 특정 SPO가 수수료를 낮추도록 강제되는 것은 아니지만, 하한선에 있는 소규모 풀들이 새로운 낮은 하한선을 채택하여 경쟁력이 향상될 것으로 기대됨.
- 이는 stakePoolTargetNum(k)과 직접적으로 관련이 있으며, 향후 k를 인상하기 전에 소규모 풀의 건강한 생태계가 경제적으로 생존 가능해야 하므로 이번 인하를 통한 소규모 풀 경제성 개선은 대안이 아닌 선행 필수 단계임.
- minPoolCost 인하는 트레저리 유입을 미미하게 감소시키며, Parameter Committee 경제 실무 그룹은 2023년 인하와 관련하여 트레저리 잔액이 예상치를 상회하므로 장기적인 경제 안정성에 위험이 없다고 평가했음.
- minPoolCost 시빌 공격 고려사항: 손실을 보면서 풀을 운영하여 지배적 지분을 확보하려는 공격자에게 최소 비용 하한선을 부과하는 것이 시빌 완화를 위한 minPoolCost의 원래 근거였음.
- PCP-001의 2023년 분석에 따르면 비근시안적 게임 이론 균형 하에서는 시빌 공격을 방지하는 데 minPoolCost가 엄격히 필요하지는 않지만, 악의적 행위자 모델 하에서는 실질적인 비용을 부과함.
- IO Research의 최신 보고서는 높은 고정 수수료 하한선이 고정 수수료를 반복 수취하기 위해 지분을 여러 풀로 쪼갤 수 있는 대자본 운영자의 시빌 스타일 지분 단편화를 억제하기보다는 오히려 선호하게 만든다고 결론지었음.
- 이에 따라 보안을 이유로 높은 하한선을 유지하는 주장이 약화되었으므로 0으로 즉시 이동하는 대신 75 ₳로의 추가 단계적 인하를 권장함.
- 2023년 이후의 실증적 증거: PCP-001 당시에는 없었던 2년간의 2023년 이후 데이터를 사용할 수 있게 되었음.
- 2023년에 제기된 '바닥으로의 경쟁(race to the bottom)' 우려와 달리 시장은 새로운 하한선으로 무너지지 않았으며, 340 ₳는 축소 후에도 여전히 주요 고정 수수료 설정으로 남았고 소규모 및 경쟁력 있는 풀만 낮은 하한선을 채택했음.
- IOR 보고서는 활성 풀 1,614개 중 873개 운영자(54%)가 일관된 블록 생성을 위한 약 3백만 ₳ 위임 임계값 아래에 머물러 있는 생태계 계층화를 기록하고 있으며, 이는 2023년 인하만으로는 근본적인 구조적 압력을 해결하지 못했음을 나타냄.
- 라이브 안건 PCP-006 및 향후 방향: 2026년 3월 30일 기준 PCP-006(Cerkoryn)은 단일 블록 풀에 대한 위임자 페널티를 초기 셸리 수준으로 회복하도록 170 ₳에서 75 ₳로 인하할 것을 요청하며, 이는 minPoolMargin 파라미터(CIP-0023)와 같은 구조적 해결책이 구현될 때까지의 임시 방편임.
- minPoolCost의 장기적 궤적은 파라미터 업데이트의 점진적 인하(CIP-0074)나 CIP-0023을 통한 구조적 교체를 통해 0 또는 기능적 무의미함을 향하고 있음.
- CIP-0082는 이러한 순서와 일치하는 minPoolCost 및 stakePoolTargetNum(k) 전반의 단계적 결합 로드맵을 제시함.
- 본 제안은 장기적인 구조적 프로세스와 독립적으로 지금 당장 이용할 수 있는 단기적이고 저위험인 단계임.
- minPoolCost 제안된 파라미터 변경: minPoolCost는 현재 설정인 170,000,000 Lovelace(170 ₳)에서 75,000,000 Lovelace(75 ₳)로 약 55.9% 감소함.
- 가이드라인과의 일치성: PARAM-05(거버넌스 핵심 파라미터에 대한 DRep 투표)에 따라 minPoolCost는 거버넌스 시스템에 핵심적인 파라미터에 포함되며, 원장의 비준 규칙에 의해 자동으로 강제되는 표준 DRep 과반수 임계값(활성 투표 지분의 50% 초과)의 대상이 됨.
- PARAM-06(3개월 통지): PCP-006은 2026년 3월 30일 Cardano Forum에 게시되었으며, 본 거버넌스 안건은 2026년 6월 30일 이전에 제출되지 않으므로 통지 기간을 충족하고 PCP-001(2023) 및 2022년 이후의 커뮤니티 주도 논의를 바탕으로 함.
- MPC-01: 제안된 설정(75,000,000 Lovelace)은 양수임.
- MPC-02: 제안된 설정은 500,000,000 Lovelace 상한선보다 훨씬 낮음.
- MPC-03: 제안된 75 ₳ 설정은 PCP-006에 따라 단일 블록 풀에 대한 위임자 페널티를 초기 셸리 수준에 가깝게 복원하도록 보정되었음.
- Plutus 메모리 제한 기술 평가: 두 Plutus 메모리 파라미터에 대한 전체 25% 인상은 2025년 5월 8일 Intersect의 Parameter Committee가 권장하고, 2025년 10월 1일 Intersect의 Technical Steering Committee가 비준했음.
- 이 권장과 비준은 전체 2단계 변경을 다루므로, 승인된 계획의 후반부를 구현하는 본 안건은 별도의 위원회 권장을 요구하지 않음.
- Plutus 메모리 제한 테스트넷 배포: 연계된 두 안건 전반에서 제안된 전체 목표 값(maxTxExecutionUnits[memory] 17,500,000 및 maxBlockExecutionUnits[memory] 77,500,000)은 2026년 7월 프리뷰(Preview) 테스트넷에서 함께 시험되었음.
- Plutus 메모리 제한 기능, 보안 및 성능: 본 안건의 효과는 단일 블록 내에서 Plutus 스크립트가 더 많은 작업을 수행할 수 있도록 하여 DApp 개발자와 사용자의 애로사항을 줄이는 것임.
- Praos 타이밍 보장이 유지되므로 특정 보안 우려는 제기되지 않음.
- maxTxExecutionUnits[memory]를 늘려도 성능에 영향이 없으며, maxBlockExecutionUnits[memory] 인상의 영향은 노드 버전 10.2 및 10.3을 사용하여 IOE의 Performance and Tracing 팀이 평가한 결과 중요한 타이밍 지표에서 적절한 여유 공간이 있음을 나타냄.
- Plutus 메모리 제한 제안된 파라미터 변경: 시작점 maxTxExecutionUnits[memory] 14,000,000, maxBlockExecutionUnits[memory] 62,000,000에서 파트 1은 각각 16,500,000(+17.9%), 72,000,000(+16.1%)으로 인상되었고, 파트 2(본 안건)는 각각 17,500,000(+6.1%), 77,500,000(+7.6%)으로 인상되어 누적으로는 둘 다 25.0% 인상됨.
- 이는 단일 블록에 들어갈 수 있는 최대 크기 트랜잭션 수(4개)에 대한 용량을 유지함.
- Plutus 메모리 제한 가이드라인과의 일치성: PARAM-03a(핵심 운영 파라미터에 대한 SPO 투표 필요)에 따라 maxBlockExecutionUnits[memory]는 블록체인 운영에 핵심적이므로 DRep 투표 외에도 활성 블록 생성 지분의 50% 초과라는 SPO들의 집단적 찬성이 필요하며, 이는 원장에 의해 자동으로 강제됨.
- PARAM-04a(3개월 통지): 25% 전체 목표를 다룬 2025년 7월 7일의 오프체인 게시를 통해 충족되었으므로 이 두 번째 단계를 위해 새로운 통지 기간이 필요하지 않음.
- NETWORK-01(2에포크당 1개 이하의 변경): 동일한 두 파라미터를 변경한 파트 1 이후 2에포크 이상 지나서 본 안건이 제정됨.
- NETWORK-02(상관관계가 없는 한 에포크당 1개의 네트워크 파라미터): maxTxExecutionUnits[memory]와 maxBlockExecutionUnits[memory]는 직접적인 상관관계를 가지며 본 안건에 의해 변경되는 유일한 네트워크 파라미터임.
- MTEU-M-01/02/03/04: 17,500,000은 40,000,000 상한선 미만이고, 양수이며, 이전 설정인 16,500,000보다 크고, 1,000,000 유닛 증가를 나타내며, 이는 에포크당 최대치인 2,500,000 유닛 이내임.
- MBEU-M-01/02/03/04a: 77,500,000은 120,000,000 상한선 미만이고, 양수이며, 5,500,000 유닛 증가를 나타내고, 이는 에포크당 최대치인 10,000,000 유닛 이내임.
- MEU-M-01: maxBlockExecutionUnits[memory]는 maxTxExecutionUnits[memory]보다 작지 않아야 하며 77,500,000은 17,500,000보다 현저히 큼.
- 결합된 가이드라인 참고: 본 안건은 minPoolCost(거버넌스 시스템에 핵심적, PARAM-05)를 maxBlockExecutionUnits[memory](블록체인 운영에 핵심적, PARAM-03a)와 함께 변경하므로 표준 DRep 투표 외에 SPO 투표를 유발함.
- 두 임계값 모두 특별다수제가 아닌 단순 과반수이며, SPO는 활성 블록 생성 지분의 50% 초과라는 집단적 지원으로 찬성해야 하고 보안 관련 파라미터 변경에 대한 온체인 곤잘레스(Conway) 제네시스 파라미터는 0.51(51%)로 설정됨.
- SPO들은 PARAM-05 자체의 요구사항이라기보다는 번들링의 결과로 minPoolCost를 포함하여 번들링된 안건 전체에 대해 투표함.
- DRep 임계값은 CIP-1694의 프로토콜 파라미터 그룹 규칙을 따르며, 안건이 여러 그룹에 걸쳐 있는 경우 두 그룹의 DRep 임계값 중 더 높은 값이 전체 안건에 적용됨.
- minPoolCost는 네트워크 파라미터가 아닌 경제/거버넌스 파라미터이므로 상관관계가 있는 메모리 제한 쌍과 함께 포함된다고 해서 여러 네트워크 파라미터의 번들링을 제한하는 NETWORK-02가 적용되지 않음.
- 복원 계획: minPoolCost는 보상 분배에만 영향을 미치고 블록 생성, 전파, 실행 제한과는 무관하므로 0으로 줄어들지 않은 이상 보안이나 성능 위험이 미미함.
- 모니터링을 통해 낮은 하한선을 악용하는 시빌 스타일 지분 단편화나 예상치 못한 트레저리 영향 등의 부작용이 발견되면 후속 안건을 통해 minPoolCost를 170 ₳로 복원할 수 있음.
- 그러나 minPoolCost는 풀이 인증서를 등록하거나 업데이트할 때만 강제되므로 온체인에 이미 있는 인증서에 소급 적용되지 않음.
- 결과적으로 하한선이 75 ₳인 동안 선언된 비용을 170 ₳ 미만으로 낮춘 SPO는 파라미터가 나중에 복원되더라도 170 ₳로 다시 올리도록 강제될 수 없으며 기존 등록은 다음에 새 인증서를 제출하기로 선택할 때까지 유효함.
- 따라서 복원은 새로운 풀 등록과 복원 후 자발적으로 재등록하는 풀에만 제한되며, DApp이나 스크립트 재작업을 강제하지 않음.
- Plutus 메모리 제한: 이 변경은 전반적인 네트워크 성능에 미치는 영향이 미미하거나 없으며 복원될 필요가 없을 것임.
- 후속 파라미터 업데이트 안건을 통해 maxTxExecutionUnits[memory]를 파트 1 이후 설정인 16,500,000으로, maxBlockExecutionUnits[memory]를 파트 1 이후 설정인 72,000,000으로 복원할 수 있으나 그렇게 하면 더 높은 제한을 활용해 온 DApp 개발자와 사용자에게 지장을 줄 수 있음.
- 둘 중 하나만 복원하면 단일 블록에 들어가는 전체 크기 Plutus 스크립트 트랜잭션 수가 변경되지만 해롭지는 않을 것임.
■ 주석
*RoS: 스테이킹 수익률(Return on Staking)
***Preview: 카르다노의 테스트넷 환경 중 하나
🇺🇸 English
1. **minPoolCost:** decrease `minPoolCost` from 170,000,000 Lovelace (170 ada) to 75,000,000 Lovelace (75 ada), a decrease of approximately 55.9%.
2. **Plutus memory unit limits (Part 2 of 2):** increase maxTxExecutionUnits[memory] from 16,500,000 to 17,500,000 units (+6.1%) and maxBlockExecutionUnits[memory] from 72,000,000 to 77,500,000 units (+7.6%), completing the two-step, cumulative 25% increase to both parameters begun in the linked Part 1 action.
These two changes are otherwise unrelated: one lowers the stake pool fixed-fee floor, the other increases Plutus script execution headroom. The changes are bundled here for submission efficiency and to allow SPOs to give input on `minPoolCost`. No other protocol parameters or Plutus cost model settings are changed by this action.
**Plutus memory unit limits.** Part 1 of this two-step change increased `maxTxExecutionUnits[memory]` and `maxBlockExecutionUnits[memory]` by the maximum single-epoch amount permitted under guardrails MTEU-M-04 and MBEU-M-03. That step alone did not deliver the full 25% increase recommended by Intersect's Parameter Committee and ratified by the Technical Steering Committee, because no individual governance action may increase `maxTxExecutionUnits[memory]` by more than 2,500,000 units, or `maxBlockExecutionUnits[memory]` by more than 10,000,000 units, in a single epoch. This action makes up the remainder, bringing both parameters to their originally recommended target values and reducing pain points for DApp developers constrained by the pre-increase limits.
The current 170 ada setting was recommended by Intersect's Parameter Committee in PCP-001 (2023) and enacted in epoch 445 (October 2023), prior to the availability of on-chain Parameter Update governance actions under CIP-1694. The proposed further reduction to 75 ada is the subject of PCP-006, authored by Cerkoryn and published on the Cardano Forum on 30 March 2026, which explicitly requests Intersect Technical Steering Committee (TSC) endorsement as part of its acceptance criteria. The TSC ratified this reduction on 2026-07-09. This governance action, and the evidentiary record below, is intended to support that endorsement process and the subsequent on-chain vote.
### minPoolCost Inflation Model and Declining Reward Economics
At Shelley launch, `minPoolCost` was calibrated against prevailing ada price, the then-current inflation schedule, and estimated SPO operating costs. All three inputs have shifted materially since 2020: block rewards have fallen from roughly 1,800 ada to around 300 ada per block as the reserve depletes, while infrastructure costs have broadly risen. `minPoolCost` now represents a disproportionately large share of total rewards for small pools producing only one or a few blocks per epoch, as shown using PCP-001 appendix data (Epoch 415, approximate gross reward per block ~300 ada):
| Blocks/Epoch | minPoolCost (ada) | minPoolCost as % of Gross Reward |
| :---- | :---- | :---- |
| 1 | 340 | ~113% (no reward) |
| 1 | 170 | ~57% |
| 1 | 75 | ~25% |
| 2 | 340 | ~57% |
| 2 | 170 | ~28% |
| 5 | 340 | ~23% |
| 5 | 170 | ~11% |
### minPoolCost Competitive Dynamics and Treasury Impact
Because delegators can observe a pool's advertised Return on Staking (RoS), small pools operating at the `minPoolCost` floor are structurally disadvantaged relative to larger pools. Lowering `minPoolCost` does not force any SPO to reduce their fee, but market pressure is expected to lead small pools currently at the floor to adopt the new, lower floor, improving their competitiveness. This is directly relevant to `stakePoolTargetNum` (k): a healthy ecosystem of smaller pools must be economically viable before any future k increase is effective, so improving small-pool economics via this reduction is a prerequisite step, not an alternative. Separately, a reduction in `minPoolCost` marginally decreases treasury inflow at the margin; the Parameter Committee's economic working group assessed, in connection with the 2023 reduction, that treasury balance was above forecast projections and that a reduction posed no risk to long-term economic stability. No evidence has since emerged to change that assessment.
### minPoolCost Sybil Attack Considerations
The original rationale for `minPoolCost` as a Sybil mitigation rested on imposing a minimum cost floor on an adversary seeking to accumulate controlling stake by operating pools at a loss. PCP-001's 2023 analysis found that, under a non-myopic game-theoretic equilibrium, `minPoolCost` is not strictly necessary to prevent Sybil attacks, but under an adversarial-actor model (where an attacker is prepared to subsidise pool operation indefinitely to pursue consensus manipulation), it imposes a tangible cost. IO Research's updated incentives report has since revised this assessment, concluding that a high fixed-fee floor now more plausibly favours Sybil-style stake fragmentation by large, well-capitalised operators (who can split stake across many pools to harvest the fixed fee repeatedly) than it deters it, and recommends `minPoolCost` be lowered toward zero, ideally paired with a proportional `minPoolMargin` mechanism. This weakens, but does not eliminate, the case for preserving a high floor on security grounds, which is why this proposal recommends a further staged reduction to 75 ada rather than an immediate move to zero.
### minPoolCost Empirical Evidence Since 2023
Two years of post-2023 data are now available that were not available at the time of PCP-001. Contrary to "race to the bottom" concerns raised in 2023, the market did not collapse toward the new floor: 340 ada remained the dominant fixed-fee setting across pool sizes after the reduction to 170 ada, with only smaller, competitively-positioned pools adopting the lower floor so directly answering the empirical question PCP-001 left open. The IOR report also documents persistent ecosystem stratification: of 1,614 active pools, 873 operators (54%) remain below the roughly 3M ada delegation threshold associated with consistent block production, while only 289 pools could theoretically saturate given current delegated stake, indicating the 2023 reduction alone did not resolve the underlying structural pressure.
### minPoolCost Live Proposal PCP-006 and Future Trajectory
As of 30 March 2026, PCP-006 (Cerkoryn) requests a reduction from 170 ada to 75 ada, calibrated to restore the delegator penalty on single-block pools closer to the range experienced in early Shelley, and framed as a stopgap while the more complete structural solutions, such as a `minPoolMargin` parameter (CIP-0023), work toward implementation. Beyond this proposal, the long-term trajectory for `minPoolCost` points toward either zero or functional irrelevance: either via continued incremental Parameter Update reductions (as argued more aggressively by CIP-0074), or via structural replacement through CIP-0023's `minPoolMargin`, which scales proportionally with pool rewards and would eliminate the competitive distortion inherent in a fixed fee. CIP-0082 lays out a staged combined roadmap across `minPoolCost` and `stakePoolTargetNum` (k) consistent with this sequencing. This proposal is the near-term, low-risk step available now, ahead of and independent from that longer structural process.
### minPoolCost Proposed Parameter Change
`minPoolCost` will be decreased from its current setting of 170,000,000 Lovelace (170 ada) to 75,000,000 Lovelace (75 ada), a decrease of approximately 55.9%.
### minPoolCost Consistency with Guardrails
* **PARAM-05** (DRep vote for governance-critical parameters): `minPoolCost` is listed among parameters critical to the governance system; this action is subject to the standard DRep majority threshold (more than 50% of active voting stake), enforced automatically by the ledger's ratification rules.
* **PARAM-06** (3-month notice): PCP-006 was published on the Cardano Forum on 30 March 2026. This governance action is not intended for submission before 30 June 2026, satisfying the notice period; it also builds on public discussion dating back to PCP-001 (2023) and community advocacy since 2022.
* **MPC-01**: the proposed setting (75,000,000 Lovelace) is positive.
* **MPC-02**: the proposed setting is well below the 500,000,000 Lovelace ceiling.
* **MPC-03**: the proposed 75 ada setting is calibrated, per PCP-006, to restore the delegator penalty on single-block pools to a level closer to that experienced in early Shelley, reflecting current SPO operating costs and reward levels rather than the 2020 launch-era calibration.
### Plutus Memory Limits Technical Evaluation
The full 25% increase to both Plutus memory parameters (of which this action is the second and final step) was recommended by Intersect's Parameter Committee on [2025-05-08](https://forum.cardano.org/t/may-08-2025-parameter-committee-triweekly-meeting-notes/150392), and subsequently ratified by Intersect's Technical Steering Committee on 2025-10-01 (see [Recording](https://youtu.be/Gd7t52uh3m0?si=FIHpflP8yxH-xWqi&t=1110) or [Minutes](https://committees.docs.intersectmbo.org/intersect-technical-steering-committee/meeting-minutes/2025-tsc-meeting-minutes/meeting-minutes-october-01-2025#decisions-actions)). That recommendation and ratification covered the complete two-step change; this action does not require a separate committee recommendation, as it implements the second half of the same approved plan.
### Plutus Memory Limits Testnet Deployments
The full target values proposed across both linked actions (`maxTxExecutionUnits[memory]` of 17,500,000 and `maxBlockExecutionUnits[memory]` of 77,500,000) were exercised together on the Preview testnet during July 2026(`gov_action1m48mcctgp0tl508e0kq4hha02j7fsukjl5xx7h5mmwr0aupxp3gsqjwupe3`)
### Plutus Memory Limits Functionality, Security and Performance
The effect of this action is to enable more work to be done by Plutus scripts within a single block, reducing pain points for DApp developers and users. No specific security concerns are raised: Praos timing guarantees are maintained following the full 25% increase to both parameters. There is no performance impact from increasing `maxTxExecutionUnits[memory]`; the impact of the full increase to `maxBlockExecutionUnits[memory]` , inclusive of both Part 1 and Part 2, has been evaluated by IOE's Performance and Tracing team using node versions [10.2](https://updates.cardano.intersectmbo.org/reports/2025-03-execbudget-memory-10.2/) and [10.3](https://updates.cardano.intersectmbo.org/reports/2025-05-execbudget-memory-10.3/), which indicate adequate headroom in critical timing metrics for the complete proposed increase. More recent node versions provide further performance improvements.
### Plutus Memory Limits Proposed Parameter Change
| Step | maxTxExecutionUnits[memory] | Change | maxBlockExecutionUnits[memory] | Change |
| :---- | :---- | :---- | :---- | :---- |
| Starting point | 14,000,000 | — | 62,000,000 | — |
| Part 1 (enacted) | 16,500,000 | +2,500,000 (+17.9%) | 72,000,000 | +10,000,000 (+16.1%) |
| Part 2 (this action) | 17,500,000 | +1,000,000 (+6.1%) | 77,500,000 | +5,500,000 (+7.6%) |
| **Cumulative** | **17,500,000** | **+3,500,000 (+25.0%)** | **77,500,000** | **+15,500,000 (+25.0%)** |
This maintains capacity for the same number of maximally sized transactions (4) to fit into a single block.
### Plutus Memory Limits Consistency with Guardrails
* **PARAM-03a** (SPO vote required for critical operation parameters): `maxBlockExecutionUnits[memory]` is critical to blockchain operation, so this action requires SPOs to say "yes" with collective support of more than 50% of active block production stake, in addition to the DRep vote; this is automatically enforced by the ledger.
* **PARAM-04a** (3-month notice): satisfied by the [off-chain publication](https://forum.cardano.org/t/intention-to-changeplutus-script-memory-unit-limits-maxtxexecutionunits-memory-and-maxblockexecutionunits-memory/147270) of 2025-07-07, which covered the full 25% target; no fresh notice period is needed for this second step.
* **NETWORK-01** (no more than one change per two epochs): this action is enacted no less than 2 epochs after Part 1, which changed the same two parameters.
* **NETWORK-02** (one network parameter per epoch unless correlated): `maxTxExecutionUnits[memory]` and `maxBlockExecutionUnits[memory]` are directly correlated, as the guardrail itself notes, and are the only network parameters changed by this action.
* **MTEU-M-01/02/03/04**: 17,500,000 is below the 40,000,000 ceiling, positive, greater than the prior 16,500,000 setting, and represents a 1,000,000-unit increase; this is within the 2,500,000-unit per-epoch maximum.
* **MBEU-M-01/02/03/04a**: 77,500,000 is below the 120,000,000 ceiling, positive, and represents a 5,500,000-unit increase; this is within the 10,000,000-unit per-epoch maximum. Benchmarking (node 10.2, 10.3) confirms performance remains within stated bounds at this cumulative value.
* **MEU-M-01**: `maxBlockExecutionUnits[memory]` must not be less than `maxTxExecutionUnits[memory]` - 77,500,000 remains significantly greater than 17,500,000.
### Combined Guardrail Note
Because this action changes `minPoolCost` (critical to the governance system, PARAM-05) alongside `maxBlockExecutionUnits[memory]` (critical to blockchain operation, PARAM-03a), it triggers an SPO vote in addition to the standard DRep vote. Both thresholds are simple majorities, not supermajorities: per the Constitution's guardrail text, SPOs must say "yes" with collective support of more than 50% of active block production stake (PARAM-03a), and the on-chain Conway genesis parameter for this SPO threshold on security-relevant parameter changes is set at 0.51 (51%). SPOs will vote on the bundled action as a whole, including `minPoolCost`, as a consequence of bundling rather than a requirement of PARAM-05 itself. The DRep threshold follows CIP-1694's protocol-parameter-group rules: where an action spans multiple parameter groups — here, the Economic group (`minPoolCost`) and the Network group (the memory limits) — the higher of the two groups' DRep thresholds applies to the whole action; in this case both groups have the same current threshold. Finally, `minPoolCost` is an Economic/Governance parameter, not a Network parameter, so its inclusion alongside the correlated `maxTxExecutionUnits[memory]`/`maxBlockExecutionUnits[memory]` pair does not engage NETWORK-02, which restricts only the bundling of multiple Network parameters.
### Reversion Plan
**minPoolCost.** This change affects reward distribution only and has no bearing on block production, propagation, or execution limits, so since it has not been reduced to zero, it carries minimal security or performance risk. If monitoring reveals adverse effects, for example, evidence of Sybil-style stake fragmentation exploiting the lower floor, or unexpected treasury impact, then `minPoolCost` could be reverted to 170 ada via a subsequent action. However, `minPoolCost` is enforced only at the point a pool registers or updates its certificate; it is not retroactively re-applied to certificates already on-chain. Consequently, SPOs who lower their declared cost below 170 ada while the floor is 75 ada cannot be compelled to raise it back to 170 ada if the parameter is later reverted: their existing registration remains valid until they next choose to submit a new certificate. Reversion would therefore only constrain new pool registrations and any pool that voluntarily re-registers after the revert; it would not force any DApp, script, or transaction-level rework, nor would it force already-registered SPOs to change their pricing.
**Plutus memory limits.** This change has minimal or no effect on overall network performance and is unlikely to need to be reverted. `maxTxExecutionUnits[memory]` could be reverted to its post-Part-1 setting of 16,500,000, and `maxBlockExecutionUnits[memory]` to its post-Part-1 setting of 72,000,000, via a subsequent Parameter Update action, though doing so would disrupt any DApp developers and users who have taken advantage of the higher limits. Reverting one without the other would change the number of full-sized Plutus script transactions that fit in a single block but is unlikely to be harmful.