Neo Governance Logo
PROPOSAL #7
Competitive Fee and Blocktime Enhancements
Submitted by
lllwvlvwlll|68f5fda82dafd413c4109a64
Proposal type
Governance
Duration type
🗓️ Monthly
Deadline
7 MONTHS AGO
Fri Mar 27 2026 23:59:59 GMT+0000 (Coordinated Universal Time)
0
11 = MAJORITY
21
For:2
Neutral:0
Against:0
For 2
Neutral 0
Against 0
Total votes is 2, with 19 members not voted yet.

This proposal consolidates a number of ecosystem updates that have been enabled by recent enhancements that improve Neo's ability to:

  1. compete on price
  2. compete on performance (blocktime)
  3. enage in proactive governance

Overview:

Technicals:

  1. ExecutionFeeFactor: 0.01 (1% of current)
  2. GasPerBlock: 100000000 (5x reduction to align with blocktime change
  3. MillisecondsPerBlock: 3000 (ms)
  4. MaxTransactionsPerBlock: 200 (reduced to accommodate blocktime)
  5. MaxValidUntilBlock: 201600 (1 week @ 3s blocktime)

Results: a) Reduce the system fee by 100x the current value, making transactions effectively compute free b) Transition the ecosystem to 3s blocktime (this requires manual configuration change on consensus nodes) c) Update the governance workflow to allow a 1 week voting window to accomodate coordination

Considerations

There are additional features which can enable targeted fee reductions for specific contracts. This proposal is not intended to replace those discussions. It is designed to be complementary.

The execution fee factor is a significant consideration when evaluating whether an ecosystem is viable for a project. In many cases, the magin on individual transtions for projects is incredibly low. Reducing this value in a dramatic way allows us to compete for projects on fees and also stimulates use of the network.

alt

The resulting change will bring swaps for flamingo below $0.02 for all GAS prices over the past 12 months and allow it to directly compete on fees. It also signals the Neo is a compute blockchain, making other complex projects financially viable.

This proposal is insentive to congestion risk (it reduces fees and blocktime simultaneously). We believe that these changes are worth the risk and can be scaled back if there is an issue. Having transactions on the network is a good problem to have.

These configurations span multiple areas of the project and need to be adopted across multiple rolls in the ecosystem:

For Council Members: (1), (2), and (5) are policy changes and require a vote

For Consensus Nodes: (3) and (4) are configuration changes

Show Full Description
No comments yet. Be the first to comment!
The deadline for commenting on this proposal has passed.