just spent the last two days going through the transaction fee section line by line and honestly the more i sit with the formula the more i think its doing three completely different jobs simultneously...
most people think of transaction fees as one thing. you pay to transact. but on midnight the fee is actually three separate components that each solve a different problem, and understanding what each one is doing changes how you read the whole system.
the first component is the minimum fee. fixed, configurable, payable on every transaction regardless of network conditions
this ones pure anti-spam infrastructure. the whitepaper is explicit about its purpose -making it prohibitively expensive in DUST terms for an attacker to sustain millions of small transactions over extended periods. it doesnt fluctuate
it doesnt respond to demand
it just sits there as a flat floor that every transaction has to clear before it even gets considered.
the second component is transaction weight. right now this reflects storage space - how many kilobytes a transaction occupies in a block. given that blocks have a fixed size limit, weight is essentially your transaction's claim on scarce block space. the whitepaper notes this is expected to expand later to include compute and disk read usage, but at launch its KB only
heavier transactions cost more
simple
the third component is the congestion rate - and this is where the formula gets interesting.
the congestion rate is a dynamic multiplier applied to transaction weight. it adjusts block by block based on how far current utilization sits from the 50% target
above 50% it rises
below 50% it falls
and because each block's rate is calculated from the previous block's rate, sustained demand compounds it upward exponentially.
put them together and the full fee for any transaction at block n is: congestion rate x transaction weight, plus the minimum fee. three numbers, one DUST cost.
what this design gets right is the separation of concerns
the minimum fee handles attacks
transaction weight handles resource consumption. the congestion rate handles demand management. each component has one job and they dont interfere with each other.
but heres the thing i keep coming back to. transaction weight is currently KB only. compute intensity and disk read are explicitly described as future additions. that means right now a computationally heavy ZK transaction and a lightweight transfer pay the same weight-based fee if they occupy the same bytes
the resource cost to the network isnt fully captured in the fee yet.
honestly dont know if the three-component formula is the clean modular fee architecture that handles every network condition correctly once weight expands to include compute or an incomplete pricing signal that undercharges heavy computation until that expansion actually ships?? 🤔
#night @MidnightNetwork $NIGHT
