Hello all,
This post is going to be long and contain quite a few points so it’s a heavy read. I will post this in discord as well broken down over a few messages.
Disclosure first, because it matters here. I run one of the many bots that claims storage rent. My bot was also one of the collectors that took the Flux bridge reserve on 21 September. We proactively reached out to Flux once we realized it was claimed, and yes, a bounty was offered, but we would have given it back anyway. It was the right thing to do.
Another disclosure: I used AI to help structure and word this post, which I have reviewed thoroughly with several manual edits. The opinions and ideas are my own.
I collect rent because it was there for the taking by anyone under the rules of the protocol. I agree that in the long term, rent should go to actual miners who participate actively in the ecosystem (with “participate” being key here, I’ll come to that later). I can see the reasoning, and it is in the best interest of Ergo, even though the current state is the one that pays some of that rent to me (and a few others).
So in principle I support ensuring miners claim the storage rent. But I would not rush PR 2577 (declining SR transactions in the mempool) in its current form. It is not the fix for the single-transaction blocks people keep pointing at. That has a separate cause, which I come to next, along with some additional thoughts the community should consider before rushing decisions that will have long-term impact.
The “filtering of mempool” argument for moving fast do not hold up - PR2577
Worth stating plainly, since it keeps coming up as a reason to move fast. The recent single-transaction blocks were not caused by storage-rent bots filling the mempool with competing claims. The cause lies deeper in the node code. SR bots surfaced it and made it happen more often.
PR #2577 - declining those txs in the mempool does not fix the underlying cause and it will happen again, even without SR bots.
There is a separate node-level issue which some SR bots happened to expose through their behaviour. I have submitted a vulnerability report. I am not going to detail it in public while it is unfixed. But once it is fixed, this kind of traffic that SR bots generate would no longer starve the node, so blocks would carry the transactions waiting in the mempool instead of coming up empty during these episodes.
On the churn argument, the case for the filter is that competing rent claims churn the mempool with double-spends and RBF. That churn is real, but handling contention and RBF is what a mempool is for, and this volume is tiny. If a chain our size cannot absorb a handful of rent bots, that is a mempool to harden, not a reason to rush a special-case content ban. It also sits oddly with the principle that miners should decide what goes in their own blocks: if a miner is free to take whatever the protocol allows, why make the node refuse them for everyone by default?
I still support rent going to miners in the longer term, I just do not think this is a strong enough reason to move fast and rush decisions without thorough analysis and review.
Now for PR2598 - Storage rent collection in the node.
This one I object to as being bad for our small community, at least until Lithos has been live for a few months and Ergo is more mature. It completely undermines Lithos, and the miners who engage with and support Ergo
Lithos is the project built to deliver what everyone here says they want, rent and fees reaching the people who mine, without having to trust a pool operator.
In Lithos miners build their own blocks and have “full block control”. Transaction selection, collecting storage rent etc.
With this, pool operator decides whether to share. Will 2miners even share the revenue from collecting storage rent if it is enabled by default in the config? They would need to develop custom code to enable sharing of rent.
EIP-0052 draft admits rent then “reaches pool members only if the pool shares it”. 2Miners has 50%+ of the hashrate and would get 50%+ of the rent from a config flag, before Lithos can mine a single block.
Shipping a storage-rent toggle in the reference node might not be the best idea in the current market. Putting it in the client every pool runs, right before Lithos can mine, is what hands the centralized pools like 2Miners the head start and could impact Lithos severely. 2Miners can flip a switch and collect the rent. They would then have to build a mechanism to share it with their miners. I’m not sure they are invested enough in Ergo to bother. Unlike Lithos (years in development), HeroMiners and a few smaller pools, who built their own SR collection method.
Ergo is a small ecosystem, where decentralization matters more, not less. Handing the largest pool an automatic share of rent pushes the wrong way, keeping smaller pools and independent miners viable is how a chain this size stays healthy. At least until ergo is more mainstream.
The drafts already bend around Lithos. EIP-0052 says two simpler rules were “considered and rejected because of Lithos”. That shows how easily a rule written today can break it.
*One week’s discussion is not long enough for significant changes, especially consensus ones.
The Flux incident was 21 September. Then:
• 25 Sep: EIP-0052, attestation
• 26 Sep: PR 2577 mempool filter, EIP-53 grace period + implementation, EIP-0051
• 27 Sep: PR 2598, collector in the node
Five proposals in three days, within a week of the incident. Three of them change consensus. Decisions the whole network has to live with for years should not be settled on a week of chat driven by one event. Consensus rules cannot be reversed, so they deserve months of discussions and review. Policy driven changes can be reversed or modified but still requires deep analysis and review and not in the heat of the moment decisions.
Closing thoughts
1.I support miners and people who engage and are invested in ergo getting the SR fees!
But please review the vulnerability I submitted, it may change the approach on how this is done and have a thorough discussion rather than a rushed decision and rollout based on one incident and a wrongly perceived impact (empty blocks)
2. Await lithos
Set a date to re-evaluate: a few months, or once Lithos has been live for some time.
3. Decide then, with data instead of a week of discussion
What pools are collecting, what do Lithos miners receive, how were tokens handled..
**Waiting costs little**.
Some miners already build their own claims, and any pool that wants the rent can do the same, but at least has to make a conscious effort to get involved.
Rent has been collectable since 2023. A few months to get the decentralized version right is a fair trade.