Fee governance

The fee configuration is live in the active immutable chain-ID-6 revision-6 package at 0x0afbe7d92996d30632c228665bac163478ae2a04922fdfc8cb3c69a51fba9230. The package was initialized through the recorded public ceremony and frozen under immutable policy 2. The retained claim-only revision-5 package at 0xc4dcb9a8a6dcabac0ae695fe95df5a7cb793f3f5766746ced70c1159705ec74b keeps its own fee configuration and governance for its existing positions.

Fee schedule and hard caps#

The revision-6 acceptance run applied the testnet schedule through propose_schedule and apply_schedule after the 300-second delay (shortened for testing). The first two columns are a historical record, not the current fee: governance can change the schedule at any time within the caps. Always read the live schedule view before signing; the dApp shows it on every fee-charging action.

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 schedule is below the immutable caps. The fee governor proposes all three values with propose_schedule, including an effective time at least the configured delay after chain time: 300 seconds on revision-6 testnet (shortened for testing; mainnet payloads use 604,800 seconds) and 60 seconds on the retained revision-5 package (also shortened for testing). After that time, any account may call apply_schedule; on revision 6 it must do so within the 14-day acceptance window. Direct set_schedule is disabled because both immutable deployments have a nonzero schedule delay.

On revision-6 testnet the fee governor, treasury administrator, and collector are single-key testnet wallets held by one operator. This is role separation for testing, not a multisig and not independent custody. The revision-5 roles are three distinct 3-of-5 multisig wallets.

Testnet governance console#

The fee configuration console (Protocol › Fee configuration in the dApp sidebar) reads the active package, current fees, fee governor, fee change, role change, and renounce delays, pending schedule, and chain time directly from Supra. It reads the governor's custody from chain: a single-key governor is shown as such, and the owner set, threshold, queue, and votes are shown only when the governor is a multisig. If the account type cannot be read, the console shows "Governor custody unknown" instead of a custody claim.

The console is public and read-only until a connected StarKey account can act for the fee governor: as the governor wallet itself (badge Governor connected), or as one of its owners when the governor is a multisig (Owner connected). A single-key governor proposes and cancels a pending schedule directly. Anyone can apply a pending schedule after its activation time. A pending schedule that passed its 14-day acceptance window is labelled Pending fee schedule expired, and the governor can replace it with a new proposal.

For a multisig-held governor, such as the revision-5 governor, 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 delay (300 seconds on revision-6 testnet and 60 seconds on revision 5, both shortened for testing). On revision 5, three distinct 3-of-5 multisig wallets with 15 unique owners hold the roles, so no single owner key can execute a governance transaction. On revision-6 testnet each role is a single key.

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 that account's normal signing policy.

Fee governance can be irreversibly renounced through the same governor-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.

Revision 6 rules#

The active revision-6 package tightens these controls. The retained revision-5 package is immutable and keeps its original rules, under which a pending proposal does not expire.

• Every governance delay must be at least 48 hours (172,800 seconds) unless the chain is Supra testnet (chain ID 6) or the framework test chain (chain ID 4); mainnet and unknown chains fail closed, so immediate set_schedule can never run on mainnet.
• A matured schedule, role rotation, or renunciation must execute within a 14-day acceptance window (1,209,600 seconds, inclusive) after its effective time. After that it aborts with EPROPOSAL_EXPIRED (fee_config code 23) and must be canceled or proposed again.
• Accepting a new fee governor cancels any schedule the previous governor proposed.
• The collector must already hold a registered SUPRA store when it is set, proposed, and accepted.

See the governance delay configuration record for exact abort codes.