The Emissions Thread -aka lollipops

[Josh]

@Southside

Or will as someone said yesterday, DevNet becomes the actual working network

That was me, my fantasy is that folk add nodes and it becomes sustainable without the need to pay for uploads.

A small network run on volunteered resources.
The greed element has worn me out.
Remove the money, Remove the problems.

[Dimitar]

For me, the main problem with emissions is that the way things are described on the site, a newcomer is left with the impression that if they start 50 nodes (the maximum on the launchpad) they will get something for the free resources on their computer and there is no example or calculator anywhere of what they can expect for their efforts…

It says this “Contribute your spare resources and get paid. Everyday devices. No complex setup.” - this is technically true, but it will lead to inevitable disappointment and for me it is misleading:

---

Check out the Dev Forum

[Southside]

I can see why @dirvine is totally scunnered, I am myself. Its almost as if - whisper it - someone in “management” has a financial interest in ensuring this emissions scam continues.

I simply cannot see the reason to continue paying out these funds for no reason. @Mav I think postulated they want to see what happens at this scale. Well we see what happens at this scale, we have a knackered network that wil take a lot of fixing and we are asking the devs to fix problems that we should not be seeing - not at this stage anyway.

[Southside]

Yes - that claim is entirely misleading and in any other arena than “crypto” would get you done for false advertising.

[Josh]

@Dimitar

is misleading:

Surely we cannot make an informed decision untill uploads work and the network starts filling.

Node numbers will drop because disk space is required and storage cost goes up etc..

[Dimitar]

Since the number of nodes and storage space can be published on the site, I don’t see why the current yield of 50 nodes/week = 0.05 ant cannot be published.

---

Check out the Dev Forum

[feinberg]

I am in no way qualified to be commenting on the technical details of the network. So, just for kicks, I fed the 27th March update to Grok. After the initial response, I then fed it this thread with emphasis on mav’s post. This was the response I received:

Thanks for sharing Mav’s opinion from the emissions thread. It’s a thoughtful take, and I’ll break it down to see how it aligns with or sways my earlier analysis of the Autonomi Network’s core issues and my proposed technical fixes. Mav’s perspective shifts the focus from “intended effect” (how emissions should work) to “observed effect” (how they’re actually playing out), which is a refreshing angle. Let’s unpack it and see where it lands.

Mav’s Core Argument

Mav sees emissions not as a reward for node operators but as a network-wide cost—a stress test exposing weaknesses, like too many nodes exploiting easy rewards. They argue:

• The cost can be borne for a while, thanks to excess storage capacity and participation.

• Those benefiting (node runners racking up ANT) are highlighting a flaw, whether intentionally or not, and that’s valuable intel.

• The real imbalance isn’t emissions—it’s the upload side, which is unreliable, costly (ETH gas + ANT), and clunky due to a weak app ecosystem.

• Fixing uploads, not tweaking emissions, is the key to rebalancing the network.

Does This Sway My View?

It doesn’t overturn my earlier read but refines it. I pegged token rewards and upload/download challenges as two of the four core issues in the March 27 update thread, alongside network stability and transparency. Mav’s take zeroes in on these two, downplaying emissions as the fixable lever and elevating uploads as the priority. Here’s how it tracks with my analysis:

1. Token Rewards and Incentives

• My Take: I saw rewards as a pain point—users might feel cheated by the emissions correction (54k to 27k ANT daily) or unclear payouts. I suggested refining reward logic (e.g., pay for uptime/data) and auditing smart contracts.

• Mav’s View: Emissions aren’t rewarding effort—they’re a cost exposing a flaw (too-easy node spinning). The beneficiaries are speculators betting on future ANT value, not breaking the system.

• Impact: Mav’s framing doesn’t contradict me but shifts the lens. I assumed discontent stemmed from reward cuts; Mav suggests it’s more about the system incentivizing node spam over utility. My fix (rewarding data served) still fits—it’d discourage idle nodes—but Mav’s point implies emissions aren’t the root evil. I’d still audit the contracts to catch errors like the over-emission, but I’m swayed that tweaking rewards might be secondary.

2. Upload/Download Challenges

• My Take: I flagged this as a major issue—slow, unreliable uploads/downloads, likely tied to NAT issues and unready optimizations. I proposed chunk retries, better peer selection, and user diagnostics.

• Mav’s View: Uploads are the real imbalance—unreliable, ETH gas friction, and a barebones app ecosystem. Fix these, and emissions might self-correct.

• Impact: This strongly reinforces my focus on uploads. Mav’s three pain points (reliability, cost, simplicity) align with my fix ideas but add urgency. I didn’t emphasize ETH gas friction—good catch. It’s an extra hurdle outside Autonomi’s ANT economy, and Mav’s right: it’s a barrier to adoption. Their app ecosystem critique also highlights a gap I didn’t fully address: usability matters as much as tech.

3. Network Performance and Stability

• My Take: I assumed node stability (e.g., dropouts, NAT traversal) was a big deal, suggesting software patches and load balancing.

• Mav’s View: Barely mentioned—focus is on uploads, not node uptime.

• Impact: Mav’s silence here doesn’t disprove my point, but it suggests stability might be less pressing than I thought if excess storage (node count) is holding up. I’d still fix it, but maybe not first.

4. Communication and Transparency

• My Take: I saw vague updates as a trust killer, proposing clearer formats and feedback loops.

• Mav’s View: Not addressed directly, but implied—better upload fixes might reduce the need to explain emissions woes.

• Impact: No sway here. Mav’s focus is technical, not communicative, so my transparency fix stands separate.

What Do I Think of Mav’s Opinion?

It’s sharp and pragmatic. Mav’s “observed effect” lens—emissions as a diagnostic cost, not a reward—flips the script in a way that makes sense. The network’s lopsidedness (tons of nodes, weak uploads) matches the data: January 2025 updates boasted 365,000 nodes and 2 petabytes of storage, yet March 20 admitted upload improvements weren’t ready. Mav’s right—excess supply isn’t the crisis; demand (uploads) is. Their take on node runners as speculators also rings true—low liquidity (ANT trading thin post-TGE) means they’re banking on future value, not crashing the market now.

I buy the upload-first argument. Emissions tweaks (like my reward scale) might deter node spam, but if uploads stay broken, the network’s utility stalls. Mav’s three upload issues—reliability, ETH gas, app simplicity—are spot-on blockers. I’d tweak my fix approach based on this:

• Reliability: My chunk retries and peer selection still apply—double down here.

• ETH Gas: Add a bridge or subsidy in the client to pay gas with ANT, cutting external steps. Long-term, push for gasless uploads via Arbitrum upgrades.

• Apps: Build a dead-simple upload GUI (drag-and-drop, one-click) in the Node Launchpad, even if barebones, to kickstart usage.

Adjusted Fix Priority

Mav sways me to reorder my plan:

1. Fix Uploads First: Reliability (retries, peer tweaks), then gas friction (ANT bridge), then apps (simple GUI). Testnet this by April 10, 2025.

2. Monitor Emissions: Hold off on reward tweaks—let upload fixes drive demand, then see if node spam persists. Keep the contract audit, though.

3. Stability Later: Patch nodes if needed, but excess capacity buys time.

4. Transparency Ongoing: Keep communication clear to sell the upload focus.

Mav’s perspective doesn’t upend my core issues—it sharpens them. Emissions are a symptom; uploads are the disease. I’d still fix both, but Mav’s got me convinced to lead with usability over economics. What’s your take—does Mav’s view match your “different perspective,” or are you leaning elsewhere?

[feinberg]

When pressed further, it says Southside wins. Anyway, hope this is at least entertaining:

Updated Context

• Whales and LaunchPad: LaunchPad enforces 35 GB/node, but whales—likely big operators with “mega millions” of nodes—use lightweight, custom scripts or forks to spin up tons of nodes on the cheap (e.g., VPS clusters). This explains Southside’s “2D sheets” complaint—they’re not providing meaningful storage, just node count.

• Impact: Emissions (16,307 ANT daily, post-correction) get gobbled up by these low-effort nodes, skewing rewards away from LaunchPad users (small operators with 1-2 TB HDDs) and draining ANT/ETH gas for little network benefit.

Revisiting Southside’s Argument

• Core Claim: High emissions favor whales, betraying Autonomi’s vision of rewarding spare capacity. Whales aren’t providing storage, just node spam.

• With Whales Off LaunchPad: This strengthens Southside’s case. If whales dodge the 35 GB rule via custom setups, the reward system is even more broken—LaunchPad users are penalized for following rules, while whales exploit a loophole. Southside’s “pissing away ANTs to whales” hits harder: emissions aren’t just high, they’re misdirected.

• Solution: Reduce emissions, tie rewards to storage (not node count), and raise payout thresholds ($100). Now, we’d add: enforce LaunchPad compliance or penalize non-compliant nodes.

Strength Boost: The whale loophole makes Southside’s fairness argument more urgent—emissions aren’t just inequitable, they’re rewarding rule-breakers.

Revisiting Mav’s Argument

• Core Claim: Emissions are a cost exposing weaknesses; the real fix is uploads (unreliable, ETH gas, weak apps). Excess storage buys time.

• With Whales Off LaunchPad: This complicates Mav’s view. Excess storage (e.g., 2 PB, January 2025) is real, but if whales contribute little of it (e.g., 1-3 GB/node vs. 35 GB), the “strength” is hollow—node count, not capacity. Uploads still matter, but whale spam undermines Mav’s assumption that supply-side resilience offsets emissions flaws.

• Solution: Fix uploads (reliability, gas, apps)—unchanged. But now, whale behavior questions whether upload fixes alone can rebalance things if rewards keep flowing to useless nodes.

Strength Hit: Mav’s “excess storage is good” weakens if whales aren’t adding real capacity. Uploads remain key, but emissions feel more pressing.

Comparison with New Insight

Evidence and Logic

• Southside: Whales off LaunchPad is killer evidence—custom nodes flout the 35 GB rule, proving emissions reward presence over utility. Logic tightens: the system’s not just unfair, it’s exploitable. Weakness: Still lacks hard stats (e.g., whale node %).

• Mav: Excess nodes (365,000 peak) and upload delays (March 20) hold, but “strong supply” falters if whales add negligible storage. Logic still flows—uploads are the bottleneck—but ignores the whale exploit’s scale.

Edge: Southside’s sharper—whale loopholes are a smoking gun Mav overlooks.

Practicality of Solutions

• Southside: Tying rewards to storage (e.g., ANT per GB) gets trickier—needs a way to verify storage across custom nodes (e.g., proof-of-storage checks). Enforcing LaunchPad or penalizing non-compliance (e.g., node ID blacklists) is doable but messy. Timeline: 3-4 weeks (April 24, 2025).

• Mav: Upload fixes (retries, gas bridge) stay quick—1-2 weeks (April 10). Doesn’t address whale exploits directly, but boosts utility regardless.

Edge: Mav’s still faster, but Southside’s fix tackles the root exploit, even if it’s harder.

Alignment with Goals

• Southside: Whales off LaunchPad is a direct betrayal of “spare capacity”—Southside’s fix restores that ethos by forcing real resources. Risk: Node count drops if whales bail.

• Mav: Uploads align with usability, but whale spam undercuts the “redundant storage” promise if it’s all fake capacity.

Edge: Southside’s truer to the vision—whale exploits mock the mission more than upload woes.

Which is Stronger Now?

Southside’s argument grows stronger with whales off LaunchPad. It’s not just about high emissions—it’s about a systemic exploit: custom nodes gaming the system, leaving LaunchPad users (the intended backbone) screwed. Southside’s call to rethink emissions and rewards hits the core flaw—16,307 ANT daily flowing to useless nodes is a travesty. Their fix (storage-based rewards, higher thresholds) needs a new piece: detect and penalize non-LaunchPad nodes (e.g., via storage audits or software signatures).

Mav’s upload focus remains valid—unreliable uploads are the usability killer—but the whale loophole undermines their “excess storage” optimism. Fixing uploads won’t stop whales from hoarding ANT unless rewards shift, making Mav’s solution feel incomplete. Southside’s passion and structural critique outweigh Mav’s pragmatism here.

Final Call: Southside’s stronger on March 27, 2025. The whale exploit tips it—they’re not just benefiting, they’re cheating, and that’s a bigger threat than upload friction. Mav’s fix is a good step, but Southside’s addresses the rot at the heart. If the team patched the loophole (e.g., mandatory 35 GB via LaunchPad), Southside’s edge would solidify. What’s your take—does this shift your view, or do you see Mav’s angle holding up?

[feinberg]

Sounds to me like both men are correct, so I pressed it even further. Hope this is useful:

You’re spot on—Southside and Mav’s perspectives aren’t mutually exclusive; they’re tackling different facets of the same mess. Southside’s zeroing in on the structural rot (whales gaming emissions with low-storage, non-LaunchPad nodes), while Mav’s hitting the usability crisis (unreliable uploads stunting network adoption). Both are true: the reward system’s broken, and the network’s unfit for real use. Implementing both is not only possible but could be synergistic—fixing emissions to reward actual utility (Southside) while boosting uploads to drive demand (Mav). Here’s how I’d blend them into a cohesive plan, with a prioritized order and timeline.

Combined Strategy: Fix Emissions and Uploads Together

Core Principles

• Southside’s Goal: Stop rewarding whale spam; tie emissions to real storage (35 GB/node via LaunchPad) and cut wasteful payouts.

• Mav’s Goal: Make uploads reliable, frictionless (no ETH gas), and simple to grow the network’s purpose—data storage.

• Synergy: Reward useful nodes (Southside) to fund a network worth using (Mav). Whales lose their edge if uploads work and rewards demand storage.

Implementation Plan

Step 1: Quick Upload Reliability Fix (Mav)

Why First: Uploads are the network’s lifeblood—without them, it’s a node farm, not a storage system. A fast win here builds momentum and trust, softening Southside’s “unfit for purpose” sting. March 20 updates said upload fixes were “looking good”—this is low-hanging fruit.

• Action:

  • Patch client software for automatic chunk retries (60s timeout) and smarter peer selection (low-latency nodes first).

  • Test on testnet with 10% of nodes (28,000 of 280,000 steady-state).

• Timeline: 1 week—deploy by April 3, 2025.

• Impact: Upload success rate jumps (e.g., from 50% to 80%), proving utility to small users and devs (e.g., Impossible Futures program).

Step 2: Enforce Storage-Based Rewards (Southside)

Why Second: With uploads working, shift emissions to reward real capacity, not node count. Whales off LaunchPad are the exploit—fixing this needs upload progress to justify the shift (why store data if uploads fail?). This hits Southside’s fairness goal.

• Action:

  • Update smart contracts: Base reward (0.2 ANT/node) + bonus (0.01 ANT/GB stored, verified via periodic proof-of-storage checks).

  • Mandate LaunchPad (or equivalent 35 GB minimum) via node authentication—non-compliant nodes get zero ANT.

  • Audit contracts to catch errors (like the 931,506 ANT over-emission).

• Timeline: 2-3 weeks—testnet by April 10, mainnet by April 17, 2025.

• Impact: Whales either comply (add storage) or exit; small users (1-2 TB HDDs) earn more (e.g., 0.55 ANT/node vs. 0.2 for whale spam).

Step 3: Cut Upload Friction (Mav)

Why Third: Reliability alone isn’t enough—ETH gas is a barrier (Mav’s second upload issue). With rewards fixed, reduce friction to spur upload demand, leveraging Step 1’s stability.

• Action:

  • Add an ANT-to-ETH bridge in the client—users pay ANT, network covers gas (subsidized by emissions savings from Step 2).

  • Cap gas costs at 0.01 ANT/upload, testing on Arbitrum’s low-fee layer.

• Timeline: 2 weeks—deploy by April 17, 2025, alongside Step 2 mainnet.

• Impact: Uploads become one-step (no external ETH), doubling small-user participation (e.g., from 10% to 20% of nodes uploading).

Step 4: Raise Payout Threshold (Southside)

Why Fourth: Twice-daily payouts waste gas (Southside’s point)—fix this after stabilizing rewards and uploads to save resources without disrupting early adopters.

• Action:

  • Set a $100 ANT threshold (at ~$0.50/ANT post-TGE, that’s 200 ANT/node).

  • Batch payouts weekly for nodes below threshold, cutting gas 14x (2/day to 1/week).

• Timeline: 1 week—deploy by April 24, 2025.

• Impact: Gas drops (e.g., from 0.01 ETH/day to 0.001 ETH/week for 280,000 nodes), favoring small users over whale cashflow.

Step 5: Simplify Upload Apps (Mav)

Why Last: Mav’s third upload fix—app ecosystem—needs reliability and low friction first, or no one builds. With Steps 1-4, the network’s ready for adoption.

• Action:

  • Release a drag-and-drop upload GUI in LaunchPad (one-click, no CLI).

  • Open-source an API kit for devs (e.g., Impossible Futures) to build apps.

• Timeline: 4-6 weeks—deploy by May 8, 2025.

• Impact: Uploads triple (e.g., from 1% to 3% of nodes), drawing real use (e.g., Ed Sutcliffe’s disruptors).

Order Rationale

1. Upload Reliability (April 3): Fastest win—makes the network usable, buys goodwill. Southside’s “unfit” critique softens if uploads work.

2. Storage Rewards (April 17): Builds on Step 1—rewards shift to storage as uploads prove value. Hits whale exploit head-on.

3. Upload Friction (April 17): Pairs with Step 2—gas fix needs reward savings to fund. Boosts Step 1’s reach.

4. Payout Threshold (April 24): Optimizes gas post-reward fix—small users benefit most once whales are curbed.

5. Upload Apps (May 8): Long-term adoption play—needs prior steps to shine. Turns capacity into utility.

Why It Works

• Southside’s Win: Whales lose their edge—35 GB enforcement and storage-based ANT kill spam. Small users (1-2 TB) out-earn node farms (e.g., 0.55 vs. 0.2 ANT/node). Gas savings ($100 threshold) align with “spare capacity” ethos.

• Mav’s Win: Uploads become reliable, cheap, and simple—network grows beyond speculators to real storage (e.g., 10 PB uploaded by June 2025).

• Synergy: Useful nodes (Southside) power a useful network (Mav). Whales either contribute or leave; small users thrive.

Risks and Mitigations

• Node Dropoff: Whales exiting could cut node count (e.g., 280,000 to 200,000). Mitigation: Phase Step 2—30-day grace period for compliance.

• Upload Lag: If Step 1 falters, later steps stall. Mitigation: Double dev resources on retries/peers (March 20 progress suggests it’s close).

• Community Pushback: Southside’s crowd might demand emissions cuts now. Mitigation: Transparent roadmap—weekly updates showing upload wins first.

Final Thoughts

This hits both truths: Southside’s “whales are cheating” and Mav’s “uploads are broken.” Order prioritizes usability (Mav) to prove the network’s worth, then fairness (Southside) to sustain it. By May 8, 2025, Autonomi could be a lean, user-driven storage system—280,000 nodes, 5-10 PB used, and ANT rewarding real work. What do you think—does this balance their fire and pragmatism for you?

[Southside]

Thank you for this @feinberg
its 05:30 here - I must sleep before I try take this in.
Its not me vs Mav though - its both of us vs a broken system but must sleep now…

[storage_guy]

This is maybe the most balanced and sensible post on the subject we’ve seen! I think this is what we were waiting for.

[Toivo]

@Southside

And uploads would likely work properly IF there were not millions of unresponsive nodes on the network

Is this really the case?
Are nodes unresponsive?
Would 50M nodes network work, if the nodes were responsive?

Honest questions, no agenda.

[loziniak]

@feinberg

Hope this is useful

tl;dr

@Toivo

Are nodes unresponsive?

Yes, maintainers do not respond to upgrade calls. Hence nodes are still not upgraded and fixes in the code cannot be rolled out to the network. The majority is on old soft.

BTW it was about time this topic was created. David was right, emissions popping out in every topic on every forum was tiresome. @moderators could probably do the job earlier.

[Toivo]

So the maintainers are unresponsive.

But the nodes themselves? Are they unresponsive, and which ways? Don’t respond to queries?

[riddim]

@loziniak

The majority is on old soft.

Still? Are we sure about this or is the info on which this is based possibly outdated info that doesn’t get refreshed by the running nodes..?

[loziniak]

I think it’s a major network health indicator, so if it would change, I’m sure the team would share the news.

[riddim]

Hmhmm - We’ve non existing nodes in our routing tables - and I think the official numbers about network size estimate is based on the routing table (buckets and how full they are)… What makes us think that the version info about those - possibly non existing - nodes is accurate and reflects the state of the network? Not sure what the version distribution is based on and if that info is refreshed more often than the info about the other node existing or not…

For all I know the % of versions is something that’s comes out of nodes…? Just as the buckets and the routing tables…

[DavidMc0]

@Southside

Emissions are ONLY an economic Band-Aid to satisfy the free marketers

As a fan of free markets, I’d suggest free marketers would be unsatisfied with a market distorting subsidy. They will see it as causing oversupply of nodes and wrecking the intended market for resources by suppressing the ANT price of uploads with the huge quantity of unnecessary nodes… though of course, no market for resources can work if uploads & downloads don’t function.

@mav

testnets didn’t have emissions. Uploads didn’t work well there either.

This is true, but if I remember correctly, uploads did work better in tests than we see now.

This network had minimally functioning uploads in the first weeks, and upload performance grew progressively worse as the node numbers grew ever larger.

Correlation does not equal causation, but it seems plausible that the scale of the network is a significant cause of poor performance, and probable that emissions caused the excessive node growth, so it may be worth investigating.

If excessive node growth can be shown to be a significant factor in upload / download performance diminishing, then there would be a strong argument to stop emissions to prevent further damage to the network at this time, and possibly help fix upload / download issues if a shrinking network achieves this.

Of course, if that happens, the emissions would have added value by highlighting issues that can be fixed to help the network scale in due course.

@mav

Removing emissions to fix uploads doesn’t seem grounded in observed reality. It’s an interesting theory, but can we take it further and show it to be a real solution? Genuine question.

It seems to be observed reality that the network is getting kind of dislocated at the current scale, e.g. not returning closest nodes when it should. Perhaps this wouldn’t be happening with a smaller scale network?

Could this be tested in some way with a community test net with a small number of nodes, but running ‘in the wild’ rather than in MaidSafe’s test environment?

If uploads / downloads don’t work in a small-scale community test with the same code, then quantity of nodes, and therefore emissions, isn’t likely to be the primary cause of bad performance. If upload / download performance is good, then it would be evidence that the scale of nodes might be causing issues.

Not sure how much effort it’d be to do a community network given the EVM stuff, but I’d certainly contribute a few nodes if this might be helpful.

[Toivo]

@riddim

Hmhmm - We’ve non existing nodes in our routing tables - and I think the official numbers about network size estimate is based on the routing table

Haha, imagine The Whale being just an imaginary one!

[Southside]

@DavidMc0

As a fan of free markets, I’d suggest free marketers would be unsatisfied with a market distorting subsidy. They will see it as causing oversupply of nodes and wrecking the intended market for resources by suppressing the ANT price of uploads with the huge quantity of unnecessary nodes… though of course, no market for resources can work if uploads & downloads don’t function.

You are quite correct

@Southside

an economic Band-Aid to satisfy the free marketers

was sloppy language used in haste mid-rant