A#3 IC Tokenomics Flow

Tokenomics
1

Greetings, all! We’ve discussed tokenomics from many different angles, and this particular one led me to brand-new insights that may help settle a lot of debates. I hope you find them useful for NNS governance! Personally, this perspective makes me even more bullish on the IC, because the problem with its tokenomics so far is that even when business is booming, the charts don’t reflect it.

Draft for community discussion — please poke holes, correct assumptions, and improve the math.

TL;DR

  • Today’s net flow is inflationary for holders. Under reasonable assumptions (listed below), the network mints ~1.09M XDR/month to pay node providers (NPs), while burning ~0.205M XDR/month in cycles — a net −0.886M XDR/month for ICP holders.

  • Even at max load on existing “burning” subnets, net still < 0 because non‑burning/system/idle subnets continue to mint rewards. On the same assumptions, max usage improves things but still leaves ~−0.328M XDR/month.

  • One fully utilized “rented”/application subnet contributes only ~+1,400 XDR/month net (burn minus NP payouts), so you’d need on the order of ~630+ such subnets (at today’s usage) just to break even.

  • The core issue: NP payouts are largely load‑insensitive and paid in newly minted ICP (XDR‑pegged), while burn depends on actual usage. When usage is below a high bar, mint > burn and holders subsidize the network.

  • There are options. Ranging from light‑touch transparency fixes, to tuning NP payouts, to introducing DPoS‑style NP selection/revenue sharing, to permissionless/third‑party subnets that pay a protocol commission. Each has trade‑offs — let’s discuss.

This is not investment advice. It’s a community attempt to reason about incentives with back‑of‑envelope math. If any parameter below is wrong, please correct it — the conclusions are only as good as the inputs.

Assumptions & inputs (from our chat + public parameters we’ve seen before)

Please challenge these — they drive everything:

  1. Subnets & roles for this snapshot:

    • 30 “cycle‑burning” application subnets (host most user canisters).

    • 16 non‑burning/system/idle subnets (governance, routing, special‑purpose, or under‑utilized).

    • 1 “rented”/heavy‑use application subnet we have a proposal for (used here as a concrete max‑load example).

    • Unassigned nodes not part of the needed reserve aren’t involved in the calculations. The goal is to see how tokenomics will work with the current load and with the max load.

    • Think of neurons and ICP holders as one. How the value moves between them isn’t relevant.

  2. Costs & burn, in XDR (Special Drawing Rights):

    • NP payout per subnet per month: 23,200 XDR
      (=> 16 nodes per subnet, including 3 in reserve × 1,450 XDR per node per month).

    • Observed current network burn: 6,000 XDR/day across the 30 cycle‑burning subnets.
      ⇒ ~180,000 XDR/month for those 30.

    • Max practical burn per app subnet at full load: ~820 XDR/day ← :alien_monster: Critical assumption
      ⇒ ~24,600 XDR/month per fully loaded subnet (taken from a rented‑subnet proposal).

  3. Unit conventions: Everything below is per month in XDR (we convert any daily figures ×30).

If you have better current counts for subnets, per‑node XDR, reserve ratios, or a fresher burn line, please swap them into the sheet — the method stays the same.

The numbers (made consistent to monthly XDR)

Subnet type Count Burn @ current per month Burn @ max per month NP payouts per month Net to holders (burn − mint) @ current Net @ max
Cycle‑burning subnets (aggregate) 30 180,000 738,000 696,000 −516,000 +42,000
Non‑burning / system / idle 16 0 0 371,200 −371,200 −371,200
Example fully‑loaded “rented” subnet 1 24,600 24,600 23,200 +1,400 +1,400
Totals 47 204,600 762,600 1,090,400 −885,800 −327,800

  • Today (current burn): −885,800 XDR/month net (mint > burn).

  • Cycle burning subnets only flip to positive above 95% load, which isn’t realistic.

  • If all 30 burning subnets reach “max”: −327,800 XDR/month net (still negative because of fixed payouts on non‑burning/system subnets ).

  • Per fully utilized new app subnet: +1,400 XDR/month.

Break‑even intuition:
At today’s utilization, to offset −885,800 XDR/month, each maxed‑out app subnet contributes +1,400, so we’d need ~885,800 / 1,400 ≈ 633 additional fully loaded subnets to get to zero. (If the current burn increases meaningfully, that number falls; if NP payouts rise or non‑burning subnets grow, it rises.)

What this means for each stakeholder

  • ICP holders: Under these parameters, utility burn doesn’t reach you unless usage scales far beyond today’s footprint and/or NP payouts become usage‑sensitive or shared. The token’s value to a “casual holder” is mostly governance + speculation, not a claim on network cash flows.

  • App builders: Your costs are USD/XDR‑pegged via cycles. You don’t need to hold ICP (beyond ops cash‑management) unless you’re speculating. That’s great for predictability — but it decouples app success from ICP holder upside.

  • Node providers: You bear infra capex/opex and receive XDR‑targeted rewards regardless of load. That stabilizes supply of compute but socializes under‑utilization onto holders during slow demand.

  • Governance (NNS majority): In practice, whoever controls NP onboarding and reward policy decides who captures utility economics. Today, that’s mostly the NPs;

FAQ (pre‑empting questions from the chat)

Q1) “Does maxing out existing subnets fix it?”
Partly, not fully. Max load on current burning subnets flips their slice slightly positive (+42k XDR/mo) but non‑burning/system subnets still mint rewards (−371k), leaving the net ~−328k XDR/mo.

Q2) “Why do we count ‘non‑burning’ subnets — aren’t they necessary?”
Yes — routing, governance, system duties exist. The point isn’t “don’t have them,” it’s that their rewards are load‑insensitive. Unless balanced by high burn elsewhere or made elastic/shareable, they drag net negative.

Q4) “What about SNS tokens / app‑level value accrual (e.g., Odin)?”
Those can accrue value locally even if ICP doesn’t. That’s good for builders and speculators in app tokens. But ICP holders still experience the mint − burn gap unless tokenomics change or usage dwarfs fixed mint.

Q5) “Is ICP therefore a ‘ponzi’?”
No — there’s real compute and real costs being paid. The critique is about who captures value from utility under the current reward/burn plumbing. We’re arguing the incentive split can be improved.

Q6) “Won’t slashing NP rewards ‘hurt the network’s reputation’?”
Blunt cuts can. But there are middle grounds: make a portion of NP rewards usage‑sensitive, introduce performance tiers, or share a slice with stakers/delegators. Predictable rules > arbitrary cuts.

Q8) “Isn’t governance the value for holders?”
Potentially. But if simple majority can capture cash flows by controlling NP onboarding/rewards, while “casual holders” can’t influence those flows, the governance value is unevenly distributed.

Q9) “What if price falls — do NPs ‘hodl’ instead of selling?”
That’s a behavioral backstop, not a protocol guarantee. Some NPs may hold; others must sell to cover fiat costs. Protocol‑level alignment beats relying on market psychology.

Q10) “Do devs need to hold ICP?”
No. That’s by design (cost predictability). But it also means dev adoption doesn’t automatically produce holder accrual unless burn outruns mint or the protocol routes some value to holders.

Q11) “Is DPoS the fix?”
It’s one option. Let stakers/delegators help select NPs and share a slice of NP rewards (like indexer delegation in other networks). Trade‑offs: added complexity and different attack surfaces.

Q12) “What about ‘permissionless’ third‑party subnets?”
One idea is to let others run subnets with their own tokens, but require a protocol commission (e.g., 5–10% of burn) payable in ICP (and burned). That could grow capacity without minting NP rewards on ICP, while still accruing some value to ICP.

A menu of concrete options (non‑exclusive)

Think of these as levers we can mix and match. None is free of trade‑offs.

  1. Make a portion of NP rewards usage‑sensitive.

    • Shape: Split NP payouts into base (keeps lights on) + variable (scales with burn or utilization).

    • Pro: Aligns incentives; reduces idle‑capacity drag.

    • Con: Needs robust metrics; risk of gaming; careful rollout needed.

  2. Introduce a holder accrual stream (burn‑share or buyback) tied to utility.

    • Shape: Route X% of monthly burn to additional base‑layer burn or buybacks, or share X% of NP rewards with stakers.

    • Pro: Direct utility → holder link.

    • Con: Reduces NP take;

  3. DPoS‑style NP selection & delegation.

    • Shape: Stakers delegate to candidate NPs; emissions or fees are shared with delegators; performance‑based rewards.

    • Pro: Decentralizes selection; aligns holder–NP incentives.

  4. Permissionless/affiliate subnets with protocol commission.

    • Shape: Third parties run subnets with their own economics; interop requires paying an ICP commission (burned).

    • Pro: Scales ecosystem without bloating ICP’s NP mint; still accrues to ICP.

  5. Idle/low‑utilization safeguards.

    • Shape: KPIs for decommissioning, pausing rewards, or consolidating under‑used subnets; seasonal scaling policies.

    • Pro: Reduces “empty mall” drag; improves capital efficiency.

    • Con: Operational complexity; migration tooling needed.

  6. Transparency & dashboards first. (Low‑risk wins.)

    • Publish per‑subnet: utilization, burn, NP payouts, and net mint/burn.

    • Add a network “break‑even” dial that shows how many fully loaded app subnets would bring net to zero under current parameters.

    • Pro: Shared reality → better decisions; surfaces where to optimize.

Reframing success criteria

  • “Killer apps will save us” — we all want them. But without plumbing that routes utility → holders, app success accrues mainly to app tokens and NPs, not ICP holders.

Appendix: walk‑through math (so anyone can replicate)

  • Per‑subnet NP payout (monthly): NP_monthly = nodes_per_subnet * XDR_per_node_per_month.
    Using 16 * 1,450 = 23,200 XDR.

  • Current burn across app subnets (monthly): Burn_current_month = 6,000 XDR/day * 30 ≈ 180,000 XDR.

  • Max burn across 30 app subnets (monthly): 30 * 24,600 = 738,000 XDR.

  • Net to holders (monthly): Net = Burn_month − Σ NP_monthly.
    With today’s mix (30 burning, 16 non‑burning, 1 rented):
    Net_current = (180,000 + 24,600) − (30+16+1)*23,200 = −885,800 XDR/month.
    Net_max = (738,000 + 24,600) − (30+16+1)*23,200 = −327,800 XDR/month.

  • Per fully loaded app subnet: 24,600 − 23,200 = +1,400 XDR/month.

  • Break‑even subnets at today’s burn: 885,800 / 1,400 ≈ 633 (round up for safety).

Endnotes:

Unless critical assumptions are incorrect, no matter how much the IC network services are used, without changing NP tokenomics, casual ICP holders will never experience any of the upside (burn exceeding NP minting). The ICP token only has speculative value — that if both everything works out well and tokenomics change in the future, holders may experience utility-driven deflation, or someone may want to take it over fully by buying from the market. Currently, the governance value of the token appears to exist only for whales who manage to select nodes.

The IC fundamentals are sound: the technology works well and is improving consistently. Its services are being used more and more for real-world use cases, and apps are becoming increasingly advanced. It still has unexplored, unique use cases yet to be seen. Some of the bottlenecks so far have been due to an insufficient number of developers to bring these use cases to light. With the advancement of AI, each developer now has the performance of a whole team. Porting libraries and tools, and connecting to other chains and APIs, is much faster. Ideas materialize in weeks, and unlike Web2, they can result in trustless non-custodial crypto protocols. With Caffeine, even non-developers can create dapps.

IC tokenomics are a rare species, and almost nobody fully understands what the upside is. The problem is that crypto users are used to BTC and ETH, where tokenomics were designed well from day one and are relatively simple. They come to ICP expecting a deflationary mechanism, but don’t see one — even while the network is thriving — because ICP holders are still subsidizing node providers, who keep 100% of what the IC earns from decloud services. The NNS decides when to stop the subsidization, who runs nodes, and when to forward some of the upside to the token. Currently, it’s set to “never.” But really, it’s just a matter of changing things with a few proposals once a solution is found that works for all parties — assuming those in power want to cooperate with all ICP holders and align incentives across all roles.

1 Like