⚠ Preprod testnet

Demonstrate sample-protocol fee governance via a Plutus cost signal

System8d ago1 post

On-chain changes

  • TechnicalCost ModelsUpdatedUpdated

Abstract

This proposal demonstrates the governance validation design pattern. It is intended to update the fee parameter of a contrived sample protocol from 1,000,000 to 2,000,000 lovelace. The application change is coupled to a Cardano protocol-parameter governance action that increments Plutus V3 cost-model entry 42 by one while preserving every other cost-model entry. The Cardano parameter change is a deliberately chosen approval signal, not an economically motivated change to Cardano fees.

Motivation & rationale

Cardano applications often need community authorization for application-specific parameter changes, but implementing and operating a separate voting system duplicates governance machinery and fragments participation. This proposal demonstrates how an application can use Cardano governance as its approval process while retaining application-specific on-chain enforcement of the resulting state transition.

The sample protocol and its fee parameter are intentionally contrived. The purpose is to exercise and explain the design pattern end to end rather than to introduce a production protocol or claim that the sample fee has economic significance. The original author of this governance validation trick is Philip DiSarro.

When the proposal is added, one transaction atomically inserts its application payload into a shared on-chain proposal list and submits a matching Cardano protocol-parameter governance action. The governance action changes exactly one selected Plutus cost-model entry by +1 or -1; this demonstration uses a +1 change at Plutus V3 index 42. Every other entry in the complete cost model must remain unchanged. The proposal list permits only one active proposal for a selected cost-model position, preventing competing application payloads from claiming the same signal concurrently.

If Cardano governance ratifies and enacts the parameter update, the target complete cost model appears in the ledger's live Plutus language view. The governance validator treats that exact model as evidence that the associated application proposal passed. It then removes the active proposal from the list and creates a passed-proposal state carrying a PASS authorization token. A later permissionless finalization burns that token and requires both the sample protocol's stable governance withdrawal script and the proposal-specific final-action withdrawal script to execute. In this example, the proposal-specific script validates that the authenticated parameters UTxO is continued at the same address and that only its protocol_fee datum field changes, doubling it from 1,000,000 to 2,000,000 lovelace. An unpassed proposal can instead be removed after its expiry.

The passage proof deliberately authenticates the complete enacted cost model rather than the identity of the governance action that produced it. Any enacted action resulting in the identical complete model is therefore equivalent evidence of approval. The design assumes a socially canonical shared proposal list through which governance participants review the association between each one-entry cost-model signal and its application payload. This assumption, the contrived nature of the signal, and the absence of an intended economic effect on Cardano should all be considered when evaluating this demonstration.