On $JAMKB: should state footprint be a perpetual holding, or a metered flow?

Tech Talk
1

TL;DR. The proposal pins the quantity of state (~21M tokens for ~20GB) and lets the market find the price. I want to probe the inverse — pin the price (a small recurring rent) and let occupancy float. A flow self-heals lost and idle state, dissolves the article’s own “not generally practicable” tension, and ties DOT demand to the level of usage rather than its growth. Not a price post; a question about which variable we pin, and where value accrues.

I’ve read the article, and the case for a dedicated, DAO-owned, market-priced token is well made. I only want to probe one axis: should footprint be held in perpetuity or paid for over time? Each token is meant to “keep 1KB in Polkadot JAM’s state footprint for as long as it is held” — and making footprint a perpetual holding creates two failure modes a flow avoids.

1. Abandoned holdings have no reclamation trigger. Because capacity is metered by holding, a lost-key or dead-service token keeps its 1KB of footprint budget reserved forever, and no market corrects it — there is no seller. (A lost DOT, by contrast, removes no capacity.) It compounds: if the rising ratio (“the fixed rate would probably need to increase… and not require a hard-fork to alter”) applies to already-held tokens, each stranded token sterilises a growing amount of state.

2. Idle holding withdraws live capacity — and the article concedes it. You note that “every such token not used intentionally as a cost of holding state is preventing some other user from using the token for state,” with the ideal that “all such tokens would be held by services in accordance with their JAM state needs” — then grant that this “is not generally practicable since in order for tokens to change hands conveniently there must be some which are not in use.” A fixed-supply asset that can appreciate also gives holders a positive reason not to sell (the hoarding worry @Nukeme3 and @ultracoconut already raised in the distribution thread), and reallocation needs a standing float of idle tokens — capacity withheld by design.

Both come from pinning a stock. Pin the flow instead — occupy 1KB by paying a small recurring rate from a prepaid balance, reclaim when it empties — and the ideal of tokens “held… in accordance with… state needs” holds by construction, while the float problem dissolves, because capacity moves by payment, not by trading deeds.

Value capture. Worth surfacing from the spec: footprint already has a cost denominated in the service’s (DOT) balance — §9.3’s threshold balance is a standing DOT lock proportional to the state held. If JAMKB takes over footprint-rationing, that standing DOT lock becomes a standing JAMKB lock, and DOT features at most in the one-off purchase of the token — demand on the growth of usage, quiet in a mature network. A DOT-denominated flow points the other way: it keeps a standing DOT charge for state, tied to the level of usage and recurring for as long as the network runs (burned for direct accrual, or pooled as the DAP now does for coretime revenue — a separate governance call). So the value-capture contrast isn’t subtle: today state is a DOT sink; a dedicated token moves that sink off DOT; a flow keeps it on DOT and makes it recurring. For a community whose central worry is how $JAMKB reaches DOT, that seems worth weighing.

Consistency. Polkadot already meters its other scarce resource: you buy CoreTime as a flow, not a perpetual core. State is genuinely different — compute regenerates each block, state persists — and that disanalogy is a fair reason to reach for a different model. But persistence is exactly what rent handles: you don’t buy a perpetual deed to a square metre of warehouse, you pay for as long as your goods sit there, and the floor frees the moment you stop.

I don’t think the article’s two pricing objections settle it. First, “any preset price curve will inevitably be suboptimal” — agreed, but a rate that tracks utilisation toward a target band isn’t a preset curve, it’s demand-responsive; neither design is purely market-set (one pins quantity, the other a price target), so the real question is which variable you pin.

Second, “price-finding and rental arrangements ought not to be handled in the lowest-level of the protocol,” with only “the minimal resource access accounting” at the base. A meter doesn’t fully escape that — it asks the base layer to track a balance and reclaim on depletion, more than a static holding-check. But footprint accounting at the lowest level isn’t new: the §9.3 threshold balance is it (every service already carries one, scaling with its items and octets). So the live question is only whether that balance is held (today, and under JAMKB) or depleting (a flow) — and price-finding stays in a service above the base layer either way. The principle narrows the gap between a deed and a meter; I don’t think it decides it.

I’ll grant the proposal its strongest point: a fixed quantity is a hard ceiling — footprint can’t be over-allocated, since you can’t hold more tokens than exist — whereas a flow’s ceiling is soft, held by a controller that can lag a spike (recoverable via admission control, but that’s a moving part the cap gets for free).

The fair objection to metering is that JAM’s flagship services are long-lived and hate “forgot to top up → evicted.” Layer prepaid fixed-term leases (lock N KB for, say, 12 months) over the spot meter — the bulk-vs-instantaneous split CoreTime already uses. If a tradeable asset matters, a depleting lease — sellable, carrying demurrage, reverting when exhausted — keeps tradability without the stranding tail; this converges with @Abdulbee’s demurrage suggestion in that thread and the article’s own “grants or loans” gesture toward returnability.

The costs are real and worth stating: a meter loses the clean “own the machine forever” story and the moment of the DAO holding 100% of a capped asset, and trades a constant for a rate-controller plus admission control.

And on the protocol’s own terms this reads as settled rather than open. Beyond the §9.3 deposit above, the Gray Paper defines no state-rent and no eviction of stored state — freeing the resource is left to the holder (“moving the token out … would require the 1KB of state to first be cleared”). Keeping reclamation out of the base layer is a deliberate simplicity choice, not an oversight — but its cost is the stranding: an abandoned or key-lost service can never clear, so its footprint, and the token locked against it, persist with nothing to reclaim them. (Polkadot 1.0’s Existential Deposit already reaps under-funded accounts; the deed forgoes that precedent.) A flow reclaims on non-payment by construction — the one case a deed can’t reach. So the trade may be sharper than it first looks: a fixed-quantity deed buys base-layer simplicity and pays in permanent stranding; a flow buys automatic reclamation and pays in a little more of the footprint accounting JAM already does. If I’ve misread §9.3 or the clearing semantics, I’d welcome the correction.

2

In response to the JAMKB / footprint-vs-coretime discussion, I want to focus on the specific concept of validator memory capacity in Polkadot JAM.

That capacity—let’s call it FOOTPRINT—is estimated today at around ~20 GB, and it may change over time. Ideally it can grow as more validators join and as the minimum node requirements evolve, but in theory it could also decrease depending on the number of validators and the hardware needed to run them.

If JAM is successful, then FOOTPRINT should be well allocated, and—assuming the resulting demand for CORETIME and JAM usage is real—more validators should be incentivized to enter Polkadot JAM. That would increase the overall available/allocatable footprint and thus the total coretime capacity in the network.

However, this only works if the value of $DOT grows with JAM adoption. Remember: validators must have a self-stake of at least 10,000 $DOT, and validators are remunerated in $DOT. That means $DOT is the foundation of the validator investment and their returns. For that reason, treating any token representing FOOTPRINT as if it could have a value completely detached from $DOT is not just unlikely—it is fundamentally contradictory and would likely cause severe ecosystem damage.

Think of it like this: cloud companies (Amazon, Microsoft, Google, Oracle, etc.) effectively “own” their servers and the underlying RAM/compute capacity they sell. Even though they don’t literally hand out physical property rights over distributed servers, their economic control over that capacity is central. Similarly, DOTDAO should be considered the economic owner of the RAM/compute capacity it makes available to users, even if it doesn’t directly hold legal ownership of every physical machine in the decentralized system. This “ownership/control” must be preserved over time and cannot be ceded in a way that allows third parties—however aligned at first—to develop conflicting incentives later and potentially divert the core operational asset away from DOTDAO’s mission.

Given that, I don’t see a sustainable alternative other than treating FOOTPRINT as something that is leased (i.e., rented) over time—just like CORETIME.

For CORETIME, the model is already essentially an “NFT-like” time right: the right to use a certain amount of compute power for a fixed time period, sold via periodic auctions, priced in $DOT, with $DOT then burned—creating a deflationary mechanism and value for DOTDAO.

For FOOTPRINT, Dr. Wood proposes instead using a fungible token called $JAMKB with limited issuance—initially set equal to the total GB of RAM available in the validator set—held by DOTDAO, which distributes it via governance.

My main considerations to share with the community are:

  1. Dynamic capacity implies dynamic supply control. If validator capacity changes over time, then total $JAMKB supply must be adjusted by minting new tokens or burning existing ones.

  2. No permanent “sell” of the resource. Distribution cannot be a one-way permanent transfer, because that would amount to permanently handing third parties rights over a fundamental resource required for JAM. DOTDAO would likely lose sovereignty over the use of its core productive asset.

  3. Primary market must enable use without permanently transferring ownership. The primary allocation of $JAMKB should be structured so it supports intended usage and limits speculation. The market may still allow “wholesale” actors that redistribute in the secondary market, but this should not turn the primary into a deed-like permanent sale.

  4. Primary allocations should be on-chain on Polkadot and priced in $DOT (preferably), or at least in a $DOT-collateralized stablecoin (with a small incentive/discount for the $DOT option). Importantly, the $DOT paid for temporary rights over $JAMKB should be burnable and/or directed to the DOTDAO treasury in proportions decided by DOTDAO governance, and those proportions should be adjustable over time based on network needs.

  5. Secondary market can be flexible, including external and centralized venues if needed early on to maximize accessibility for developers experimenting with JAM-based products.

  6. $JAMKB leased in the primary can be managed via Asset Hub so that tokens remain in DOTDAO-controlled wallets, while temporarily assigned to users who acquired rights. Those users can then lock $JAMKB for RAM access or transfer them onward to other eligible accounts (based on secondary relationships).

  7. Eligibility rules should prevent abuse. I would require at least:

    • PoP (e.g., Proof-of-Personhood DIM-1)
    • a minimum $DOT holding comparable to validator requirements (at least 10,000 $DOT) to ensure “skin in the game” and discourage purely synthetic brokers from operating without real stake.

  8. Tokens must automatically return at lease end. At the end of each rental period, $JAMKB should automatically revert to full DOTDAO control for reallocation.

  9. Allow medium/long-term extensions carefully. It could be possible to support auto-extensions (e.g., weekly) for pre-agreed terms (from ~28 days up to a maximum of 24 months), using weekly rent payments in $DOT (with risk-adjusted discounts) or in $DOT-collateralized stablecoin. If tokens remain in DOTDAO wallets, governance can always respond to abnormal outcomes (e.g., failure to pay).

  10. A controller is needed. There must be an internal controller (human or protocol automation) that monitors such long-term agreements and triggers predefined actions automatically, or escalates to governance in exceptional cases.

In conclusion: for JAM to become a success for DOTDAO and produce durable value for its members—gradually increasing $DOT price due to genuine usage and real demand (not mere speculation, as with essentially all crypto assets)—it is crucial that FOOTPRINT stays exclusively controlled/owned by DOTDAO.

The temporary right to use FOOTPRINT should therefore be leased—preferably through a weekly primary on-chain auction on Polkadot, with a protocol-based mechanism ensuring DOTDAO retains underlying control. Temporary rights would be available only to eligible Polkadot users (PoP DIM-1) with a minimum $DOT holding threshold equal to validator requirements. Medium/long-term leasing could also exist up to a bounded maximum, with periodic rent and well-defined automatic or governance-based enforcement for non-compliance.

Finally, the $DOT collected in the primary market for temporary $JAMKB rights should be designed so that it can be burned and/or routed to the DOTDAO treasury in governance-defined proportions, adaptable over time, ensuring that value capture and incentive design remain aligned with Polkadot’s evolving needs.

I acknowledge the model will need further refinement and that JAM developers must clarify the operational details—but in my view, these principles align best with Polkadot’s mission, preserve DOTDAO sovereignty over the essential productive capacity, and keep value capture tied to $DOT growth through real adoption.

3

I wrote this on another thread and copying here too- seems we are finding some common ground.

[PROPOSAL] RAMTIME: Sovereign Footprint Rationing for JAM

Keep JAMKB in the DAO. Issue access, not deeds. Distribute the proceeds as sovereign wealth.

A community contribution to the open distribution question posed by Gavin Wood, June 27, 2026
Primary Source: JAM Gray Paper v0.8.0, June 3, 2026

Executive Summary

Gavin Wood’s JAMKB proposal correctly identifies JAM’s always-in-RAM state footprint as a scarce sovereign resource requiring dedicated rationing. His conservation primitive — 21 million units, fixed supply, 1:1 mapping to kilobytes, owned by the DOT DAO at genesis — is sound and preserved exactly in this proposal.

His Island Story analogy frames the DAO as a sovereign island government. History gives that sovereign a clear choice. Resource-rich nations that retained ownership and charged continuous rent — Norway’s oil, Alaska’s royalties, Singapore’s 99-year land leases — built lasting wealth for their citizens. Those that sold their scarce resource into permanent private ownership received a one-time payment and lost ongoing control.

The thesis: JAMKB is not the problem. JAMKB leaving the DAO is the problem. The decisive variable is not denomination (DOT vs dotUSD) but cadence: pay once, or pay continuously. Everything that follows turns on that distinction.

This proposal builds directly on the forum discussion already underway. batbayar’s pin-quantity-vs-pin-price framing is the analytical foundation. Nukeme3’s services-only periodic expiry, Abdulbee’s demurrage argument, ultracoconut’s non-transferability insight, and 9God’s coretime-auction analogy all point toward the same answer. This post attempts to make that answer concrete and complete.

1. The Analogy: Freehold vs. Leasehold

When a sovereign manages scarce land, history provides two paths:

The Freehold Model: Sells the resource into permanent private ownership for a one-time payment. Loses ongoing control. Wealth concentrates in early buyers who hold costlessly while latecomers pay secondary-market premiums.

The Leasehold Model: Retains ownership. Leases time-limited access. Collects continuous ground rent. Distributes proceeds to the community. Maintains permanent sovereign control.

Freehold (JAMKB distributed) Leasehold (RAMtime)
DAO control Lost at distribution Permanent
Revenue timing One-time at launch Continuous, scales with usage
Revenue at maturity Near zero Proportional to network size
Stranded capacity Permanent (lost keys) Bounded by ticket term
Speculative hoarding Structural Eliminated
Path reversibility Irreversible Adjustable by governance

Distributing JAMKB selects the freehold model. This proposal selects the leasehold model.

2. The Cadence Argument: Why Freehold Fails Long-Term

The decisive variable is cadence: pay once, or pay continuously?

Pay-Once (Bearer Token):
Growing network → high acquisition demand → DOT flows to DAO
Mature network → tokens circulate privately → DOT no longer involved
Revenue tracks the growth rate of usage. Fades at maturity.

Pay-Continuously (RAMtime):
Growing network → rising auction demand → DOT flows to DAO
Mature network → full utilisation → maximum recurring DOT flow
Revenue tracks the level of usage. Permanent at maturity.

This holds regardless of denomination. A JAMKB sold once for dotUSD still generates one-time demand. A RAMtime ticket renewed continuously in dotUSD generates permanent demand. Cadence and denomination are independent variables.

Freehold distribution also produces four structural failures that leasehold avoids:

  • Stranding: Lost keys permanently lock capacity. No reclaim trigger exists. A flow reclaims on non-renewal by construction.
  • Idle float: Reallocation requires a standing float of non-productive tokens. Gavin’s post concedes this is “not generally practicable” to avoid.
  • Enclosure: No holding cost means early buyers hold indefinitely at zero cost. The “coretime barons” dynamic, repeated at the state layer.
  • Speculative hoarding: An appreciating asset with no holding cost attracts non-productive holders who choke live capacity.

A holding cost (rent) fixes all four simultaneously. Rent is the minimal correction to the bearer deed.

3. The Three-Layer Design (Zero Protocol Changes)

One technical note before the design: §9.3’s threshold balance (at BL=1, JAM’s 10⁻⁹ denomination) prices the full 20GB of footprint at approximately 21 DOT to lock. §9.3 is an anti-spam dust filter, not a rationing mechanism. The TIS therefore governs a guaranteed tier for large production allocations — it does not gate all footprint. Small and experimental services use §9.3’s near-free base tier without touching the TIS.

Layer 1 — Conservation

All 21M JAMKB remain permanently inside the Ticket Issuance Service’s internal accounting. JAMKB never enters any external service balance. It never trades. The hard ceiling is preserved:

jamkb_available + Σ(active_ticket.kb) = 21,000,000

Gavin’s 20GB ceiling holds exactly. The only change: JAMKB is retained rather than distributed.

Layer 2 — Allocation

A Ticket Issuance Service (TIS) auctions non-transferable, time-bounded RAMtime tickets for DOT via periodic auctions. Services bid via deferred transfers (ΩT). The TIS:

Highest bidders → receive tickets {grantee, kb, expires_at}
Non-winners → refunded in the same Accumulate
Expired tickets → JAMKB auto-returns to available pool
Pool exhausted → TIS refuses new tickets (ceiling enforced)

No operator. No keeper. The TIS is immutable code (no ΩU call in its Accumulate), registered in χZ, running every block on protocol-allocated gas.

Layer 3 — Sovereign Wealth Distribution

Auction proceeds are split automatically (illustrative, governance-adjustable within constitutional bounds):

Destination Share Effect
Permanently removed from supply 50% DOT removed from circulation indefinitely
Treasury 50% Ecosystem development, validator sustainability

4. Why This Matters for the DAO

The structural alignment the leasehold model creates:

More JAM services → higher footprint demand → stronger auction clearing prices → more DOT removed from supply → better DOT value for every holder

This is not contingent on a speculative launch event. It compounds with actual network usage.

On the speculative window: Gavin’s Island Story explicitly notes short-term speculation “could, in the short-term, be advantageous to DOT DAO.” This is an honest point and not dismissed here. At current DOT prices, with validator costs exceeding coretime revenue, the near-term funding case for a JAMKB launch is real. The leasehold model forgoes that windfall for structural permanence.

A hybrid is a legitimate first-class option — not a compromise: retain 80% of JAMKB in the TIS for sovereign rent, release 20% into a DEX for a bounded speculative launch. Some upfront capital, most of the long-term structure. The community should debate what split, if any, makes sense.

5. Implementation and Trustless Enforcement

The mechanism requires zero protocol changes beyond creating JAMKB itself (which Gavin’s proposal already requires):

Primitive Section Role in TIS
χZ auto-accumulate §9.4 TIS runs every block, no external trigger
Code = hash, no ΩU §9.1 TIS permanently immutable after deployment
ΩT deferred transfer App. B Bid submission; three-way proceeds routing
χM deposit credit §9.4 Administrative threshold accounting
Native token NB §4.21 DOT denominated in 10⁻⁹ units
§9.3 threshold §9.3 Existing base tier, unchanged

On conservation depth: The TIS enforces the JAMKB ceiling in immutable code verified by JAM consensus under ELVES security. This is equivalent in practice to any other JAM service guarantee. However, Gavin’s bearer token has protocol-level conservation — base-layer arithmetic, hard-fork-only change. If the community and Fellowship determine that the conservation guarantee requires protocol-level depth, a minimal Gray Paper addition could be proposed. This is an honest open question, not a dismissal. We recommend the Fellowship assess it directly.

6. The Decisions for the DOT DAO

These are genuinely independent questions to be resolved by governance:

  1. Cadence: Sell once for a launch windfall, or lease continuously for permanent structural income?
  2. Pure or hybrid: Retain all JAMKB in the TIS, or retain the majority and release a minority for a bounded launch event?
  3. Distribution: Affirm the burn + treasury split, and set the proportions.
  4. Denomination: DOT or dotUSD? The TIS is denomination-flexible and can migrate by governance parameter.
  5. Conservation depth: Service-layer enforcement (no protocol change) or protocol-level primitive (minimal Gray Paper addition)?

7. Conclusion

Gavin’s mathematics and analogy are correct. The conservation primitive is sound. The island framing is right. The only structural error is the distribution: selling the island’s scarce land into permanent private freehold when the sovereign-wealth tradition — the one that actually worked, across Norway and Alaska and Singapore — says to keep the land, lease the use, and collect the rent forever.

This proposal retains JAMKB in the DOT DAO, issues time-limited RAMtime access tickets through a trustless immutable service, and routes auction proceeds to permanent supply reduction and ecosystem treasury. It eliminates the structural failures of the bearer deed, requires no protocol changes, and converts JAM adoption into durable DOT value — not a one-time launch event, but a permanent income stream that grows with the network.

We invite technical challenge — particularly on the conservation-depth question and the cadence-versus-launch trade-off, where community and Fellowship input will move the design further than any single proposal can.

Keep the land. Lease the use. Distribute the rent.

This is a discussion draft.

4

Exactly. The Gray Paper does not allow for any flow mechanism since there is no storage eviction.

JAM does not track which service put which key into storage (its footprint). It is therefore not possible for JAM itself to evict a service.

If you want service storage eviction you would need to change the Gray Paper and either:
Add a tracking mechanism in the form of `service → keys`
OR
Change the storage merklization to use per-services tries instead of one huge trie.

I think the closest analogy to look at is Smart Contract storage in Ethereum. You put your contract there once and it stays there forever. Your ERC20 contract will still be there in 10 years. Its a guarantee without which it would be useless.

5

You’re half right, and it’s the right place to push. The base protocol has no automatic eviction, and I said so in the first post. But the claim that footprint isn’t tracked is too strong, and the gap you’re pointing at isn’t special to a flow.

JAM does track footprint as a quantity per service. The §9.3 threshold scales with a service’s item count and total octets, so the protocol already knows how much state each service holds. A recurring charge runs against that number, so it needs no new service-to-keys map. That map is for enumerating and clearing a service’s keys, which is a separate job from metering the size.

And that clearing job is the deed’s problem too. Nothing at the base layer force-deletes a stranded service’s bytes, whether the capacity sits behind a held JAMKB token or a depleting balance. Both designs put the accounting in a service above the protocol, so eviction doesn’t tell them apart. What tells them apart is the behaviour on lapse. A held token reclaims nothing when the key is lost. A balance that runs down at least gives a controller something to act on. Clearing itself isn’t new. A holder already clears the 1KB before moving the token out, so the delete step exists, just holder-driven. A flow aims it at non-payment, which does want a trigger the base lacks today.

Your Ethereum comparison points the other way, to me. A contract still sitting there in ten years is the stranding, and it is why state growth stays a live worry there, with expiry and storage-rent ideas that keep resurfacing. The guarantee and the unbounded state are the same fact.

So I would narrow it. The open question isn’t whether footprint is tracked, it’s whether that §9.3 balance is held or depleting, and whether anything triggers reclamation when it empties. If the storage model rules a depleting balance out at the base, I’d genuinely like to see where.

6

I said that it is not tracked which keys are in the footprint, but maybe this was ambiguous:

Actually that was wrong on my part. After re-reading D.1, I see that the key constructor C does not mangle the service index, so its possible to enumerate all trie keys of a service.

I dont agree to call a contract sitting there for 10 years a stranding but that is opinions. I would hope my deadman switch is not swept because someone decided to call it dormant.

7

Appreciate you going back to D.1. That settles the feasibility half, and it puts us on firmer ground. The keys are enumerable, so a charge against footprint runs on bookkeeping the protocol already has.

On the deadman switch, I think it actually lands on the flow’s side. And let me drop the word stranding, since it carried more than I meant.

A flow doesn’t sweep on dormancy. It sweeps on an empty balance. Nobody decides your contract is dormant and reclaims it. The only test that matters is whether the rent is funded, which is an on-chain fact, not a judgment call about whether ten years of silence counts as abandoned. A funded switch sits untouched for as long as its balance covers the meter. You can load that balance years ahead, so it carries on without anyone topping it up, and it pays whatever the going rate has risen to.

Now hold that against free forever. Your switch lives free, but it lives at the mercy of whoever next proposes a sweep, and the test they pick for what counts as dormant is out of your hands. Ethereum has floated state expiry for exactly this, more than once. Paid persistence is the version where nobody gets to call your switch dormant, because you already funded its claim on the space.

What I’d call stranded is the other case: the owner is gone and the rent stopped, with nothing wired to reclaim the bytes, so they sit forever. A held deed lands there too, since the token clears nothing once its holder walks away. The flow is what catches it, because an empty balance is the signal to clear. A switch someone keeps funding never reaches that line.

So I don’t think the switch is the counterexample. If anything it’s the cleanest case for charging for persistence, since paying is what keeps the dormancy call out of everyone’s hands.

8

Good thread, thanks both.

9

Hello,

From a business and economic perspective :

Polkadot should not sell its “hardware” (state footprint), but rent it.

Selling JAMKB permanently would be like selling the servers instead of selling usage time. This would be a heresy for a decentralized infrastructure with limited physical resources.

Amazon does not sell its AWS servers — it rents them.

Polkadot should follow the same logic. DOT is (and should remain) the main token giving access to usage time (coretime).

JAMKB represents a scarce and persistent resource: memory space (state footprint). Selling it permanently would dilute this scarcity and create toxic competition with DOT.

JAMKB should always belong to the Treasury and be only rented by it, for variable durations (monthly, yearly, or perpetual with renewal).

The DAO could regularly reassess rental prices based on:Real supply and demand,

Hardware capacity evolution,

Overall network usage.

This way, the Treasury continuously receives revenue from JAMKB rentals. Since the Treasury belongs indirectly to all DOT holders through governance, it creates a virtuous circle:

The more the network is used, the more the Treasury grows, the more DOT gains in value.

Advantages of this model :

Long-term vision with a strengthening Treasury to fund future development.

Developers pay a predictable rental price and are not exposed to pure speculation on a secondary token.

Hardware remains 100% available and optimized.

DOT and JAMKB are not in direct competition: DOT remains the governance and compute-time token, while DOT holders become indirect “owner-landlords” of memory through the Treasury.

Longer-term vision:

With this well-managed resource model, we could even imagine a “Red Paper” to finance, via the Treasury, a “gpu-chain” for renting GPU power dedicated to AI.

Maybe even a decentralized AI named WUD one day.

That would be the sign that Polkadot has truly succeeded in its evolution.

10

Follow-up :

I agree that a rental model (instead of permanent sale) is much healthier for Polkadot. Concretely, I see two complementary approaches that could coexist through a dedicated marketplace managed by the Treasury / DOT DAO:

1. Fixed-term leases (variable duration) Flexible durations: 1 month, 6 months, 1 year, 2 years, etc.

Payment in DOT (or dotUSD) directly to the Treasury.

At the end of the term, JAMKB automatically returns to the Treasury for reallocation.

Possibility of auto-renewal or auctions for extensions.

  1. Metered flow / Pay-as-you-go The service deposits DOT (or a stablecoin) into a dedicated wallet.

As long as the balance is positive, the state footprint remains allocated.

The balance is gradually consumed based on usage.

When the balance reaches zero → automatic reclamation of the footprint (no more stranding).

Overall advantages: The Treasury receives recurring revenue → directly strengthens DOT’s value.

The DAO maintains full control over this scarce resource.

Developers get predictability without permanently losing sovereignty.

Avoids speculative competition between DOT and JAMKB.

Such an on-chain marketplace (on Asset Hub or via a dedicated service) seems to me the best way to align long-term incentives while remaining flexible for users.

11

@usualsuspect Thanks for putting the case in business terms. Your two-track sketch, fixed-term leases beside a pay-as-you-go meter that reclaims the moment the balance empties, is close to where I ended up in the opening post with the prepaid leases layered over a spot meter. @BizaRre arrived at leasing from the sovereignty angle above. The common ground across all three: the treasury keeps the asset and sells time on it.

You may not have seen it yet, but earlier this week W3F Research posted a mechanism in this family: Dynamically priced JAMKB via decaying deposits. A builder pays a refundable deposit and the protocol bonds the JAMKB on their behalf, so no user ever holds the token, which is your “JAMKB should always belong to the Treasury” by construction. The deposit decays toward a floor at a rate that moves with occupancy, the decayed part accrues to the DAO as revenue, and when space runs short a rule-bound reclaim opens a grace window on the most decayed slots and frees the ones nobody tops up. Closer to your meter than to your fixed-term lease, but the economics you want are there: recurring revenue with no permanent sale, and reclamation nobody has to decide. Worth a read, and the thread could use a business-side voice.

One detail in your posts is doing more work than its punctuation suggests. Each of your two tracks names the unit in passing: “DOT (or dotUSD)” in the leases, “DOT (or a stablecoin)” in the meter. The W3F proposal leaves the same choice open, to be set at the end. Your own conclusion is that the recurring revenue “directly strengthens” DOT’s value. That holds automatically on only one side of the parenthesis. Rent paid in DOT is the native token accruing to the treasury with every lease and every top-up. Rent paid in a stablecoin reaches DOT only through a conversion someone has to keep choosing to run, or through a stablecoin design the DAO has not picked yet. I pressed this in the W3F thread, and Jonas agreed there that denominating in DOT looks like more direct value capture; what stays open is whether a dollar-steady carrying cost for builders is worth the indirection. If the rental model is going to do for DOT what you want it to do, the parenthesis is the part to watch. The window to settle it is before the JAM upgrade proposal later this year, while all of this is still on paper.

12

Polkadot needs real cash flow and actual usage.

Renting JAMKB in both DOT and other currencies (stablecoins) makes the whole process much more developer-friendly and flexible.

This approach creates both direct and indirect value accrual for DOT.

As the Treasury grows — regardless of the currency received — Polkadot as a whole becomes stronger, and every DOT holder owns a proportional share of that growing Treasury. It’s a non-speculative way to increase the network’s fundamental value.Paying exclusively in DOT would indeed create stronger direct buy pressure and more frontal value accrual.

However, the flexible model (accepting stables) lowers the barrier to entry and can attract additional projects that might otherwise stay away.My reasoning is simple:

The success of JAM will first depend on real usage. Which model encourages more teams to build and deploy ?

Even if some projects pay in stablecoins, I believe the majority will still choose DOT.

But the extra projects we can capture thanks to this flexibility are worth it.There’s no such thing as small revenue .

Selling JAMKB permanently would be a huge mistake.

I’m fine with either approach as long as it generates recurring revenue for the Treasury.At this stage, we should aim to reach as many builders as possible. Failure is not an option for Polkadot.

We’ve already seen it:

High usage leads to value appreciation.
But high value appreciation does not necessarily lead to usage.

13

@batbayar, watching the debate over the last two weeks, something has become clear: support for the rental model has arrived through completely different doors.

Your case is cadence—a flow keeps the DOT sink on DOT and makes it recurring. @BizaRre’s is sovereignty—no permanent sale, or the DAO loses control of its core productive asset. @usualsuspect’s is operational, you rent infrastructure, you don’t sell it. Harbour Industrial Capital, just published, is value capture—a buy-back-and-burn only produces a recurring bid if there is a recurring stream to fund it. And the decaying-deposit design from @jonas and @kremena is a rental mechanism in full: bond, decay, reclaim.

Five arguments, five rationales, and one shared foundation that none of us has stated outright: every single one of them depends on the DAO retaining the footprint.

Cadence produces no recurring DOT demand on sold state—once it is sold, that demand terminates. Sovereignty is lost precisely at the point of sale. The buy-back bid is permanently capped at whatever remains unsold. Even the decaying-deposit mechanism, by its authors’ own scoping, prices only “the retained, DAO-controlled supply.” Retention isn’t just one argument among the five; it is the fundamental precondition underpinning all of them.

This surfaces the core question this thread was actually opened to address, and which both the WFC and the pricing design correctly leave open: how much footprint does the DAO actually retain?

Gavin’s note recommends bringing “a substantial portion” into private ownership, but he was explicit that the distribution itself is “not for me to define”—that “time and discourse is needed for DOT DAO to land at a good decision,” and the Island Story closes by handing exactly that decision to the community. This is that discourse. The point isn’t to argue against his recommendation; it’s to take up the invitation and answer the question—because it is the one variable that determines whether the entire framework built for the rental case actually functions, or only operates on the leftover fraction that remains after a sale. Denomination has a deadline and is nearly settled. This has none, which is exactly why it will be answered by default if we don’t address it deliberately.

So I’ll put it plainly to everyone who has been making the rental case from every angle: what is the retained share, and what framework should dictate it? My own answer is outlined in RAMTIME—retain the stock, lease the use, and treat any alienation as a decision that must clear a high bar rather than a default.

But the immediate priority is simply to get the question on the table, in the spirit Gavin asked for. We’ve spent two weeks agreeing on the mechanism, while the one variable it all depends upon sits completely unspecified.

14

Good summary, and the right question to put on the table. You are right that all five cases lean on retention; mine certainly does, since a flow only recurs on footprint the DAO still owns.

My answer: under a metered flow the retained-share question partly dissolves. The DAO never alienates the stock, so retention is 100% by construction, and what actually needs deciding is the release rate: how much use is out on lease at any moment, and on what terms. Governance can turn that dial every period instead of having to get one split right forever. A one-time percentage is only the natural frame if you assume sales. Drop the assumption and the decision becomes recurring and reversible, which is a better shape for a choice this large. RAMTIME’s high bar for alienation fits inside that frame; I would go a step further and make the default that there is nothing to alienate, only terms to set.

The Harbour Industrial piece makes the same dependency visible from the investor side. Their buy-back produces a recurring bid only while a recurring stream funds it, and only retained footprint yields one indefinitely. One detail in their text is worth pausing on: proceeds “denominated in DOT, or converted to DOT if denominated in dotUSD”. That conversion leg is an extra mechanism someone has to build and keep running. Settle in DOT and the bid is structural from the first block.

One firewall so the threads stay clean: the wish in the funding thread fixes the settlement unit only. Co-sponsoring it commits nobody on retention. That decision belongs here, and it should get its own referendum when it is ready.