Fee governance

The fee configuration is live in the immutable chain-ID-6 package at 0xc4dcb9a8a6dcabac0ae695fe95df5a7cb793f3f5766746ced70c1159705ec74b. The runtime registry has no pending core modules. The package was initialized through the recorded public ceremony and frozen under immutable policy 2.

Live schedule and hard caps

Fixed fees use SUPRA base units. Vesting fees use cumulative accounting over each position, so splitting one claim into many smaller claims does not reduce the total fee. Each transaction includes a user-signed maximum fee and aborts if the live schedule exceeds it. A failed creation or claim cannot leave a fee charge behind.

Fee-free products

The immutable release charges no protocol fee for:

• multi-send;
• Merkle airdrops;
• payment streams;
• staking pools;
• Digital Asset creation;
• Digital Asset locks; and
• Dexlyn LP locks.

These products are not economically interchangeable. For example, a payment stream can sometimes produce timing that resembles a token lock, but it has different state, lifecycle, and security semantics. The fee model does not claim to prevent product substitution.

Governance controls

The revision-5 launch schedule is below the immutable caps. The governor multisig proposes all three values with propose_schedule, including an effective time at least 60 seconds after chain time. After that time, any account may call apply_schedule. Direct set_schedule is disabled because this immutable deployment's schedule delay is nonzero.

Testnet governance console

The fee configuration console reads the active package, fee governor, owner set, threshold, queue, votes, caps, pending schedule, and chain time directly from Supra. It is public in read-only mode. A connected StarKey account receives transaction controls only when its address is one of the fee-governor multisig owners.

The browser ceremony follows the native 3-of-5 account:

1. one owner enters all three fee values and an effective time, reviews the exact base units, and creates a full-payload proposal;
2. two other owners switch to their own StarKey accounts, decode the stored on-chain payload, and approve it;
3. an owner executes the approved queue head to create the on-chain pending schedule; and
4. after the effective time, any account applies the schedule and confirms the event and fresh fee view.

The console refuses hash-only, malformed, unexpected-function, stale, or non-head proposals. It never asks for, receives, or stores a private key. Testnet operators import owner keys into StarKey and switch the active account between votes.

Authority is separated into three roles:

• the fee governor may propose schedules allowed by the deployed revision and begin renunciation;
• the treasury administrator may rotate itself and the collector; and
• the collector receives fixed SUPRA fees and in-kind vesting fees swept from position vaults.

Fee-role rotations use proposal-and-acceptance handshakes with their configured 60-second delay. The active release uses three distinct 3-of-5 multisig wallets and 15 unique owners; no single owner key can execute a governance transaction.

Anyone may trigger a vesting-fee sweep, but the on-chain destination is always the configured collector. Fixed SUPRA fees arrive directly in that collector account and remain transferable under its normal multisignature policy.

Fee governance can be irreversibly renounced through the same multisig-controlled flow. Initiation and finalization each include the exact terminal token-creation, fixed-lock, and vesting fee values as signed transaction arguments. The contract checks those values against the live schedule at both steps, rejects any intervening governance change, and emits the terminal schedule in both ceremony events. The SDK requires a fresh verified FeeConfigProof when it builds either transaction. Finalization clears the governor address and permanently disables fee-schedule changes. Treasury administration and collection remain available so previously accrued revenue is not stranded.