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.