Fees and ordering

Frost is fee-blind. Transactions are ordered by consensus, without reference to what anyone paid, and executed in that order. A priority fee buys no position, no inclusion priority, and no latency.

This is not a policy choice layered on top of a normal fee market — it falls out of the architecture. The consensus layer orders opaque bytes. It does not run the EVM, cannot decode a transaction, and does not know what any of them pay. By the time anything can read a fee field, the order is already fixed.

What this means in practice

eth_maxPriorityFeePerGas returns 0. The chain neither requires a tip at admission nor suggests one.

eth_gasPrice returns the base fee. The EIP-1559 base fee is the entire fee market — the only congestion price.

maxFeePerGas is a bid for inclusion, not for position. Set it high enough to cover the base fee for as long as you want the transaction to remain valid. Setting it higher does not make the transaction land sooner.

A nonzero tip is not rejected — it is just wasted. If your tooling defaults to adding a tip, it will be spent for nothing. Most SDKs read eth_maxPriorityFeePerGas, so the correct behaviour usually happens automatically; the Frost SDKs default to zero explicitly.

What it means for MEV

The forms of MEV that depend on buying position in a block do not work here. There is no priority auction to win, so there is no way to pay to be placed immediately before or after a target transaction. Frontrunning and sandwiching by fee bidding have no mechanism.

Be clear about what this does not eliminate. Ordering is still ordering: someone who observes a transaction and submits their own quickly may still land ahead of it, because being earlier is what determines position. The chain removes the auction, not the race. And nothing here prevents an application-level design from creating value that is extractable at the application layer.

Base fee behaviour

The base fee follows EIP-1559 against the block gas limit, rising when blocks are consistently fuller than target and falling when they are emptier. On a lightly loaded network it decays to a floor of a few wei.

Two things to keep in mind when sizing a transaction:

Frame transactions are calldata-heavy. A post-quantum witness is several kilobytes, and calldata gas dominates the cost of a spend — more than the signature verification does. Growth in the base fee therefore hits post-quantum transactions harder than plain transfers.

The transaction-level gas limit is signed. For a frame transaction, gas_limit is covered by the signature hash, the payer is charged it up front, and unused gas is refunded. It must be at least the transaction’s computed total. Signing it is what bounds the padding a relayer could otherwise add.

Paying for someone else

Because a frame transaction names its payer separately from its executor, one account can pay for another’s transaction without a bundler, and without the sponsor’s key sitting on the critical path as a classical signature.

The most important use of this is the one you get for free: an account’s first transaction pays for its own deployment out of the funds already sent to its counterfactual address. No sponsor is needed to get started. See Counterfactual onboarding.

Next

• Fee-blind ordering — why the chain is built this way.
• Transaction type 0x06 — the exact gas accounting.