NMESH utility, discounts and protocol economics

Four proposed uses, each with a policy boundary#

The discount is a proposed purchase benefit, not a promise that the token increases in value. Governance concerns listing standards, market parameters and protocol policy. Staking is proposed as part of a provider-failure backstop, while fee rebates depend on eligible activity.

Each use needs separate rules. A holder voting on market policy does not automatically become an insurer, and a rebate does not establish a share of all protocol revenue. The brief leaves final eligibility, treasury limits and the relationship between rewards and actual revenue open.

A discount must have a funding source#

Illustration: if an eligible compute subtotal is $1,000, a 6% discount is $60 before considering any separate fees or final policy. The same $60 is a cost to the party funding it. The brief proposes sharing that cost between broker commission and the NMESH treasury but does not publish the split.

The swap interface shows this same $1,000 subtotal and $60 discount as a labelled illustration. That arithmetic is not a finalized commercial quote, an eligibility decision or proof that treasury funds have been reserved. A production checkout must disclose the applicable base, cap, conversion price and resulting total.

Volume is not revenue#

The proposed revenue stack includes trading fees, broker commissions on delivered capacity and settlement fees for verification, clearing and document handling. These revenue sources need separate measurement because their activity bases differ.

A meaningful operating model separates traded notional, provider payouts, net fees, payment and verification costs, insurance reserves, liquidity incentives and treasury-funded discounts. High trading volume can coexist with low or negative contribution after incentives and losses.

Trading revenue = traded GPU-hours × price per GPU-hour × take rate
Broker revenue = delivered GPU-hours × commission per GPU-hour
Settlement revenue = settled contracts × fee per contract

Then account separately for payouts, incentives, payment costs,
verification costs, reserve allocations and discount subsidies.

Treasury obligations can accumulate#

Initial market liquidity and purchase discounts both draw on the proposed treasury role. They should have separately visible budgets. A liquidity inventory loss should not be hidden inside discount utilization, and a nominal token balance is not the same as liquid funds available for refunds.

The brief calls for caps, anti-abuse controls, transparent inventory and governance-approved rules. Repeated self-dealing purchases or incentive-driven volume could distort metrics without generating durable demand. Economic simulations should test those behaviors before incentives are offered.

What remains undecided?#

Final supply, emissions, unlocks, discount eligibility, cap policy, staking terms and revenue-linked reward design are not established by this documentation. No token price target, yield forecast or investment recommendation follows from the proposed utilities.

The priority in the brief is proving a small delivery-and-settlement loop with clear economics. Discount utilization, treasury exposure, repeat buyers and net revenue after costs are more useful validation signals than a token-feature checklist.

• See the staged validation plan ↗
• Read the payment boundaries ↗