The other serious post-Toccata discussion centered on fees, mempool policy, and how much control node operators should expose through configuration.
The public Toccata guide already makes the baseline clear. RPC transaction submission now applies a higher minimum standard fee rule: 100 sompi * max(compute grams, 2 * transaction bytes). The same guide states that this is a node policy and mempool rule, not a consensus rule. Consensus does not have a fee policy, and zero-fee transactions remain consensus-valid. (Toccata guide)
KaspaSilver raised the community version of the question in the R&D channel. He argued that some people did not understand that the fee increase was policy rather than consensus, and suggested making a user-friendly --minfee style argument or broader config path so miners could adjust fees themselves. [1] IzioDev said his own preference for a file-based config was partly about avoiding misleading operators: it is not just a parameter tweak, it is an entire policy change whose impacts should be understood. [2]
coderofstuff answered by separating mempool from consensus. He said the mempool is always more strict than consensus rules, and used the dust spam attack as the example: consensus could still consider a transaction valid, while updated mempool policy stopped relaying spam that would bloat the network. [3] He then pointed to KIP-9 and Crescendo as the later consensus-level spam-protection path, distinct from the quick mempool response. [4]
That distinction is the article. Node policy can protect the network before or beyond consensus rules, but configurability changes the meaning of "standard." coderofstuff said the notion of standardness becomes blurred if too much of the mempool becomes configurable, and asked which mempool parts beyond fee rate were being considered. [5] He then argued that some mempool protections should not be configurable, while other things like minimum fee rate may be more reasonable candidates. [6]
He also cautioned against treating one fixed config knob as the real solution. A better long-term answer, he argued, is likely something dynamic to network demand. [7] That matters because a static operator toggle can look like decentralization while actually making the network less predictable for wallets, apps, miners, and relay behavior.
The wallet side is not theoretical. coderofstuff noted that some wallets use a base fee of 0.0001 * UTXO_count, so from those wallets' perspective the new base fee is roughly a 10x change. He also said the change is in mempool policy, meaning it can be updated in a future release. [8]
KaspaSilver made the user-facing argument on X as well, saying the 100x base fee increase was "not as dramatic as it seems." (KaspaSilver on X) That is directionally consistent with the technical thread, but the better wording is tighter: the rule is not consensus, not permanent law, and not a reason to ignore fee-market UX. It is a standard relay policy that wallets and services now have to price against correctly.
The debate should stay open because both sides have real concerns. Operators should understand that policy is policy, not consensus. Builders should not hardcode old fee floors. But a proof-of-work network also needs standardness strong enough that ordinary users do not have to reason through every miner policy split before sending a transaction. The useful path is not "fees are nothing" or "fees are fatal." It is accurate fee estimation, dynamic policy where it makes sense, and careful limits on what gets turned into a casual config flag.
