Transaction fee economics in NEAR

NEAR is a sharded Proof-of-Stake blockchain that recently launched its main net. Their goal is to compete with Ethereum for smart contract developers.

Today I want to point out two NEAR features that might seem like quirks at first but are probably closer to serious design mistakes. Both are related to how transaction fees work.

The theory behind transaction fees

Before we dive in, here is why public blockchains use transaction fees. Fees (1) compensate block producers for including a transaction, and (2) mediate priority among transactors.

Dissecting that a little further, the transaction fee is an incentive for block producers to process your transaction, include it in a block, attest to it with a proof of work or proof of stake, and then relay it to the rest of the network.

This incentive is necessary because the above steps have a cost to block producers, who need to expend bandwidth, computation, and storage. If users want to have their transactions included in blocks, they need to compensate block producers for this cost.

Further, transaction fees mediate the priority among transactors. Having a good mediation mechanism ensures that transactors who value priority more will get their transactions mined first, thereby maximizing collective utility.

NEAR implements EIP-1559…

After Celo and Filecoin, NEAR is the third network to implement EIP-1559 before it activates on Ethereum itself. For a deep dive on the topic, read my long-form analysis with Georgios Konstantopoulos.

In short, EIP-1559 is a major change to how users bid for transaction inclusion from how the major public blockchains like Bitcoin and Ethereum work today. Instead of users engaging in a first-price auction, the protocol enforces a minimum transaction fee, called the base fee, and burns it. The fee’s size depends on the recent utilization of the blockchain capacity, targeting an average usage of 50%. When utilization has been above 50%, the fee rises to make usage more expensive. When it has been below 50%, the fee falls to entice more usage.

On top of the base fee, there is a second fee, called the “tip.” Instead of being burned, this tip is paid directly to miners as the minimum-viable solution to the two functions of transaction fees described earlier. It compensates miners for the additional uncle risk they incur by mining larger blocks, and it negotiates priority among transactors.

There are many substantial benefits to this change; one of them is that it makes fees more predictable to users and almost completely eliminates overbidding.

…but with two major differences

At first glance, NEAR has copied EIP-1559 exactly. For example, the maximum fee change per block in Ethereum is 12.5%, and the block time is 12-13 seconds. In NEAR, the maximum change is 1% at 1 second block time.

On second sight, there are two big differences in NEAR:

1. Users are not allowed to tip (incentivize) block producers in-protocol.
2. It pays 30% of the base fee to smart contracts.

No tip to block producers

I was surprised to discover a public blockchain that doesn’t allow users to incentivize block producers to include their transactions. Instead, NEAR simply assumes block producers will always fill blocks as much as they can. This assumption is safer in PoS than in PoW because block producers don’t need to minimize propagation delay.

So if you recall the reasons we need transaction fees, how does NEAR address them? Every included transaction still pays the base fee, making it expensive for an attacker to spam the network.

At the same time, block producers are compensated for the resources they expend with a perpetual block subsidy as well as the appreciation of their stake from:

1. providing reliable service to users, which hopefully increases the demand for the NEAR token over time;
2. the burning of transaction fees.

However, it completely fails to address the second goal of mediating priority among transactors. We can demonstrate that with two examples.

Failing to optimize transactor welfare

First, what happens if the demand to transact is higher than the current gas limit? Block producers could process transactions in a first-come-first-serve manner, but this strategy is naive for several reasons. First, it doesn’t ensure the optimal allocation of resources we discussed. Whenever some transactions have to remain in the memory pool, block producers have no way to ensure that they process the highest utility transactions. In Bitcoin or Ethereum, transactions with higher utility would naturally pay a larger fee to miners to ensure they get into the current block.

When I brought up this issue with a NEAR co-founder, they said the blockchain wouldn’t operate at capacity for a long time, and hence this kind of priority auction isn’t necessary. But this misses the point. Users don’t just bid for priority when the block is full, but also whenever two users publish conflicting transactions.

This kind of transaction is very common in stateful chains because users frequently compete to manipulate the global state in a profitable way.

Take, for example, an AMM-based exchange like Uniswap. Whenever a token’s price moves on a different exchange, all Ethereum users compete to buy or sell the token on Uniswap at the stale price, booking an instant arbitrage profit. However, only the first user in a block can complete the trade, whereas everyone else will eat a small loss from their failed transaction.

As a result, these mutually exclusive transactions engage in constant bidding wars in the memory pool. These bidding wars happen even when blocks are 10% full because the arbitrageur doesn’t simply care if they can get their transaction included in the block. They must also get their transaction included before other arbitrageurs.

Now you could respond that we don’t even want our public blockchains to be these scary dark forests. And while your motivation would be good, banning transaction fees can’t be the solution for three reasons.

1. It doesn’t just ban fees for arbitrageurs and frontrunners, but also for regular users whenever demand to transact exceeds capacity.
2. Block producers can, and increasingly will, capture these same profit opportunities from transaction ordering themselves. Any solution must also bind them as well, not just users.
3. Just because priority auctions are banned in-protocol doesn’t mean users and block producers will not engage in them.

Especially the latter deserves some unpacking.

Encouraging a black market for priority

A user who can make $10,000 from getting their transaction mined first in a block will pay up to $10,000 to achieve that goal. Likewise, a block producer wants to earn that $10,000, and so the two will discover a way to create the same priority market outside the network.

Encouraging this “black market” for priority has only downsides to NEAR itself.

1. It creates two classes of users – those with access to the black market and those without.
2. It weakens NEAR as the native currency because there is no reason to use it for deals outside of the network.
3. It makes the network overall less efficient and more wasteful because infrastructure must be built & maintained, and more messages and payments must be sent.

For these reasons, I hope that NEAR will amend the ability to bribe block producers in-protocol in short order.

Base fee paid to smart contracts

Whereas Ethereum’s EIP-1559 burns the entire base fee (thereby transferring wealth to token holders via deflationary pressure), NEAR only burns 70% of the base fee and pays 30% to smart contracts used in the previous epoch.

Initially, this mechanism seems to solve one of the biggest problems in open-source software development: It is tough to monetize since fees can be easily forked out. This is especially true for developer libraries or other middleware with no network effect or other user lock-in.

Upon further inspection, I believe that contract rewards create several bad incentives:

Futile attempt at price-fixing

First, the idea that you can just implement a fee in-protocol to prevent it from being forked out is too naive because, similarly to the fee issue, it ignores that users can circumvent the mechanism. The designers of EIP-1559 understood this, which is why in other implementations of this mechanism, the fee is fully burned. This is the only way miners or developers cannot pay it back to users.

Without the burn, the base fee is merely a weak attempt at price-fixing that doesn’t change the equilibrium price of using a smart contract. In any hyper-competitive market, which definitely includes public blockchains, producers are in a race to the bottom to minimize rent-extraction and offer their service to users at the smallest possible profit margin.

A forced rent doesn’t change this equilibrium. Users will still seek out the lowest fee applications, which creates an overwhelming incentive for app developers to pay back the entire rent to users. If all applications pay the reward back, we are back at square one but with a blockchain clogged by unnecessary payback transactions.

Encouraging wasteful gas usage

Second, this isn’t the only impact on the chain – the way this mechanism works also creates a direct link between gas consumption and revenue for the application developer. This doesn’t have to be a problem in practice since users might still prefer the cheapest system, and there continues to be a race to the bottom. Nonetheless, it gets less pressing for developers to minimize the amount of gas their smart contracts consume.

This incentive can go as far as devs writing deliberately expensive code or form powerful interest groups that could oppose scalability advancements in governance because it would directly hurt their bottom line.

Breaking EIP-1559

Finally, I strongly suspect that the new equilibrium hurts the incentive-compatibility of the EIP-1559 mechanism itself. If all contracts pay back their rewards, this means that users only pay 70% of the base fee every time they transact. As a result, the mechanism no longer targets the desired 50% blockchain utilization but will probably equilibrate at a much higher gas utilization.

Correction: Thanks to Nick Johnson (link) and Vitalik Buterin (link) for pointing out to me that even if all rewards were paid back, EIP-1559 still targets 50% gas utilization, only with a higher “formal” basefee. So the above paragraph is incorrect.

Conclusion

When designing mechanisms, we have to be mindful that well-intended solutions can have unexpected second-order effects. Yes, EIP-1559’s dual-fee model might seem complicated for users. And yes, the sustainability of OSS development is a big challenge. But in both cases we discussed today, NEAR’s solutions not only don’t improve the outcome but actively make it worse.

By banning fees paid to block producers, they encourage forming a “black market” for transaction priority. By adding a forced rent to app developers, they can’t change the true market price for transactions but merely force apps to refund their users.

The market has strong incentives to circumvent NEAR’s current mechanisms, making the “cure” worse than the disease itself.