Introduction

Objectives

This specification details the transaction fee mechanism (TFM) for the Nomos blockspace, which encompasses the finite resources of on-chain computation and permanent state storage. The design is engineered to achieve four primary, interconnected objectives:

To implement a market that allocates blockspace to transactions that derive the highest economic value from it, ensuring the network's limited capacity is used to maximize total utility.
To create an environment where the process of bidding for blockspace is intuitive and the transaction costs are predictable. This is paramount for fostering a healthy developer ecosystem and serving the professional entities, such as zones and rollups, that are the intended primary users of the Nomos network.
To design a system of rules where the dominant, profit-maximizing strategy for all participants (users and block proposers) is to behave honestly and in accordance with the protocol's intended function. This minimizes the potential for manipulative behaviors like transaction censorship or mempool gaming.
To ensure that network usage contributes directly to the economic value of the native Nomos token, creating a positive feedback loop between network adoption and the health of its underlying asset.

Design Rationale

The design process began with a fundamental choice between two distinct philosophies for fee market design, exemplified by EIP-1559 and StableFee: should the mechanism be optimized to manage short-term volatility or to provide long-term stability? (c.f. ‣). This document, together with our internal discussions, highly responsive, with a per-block fee adjustment designed to handle "rapid surges of user activity" characteristic of general-purpose L1s. However, the document, along with a key comment on its findings, correctly argues Nomos’ model doesn't map too well to a general-computation blockchain with user transactions (c.f. ‣).

This conclusion is rooted in the unique architectural premise of Nomos. The network is not primarily designed for a chaotic environment of retail users (c.f. Ethereum) but for a more regularized demand profile driven by a smaller set of high-volume, long-lived zones. For these users, cost predictability is paramount. The research confirms this, noting that "StableFee appears to perform better when... the inflow of transactions is relatively constant," (‣ ) a condition that directly mirrors the expected operational state of Nomos.

Therefore, the core rationale of this specification is to deliberately reject a mechanism designed for managing volatility and instead adopt and adapt a mechanism designed to provide stability.

Based on our analysis and the discussion above (c.f. ‣), we recommend a Nomos-Adapted StableFee Mechanism for the blockspace market. This model is a sophisticated implementation of the StableFee philosophy (c.f here) , tailored to the specific needs of Nomos. Our proposed methodology achieves the strategic simplicity of truthful bidding through a uniform clearing price, ensures proposer incentive compatibility via revenue smoothing, and integrates a fee-burn component to establish sound, deflationary tokenomics.

Overview

The mechanism operates on two core principles:

Truthful Bidding. Users are incentivized to bid their true maximum willingness to pay per unit of gas (their fee_cap), as overbidding provides no advantage.
Uniform Clearing Price. All transactions included in a single block pay the exact same price per gas unit. This price is determined by the fee_cap of the last, lowest-bidding transaction that was necessary to fill the block. This ensures fairness and eliminates the "winner's curse" of overpayment common in auctions.

The entire lifecycle, from user submission to proposer payment, can be visualized in the following flow:

graph TD
    %% --- Transaction Submission & Mempool ---
    TxIn["User Transactions<br>Each with a fee_cap (c_t)"] --> Mempool((Mempool));

    %% --- Block Construction by Proposer ---
    Mempool --> Sort["Sort Mempool by fee_cap (desc)"];
    Sort --> Fill["Fill Block with highest-bidding txs<br>until Gas Limit (G_max) is reached"];
    Fill --> DeterminePrice["Determine Clearing Price (P_clear)<br><br><i>P_clear = fee_cap of last included tx</i>"];
    
    %% --- On-Chain Fee & Revenue Logic ---
    DeterminePrice --> ApplyPricing["Apply Uniform Price to all txs<br>Final Fee = g_t * P_clear"];
    ApplyPricing --> CalcRevenue["Calculate Total Block Revenue<br>R_block = (Σ g_t) * P_clear"];
    CalcRevenue --> SplitRevenue{"Split Revenue"};
    SplitRevenue -- "Burn Rate (φ_burn)" --> Burned["Burned Portion"];