Dynamically priced JAMKB via decaying deposits

Ecosystem
1

Dynamically priced JAMKB via decaying deposits

by Jonas Gehrlein (@jonas) and Kremena Valkanova (@kremena)

Disclaimer: This is posted as a contribution to community discussion. It is a proposal only: nothing here is a commitment, no token is being offered or sold, and any decision to implement rests solely with DOT DAO. The design is exploratory and likely to change.

Abstract

This is a proposal for how $JAMKB, a token mapping at a fixed rate to state-footprint usage on Polkadot JAM, could be priced, distributed, and reclaimed over time, following its initial issuance on Polkadot Asset Hub.

It builds directly on Gavin’s recent note on the case for a dedicated state-footprint resource-access token. That note argues why JAM needs a specialized, inelastic-supply token distinct from DOT, and concludes that price-finding and rental arrangements should live above the base-layer protocol (JAM) rather than inside it. It deliberately stops short of specifying those mechanisms. This proposal takes up that open question.

We also address how the $JAMKB that the DOT DAO retains can drive value back to $DOT, treating it as an additional revenue source for Polkadot. A separate question, which we leave open for community discourse, is how much of the initially minted supply should eventually pass into private ownership; that portion falls outside this mechanism (and potentially under a different one), which governs only the retained, DAO-controlled supply.

Interestingly, we initially devised this mechanism to replace Polkadot’s state storage system, then realized it solves the problem above just as elegantly.

Motivation

Gavin’s note makes a strong case for representing JAM’s coherent state footprint with a fixed-supply, single-purpose resource-access token called JAMKB at a 1:1 mapping to bytes, initially held entirely by the DOT DAO. The fixed supply gives the protocol a clean soundness guarantee: footprint can never exceed what validators can hold in RAM, because the tokens needed to occupy it simply do not exist beyond genesis.

What the note leaves open is the economics on top of the token: how a service acquires JAMKB from the DAO, at what price, how that price should behave as state fills, what keeps no-longer-useful state from sitting idle indefinitely, and how a full system frees space when it must. The note gestures at distribution — for example, drip-feeding tokens into an on-chain exchange — but does not specify a pricing or carrying-cost mechanism. This proposal is an attempt to fill exactly that gap.

A key principle underlies the whole design. JAMKB is not a cryptocurrency; it is an access right to a finite, real resource, footprint that every validator must hold in RAM. This inverts the usual token-economic logic. In an ordinary token economy, supply that is lost or locked away is, if anything, a benefit to remaining holders, since their share of a fixed pie grows. Here the opposite is true: every unit of JAMKB that drifts out of productive use is footprint capacity sitting idle, deadweight that no one can build on and the protocol gains nothing from. What keeps this from happening for JAMKB subject to our pricing mechanism is that every bonded unit retains a permanent link back to the protocol: it can always eventually be reclaimed and re-allocated to a service that will actually use it. No unit is ever permanently stranded.

Three requirements shape the design:

  • The price of acquiring footprint should reflect scarcity. Cheap and near-frictionless when state is abundant; rising, and rising faster, as capacity tightens.
  • Holding footprint should carry an ongoing cost, not a one-time one. Otherwise a holder who no longer needs their state has no reason to release it, and the soundness cap is reached by accumulation of dead weight rather than live use.
  • Footprint should not become a speculative asset. A fixed-supply right that users hold and trade can be hoarded or cornered: bought cheap when state is abundant, withdrawn from genuine users, and sold into scarcity. Access to footprint should track use, not the expectation of resale.

The mechanism below — dynamically priced JAMKB via decaying deposits and scarcity-triggered reclaim — is our attempt to meet all three while leaving Gavin’s fixed-supply soundness guarantee fully intact.

Overview

We add three components on top of the fixed-supply JAMKB token:

  1. A posted acquisition price that responds both to how full state is and to how fast it is filling.
  2. A decaying carrying cost on held footprint, applied continuously and computationally cheaply, that returns value to the DAO rather than destroying any tokens.
  3. A scarcity-triggered reclaim that frees space when the system approaches saturation.

One structural choice underpins all three. For carrying cost and reclaim to be enforceable in an ownerless system, occupying state must bond JAMKB to the slot under protocol-controlled terms, rather than merely checking that the holder happens to hold enough in a free balance. Thus, JAMKB is essentially a footprint right: exactly one is bonded per KB and is held by the protocol on the user’s behalf and it returns to the DAO in full on release. What the user actually pays is a separate deposit, in some other unit, and it is this deposit that decays as a carrying cost and is partially refundable.

The pricing and decay mechanism below is described in abstract price units. The settlement asset (dotUSD or DOT) and how it ties value back to DOT are addressed at the end.

Pricing

Let occupancy be ut = Ut / C, where Ut is occupied footprint and C is the soundness-capped maximum. The posted price to acquire one unit of footprint at time t is a product of two factors:

Pt = F(gt) · P(ut + Δu)

where P(·) is a structural curve responding to the level of occupancy and F(gt) responds to the flow — how fast occupancy is changing. The level factor is evaluated at ut + Δu, the occupancy the allocation results in, where ut is current occupancy and Δu the size of the allocation being priced. Both factors are needed because occupancy alone is a lagging indicator: if state is filling rapidly the system is heading toward scarcity well before ut reflects it, and the posted price should react sooner.

Structural curve P(ut)

The level-based factor is a static convex curve in occupancy:

P(u) = Pmin / (1 − u)k

with Pmin the floor price at zero occupancy and k controlling how steeply the price rises as capacity tightens. For example, with k = 3, P(0.5) = 8 Pmin, P(0.8) = 125 Pmin, P(0.9) = 1000 Pmin — making the price cheap across most of the occupancy range and escalating sharply only when footprint is genuinely scarce.

Flow factor F(gt)

The flow-based factor is a stateless function of current flow conditions:

F(gt) = min( exp(β · gt), Fmax )

The signal gt is a smoothed measure of recent net allocation activity, normalised by remaining headroom:

gt = α · [ ΔUt / (C − Ut) ] + (1 − α) · gt−1 − δ

where ΔUt is allocations minus releases over a short window. The headroom normalisation gives gt a direct reading: at a sustained rate, gt ≈ 1/N means remaining capacity will be consumed in N periods. The EMA, parameterised via a half-life of a few days, smooths noise so the price tracks sustained trends rather than single-block bursts. When gt > 0 the flow factor amplifies the structural price; when gt < 0 (sustained net releases) it dips below 1, easing prices during slack. In prolonged periods with no allocations, suggesting that storage is overpriced relative to current demand, a small downward drift δ gradually reduces the price (similarly to a Dutch auction) until demand returns. The cap Fmax prevents the exponential from exploding during anomalous periods, above which the structural curve carries the escalation.

These magnitudes are illustrative. Realistic values of gt depend on usage patterns, so the calibration is a default for governance and simulation to refine, not a claimed optimum.

On choosing a price curve rather than an auction

An auction is a natural alternative for the acquisition price, as coretime shows. For footprint, the clean design would be to discretize time into epochs and auction available footprint at each epoch boundary, while retaining the decaying deposit as the carrying cost and aligning unbonding to the epoch. The periodic structure provides the defined bidder set and clearing event that a continuous allocation process otherwise lacks.

An auction’s information-revealing benefit, though, is most pronounced under sustained excess demand. Absent that competition an auction simply clears at its pre-set reserve price, effectively replicating a pricing curve, but with added periodicity and friction. Besides being much simpler to operate, a curve prices both abundant and scarce conditions continuously, rising automatically as utilization increases. Builders making multi-year infrastructure commitments benefit from a smooth, predictable cost path rather than periodically resetting clearing prices. For these reasons, we use a pricing curve throughout. The only plausible exception is genuinely contested reclaimed slots during periods of scarcity, where an auction-like mechanism may be appropriate (see reclaim stage).

Carrying cost via decaying deposits

Recall that decay acts on the deposit — the asset the user pays at allocation — and never on the bonded JAMKB, which stays fixed at one per KB throughout and returns to the DAO in full on release. Everything in this section concerns the deposit.

Holding footprint should cost something continuously. Rather than collecting a recurring fee — which would require per-account billing and balance monitoring — we let the recoverable portion of the escrowed deposit decay over time, at a rate that shares its shape with the posted price:

c(ut, gt) = (cmin / Pmin) · Pt = cmin · (1 − ut)−k · min( exp(β gt), Fmax )

Here cmin sets the decay rate at zero occupancy and zero flow. Reusing the same (ut, gt) response for decay as for pricing is deliberate: the cost of acquiring new footprint and the cost of continuing to hold existing footprint express the same scarcity signal, one as an entry price and one as a continuous carrying cost. Any asymmetry would create strategic incentives — softer decay lets holders sit on stale state while the price moves without them; harsher decay pushes holders out faster than the price warrants. Governance may optionally decouple the two, giving decay its own gentler exponent and flow gain for a flatter carrying-cost profile, at the cost of reintroducing that asymmetry.

A global decay accumulator

The recoverable balance depends on the integral of a time-varying rate over the whole holding period. Storing per-deposit history, or touching every bond each block, would be infeasible at the scale of millions of allocations. Instead the protocol maintains one global running sum:

A(t) = A(t−1) + c(ut, gt)

incremented once per block in constant time regardless of how many bonds exist, since c(ut, gt) depends only on current network conditions and is identical for every bond at a given block. Each bond stores just two values — its original bonded quantity and the accumulator value at creation. Accumulated decay for any bond is then A(t) − A(t0), reconstructed on access with no per-item updates. The recoverable fraction is

R(t) = D0 · ( 0.1 + 0.9 · exp( −(A(t) − A(t0)) ) )

which is monotonically decreasing, can never exceed the original bonded amount (so the protocol never owes more than it holds and never mints), and asymptotes to a structural 10% floor.

Reclaim under supply shortage

Decay applies continuous pressure, but as the system approaches saturation, decay alone may not free space fast enough. At that point the protocol activates reclaim. Critically, reclaim is automatic and rule-bound: it triggers when occupancy crosses governance-defined thresholds, and it never involves a discretionary judgment about whose state is worth keeping.

Reclaim activates gradually. At a first, high occupancy threshold only the most-decayed bonds become eligible; at progressively higher thresholds the eligibility bar relaxes so more bonds come into scope. Bonds are prioritised by accumulated decay A(t) − A(t0): a larger value means the bond has been held longer and more cheaply relative to current conditions, and has the weakest residual claim.

When a bond becomes reclaim-eligible the protocol emits an on-chain event and opens a grace period whose length shortens as occupancy rises. During the grace period the holder may restore the slot by topping up to the current posted price Pt. Ownership is never lost during this window and restoration is a top-up, not a repurchase. If the holder does not restore, they receive their current decayed balance, the bond’s JAMKB returns to the DAO, the slot is freed and re-allocated at the posted price like any other. When multiple parties would pay Pt for the same freed slot, a community could alternatively allocate reclaimed slots through a one-shot sealed bid instead of first-come allocation.

Value capture for Polkadot

The price and deposit for JAMKB allocated by the Polkadot protocol should be denominated either in DOT or (if available at the time) in dotUSD (working term for any DOT-backed stablecoin). Either way, a user only ever pays a deposit and is refunded in that asset and never holds JAMKB itself; the protocol bonds it on their behalf. JAMKB therefore remains a footprint right rather than a tradable asset, which also significantly improves the UX of interacting with the system. Further, it reduces the speculative aspect and makes sure the footprint pricing is not biased by speculation. The value capture for Polkadot comes from the portion of each deposit that decays away: this is protocol revenue, which the DOT DAO can route into activities that increase protocol value, such as buybacks, treasury accumulation, and other activities.

Conclusion & future direction

This proposal offers a dynamic pricing mechanism that uses decaying deposits to price the portion of JAMKB that remains under the control of the DOT DAO and thereby can be used to capture value for Polkadot. Our goal at this stage is to gauge community sentiment on the approach. If it is generally well received, further steps could include simulating the mechanism across a range of parameters and demand schedules, to better understand how such a system would behave under different regimes.

3

@jonas @kremena This is the layer Gavin’s note left open, and it closes the two gaps the footprint debate kept naming. A continuous carrying cost, so state that no longer earns its keep is not free to sit on. And a reclaim path, so a full system frees space by a fixed rule, with no one judging whose state deserves to stay. It also lands where the metered-flow side of the debate was pointing. Bonding JAMKB on the user’s behalf and letting them hold only a deposit is the cleanest move in the design. The speculation worry comes off the table with no one having to police it.

I want to press on one line you left open, because I think it decides more than its placement suggests. The mechanism is written in abstract price units, and the settlement asset is set at the end, DOT or dotUSD. That last choice is the one parameter that sets whether your value-capture section runs on its own or needs a policy decision behind it.

Read that section under each option. The revenue is the part of every deposit that decays to the DAO. If the deposit is dotUSD, it reaches DOT only when the DAO converts it, a buyback someone has to choose to run and keep running. If the deposit is DOT, the decayed part is the native token itself accruing to the DAO, with no conversion in between. And the demand is native too: each new allocation, and each top-up to hold a slot under reclaim, has to source DOT. Because the design rents footprint instead of selling it once, that demand keeps coming. That recurring pull toward DOT is what the footprint debate kept asking JAMKB for, and a single sale was never going to give it.

dotUSD is not free to give up. It buys reach for services that budget in dollars, and a carrying cost that does not swing with the DOT price, which is the steadiness you note builders want for multi-year commitments. Real tradeoff. What it costs is the automatic value capture above, and governance should weigh those two separately instead of inheriting the answer from whichever unit the first implementation reaches for.

Which is why denomination is not a detail to fix inside the mechanism later. It is a standing economic line, the kind the DAO sets through a Wish for Change, the way you did for the Dynamic Allocation Pool at referendum 1827. The window to set it is while the design is still in abstract units, and before the JAM upgrade proposal the roadmap puts in the back half of this year. Settle it in the open now and there is nothing entrenched to unwind. An assumed default, found after launch, takes another referendum to move.

If simulation is the next step, denomination is cheap to include. Run the value-capture path both ways, and the difference should show up on its own: how much reaches DOT under each, and how automatically.

4

@batbayar thanks for the comments. I agree that denominating the deposit in DOT looks like more direct value capture, since each allocation and top-up would have to source DOT. But as you point out, that couples the carrying cost to DOT’s price, and builders committing for multiple years likely prefer a deposit whose value is denominated in something familiar and stable, i.e. USD.

This is where a DOT-backed stablecoin earns its place. Note, that we are using dotUSD here as a general term for a DOT-backed stablecoin. To my knowledge, the DOT DAO has not yet decided on a final design, which crucially influences how DOT itself captures value from dotUSD. But I’d imagine that the DOT DAO will want to settle for a design that drives value back to DOT. Going for the obvious choice of an overcollateralized design that uses DOT, there is still indirect demand driven to DOT.

There’s a second benefit as the protocol will likely carry some of its own expenses in dotUSD. The portion of each deposit that decays to the DAO would then accrue in the same unit those expenses are settled in, so the decaying deposits could fund them directly, with no conversion step.

I’d say that the question of whether to use DOT or some dotUSD is worth discussing deeper but does not immediately influence the proposed pricing mechanism too much.

5

@jonas Thanks, that is a fair and generous reply. I want to start where you start, with the concession, because it frames the real question. If settling in dotUSD returns value to DOT as directly as settling in DOT does, your builder point wins and the denomination barely matters. So it comes down to the two channels you give for how dotUSD still feeds DOT. Both are real. I think both are weaker than settling in DOT, and here is why.

The collateral channel only drives DOT demand if the stablecoin is overcollateralized in DOT, and only when new dotUSD is minted against fresh DOT. You say yourself the design is not settled, and that it does most to decide how much value reaches DOT, which is the point: the demand rides on a choice still to be made. A builder can also buy dotUSD on a secondary market and lock no DOT at all. What does get locked comes back on redemption, so the DOT is parked for the life of the position and then released, where a decayed DOT deposit stays with the DAO for good. And the argument takes for granted that the goal is to drive demand to DOT. If it is, denominating in DOT reaches it directly, without waiting on a stablecoin design that is still open.

The expense channel I would keep apart from value capture. If decayed deposits fund dotUSD expenses, that revenue is spent on running the network and does not reach the people holding DOT. Handy for the treasury’s books, and genuinely so, but it is not capture. It is also symmetric. Revenue in DOT funds the network’s DOT-side needs, a buy-and-burn or the DOT part of the treasury, with no conversion either. So a missing conversion step is not something dotUSD gives you. It comes from matching the revenue unit to the expense unit, and which unit the protocol settles its bills in is one more choice, not a fixed fact.

Predictability is worth keeping in proportion too. The recoverable deposit already decays at a rate that moves with occupancy and flow, so the carrying cost is not fixed in any unit. dotUSD takes out the currency swing, which is a real gain, but the builder is committing to a cost that moves with scarcity either way.

So I would not leave it there as a detail that does not change the mechanism. You are right that it does not, and that is the reason to settle it on its own, rather than letting the first implementation settle it by default. Fixing the unit as DOT costs the pricing curve nothing. And for the people in the other thread who want the value-capture path written down, resting it on a stablecoin design the DAO has not chosen yet is the sort of later they are worried about. That is what a Wish for Change is for, and it touches nothing in your mechanism.

6

I think the idea of using decaying deposits is an interesting alternative to static pricing because it allows demand to influence resource allocation without requiring constant governance intervention.

One question I had while reading the proposal is how predictable the pricing would be from a developer’s perspective. If the deposit decays dynamically based on utilization, could periods of rapidly increasing demand make it difficult for teams to estimate the long-term cost of publishing or maintaining JAMKB resources?

It also seems worth considering whether the decay parameters should adapt over time. During the early stages of the ecosystem, lower effective costs may encourage experimentation and adoption, whereas a more mature ecosystem might benefit from stronger scarcity signals. A fixed decay model could behave quite differently depending on the overall level of network activity.

Overall, I like the direction because it treats scarce on-chain resources as something that should be allocated through economic incentives rather than arbitrary limits. The key challenge will likely be finding parameters that provide predictable incentives while remaining responsive to changing demand.

7

Thanks @croutonteam. I think the predictability concern is more tractable than it first appears, and it connects naturally to your second question on parameter adjustments.

On predictability: it helps to separate the up-front price from the ongoing cost. The purchase price is fixed and known at allocation. What decays afterward is the recoverable portion of the deposit, and while that does vary with scarcity by design, it is bounded and computable. The most a developer can lose is the deposit minus the 10% floor they are guaranteed back, so the maximum absolute cost is known from day one. At any moment the recoverable amount is known exactly from the public accumulator, A(t) − A(t₀). Because both pricing and decay are deterministic functions of occupancy u and flow g, a team can compute their cost under whatever demand scenarios they want to plan against. So under rapidly rising demand the cost rises but it rises within known bounds along a calculable path. As @batbayar noted, denominating in a stable unit (dotUSD) also removes the currency swing, so the cost is predictable in real terms too.

On adapting the parameters over the ecosystem’s life: they are governance-set and can be revisited if a misspecification is suspected. Two things are worth adding, though. First, the curve already delivers a lot of your intuition on its own: the structural term P(u) = P_min / (1−u)^k gives low prices at low occupancy, and since occupancy tends to accumulate over time (storage is usually held for long use, and at low occupancy there is little pressure to release because the deposit decays slowly), “cheap early, stronger scarcity signals later” is largely what the mechanism does already without a scheduled parameter change. Second, going back to your question on predictability, any retuning by the DAO undermines a forecast a developer has already made and committed to. So we would treat parameter changes as a sparingly-used correction rather than routine, and lean on the two adjustments already built in for ordinary drift: a downward drift δ that lowers the price during sustained inactivity (correcting overpricing), and the flow factor F(g) that lifts it when allocations accelerate (correcting underpricing). Baseline recalibration is then reserved for genuine misspecification, which is what the demand-scenario simulations we plan to run are meant to pin down.

8

@kremena Thanks, the bounded-loss framing is the best answer on predictability this thread has had. The most a builder can lose is fixed at allocation, and what remains recoverable is public at every moment.

One addition, since a line of mine made it into yours. I did call the currency swing a real gain for dotUSD, but that sentence had a second half: the builder is committing to a cost that moves with scarcity either way. Your own reply shows why the second half matters. Where a builder lands inside that range is set by occupancy and flow, so under rising demand the cost “rises within known bounds along a calculable path” no matter which unit it is written in. The stable unit removes the exchange rate, one source of movement, and leaves the one the mechanism is built around. A real gain, but narrower than it appears standing alone. And it sits on the other side of the scale from what Jonas granted above, that denominating the deposit in DOT looks like more direct value capture. Narrow gain against direct capture is a live choice, and the DAO should be the one making it.

Which is why the last line of your post is the part I would push on. I closed my first reply here by asking that denomination be folded into the simulations, and now I can make it specific. If demand-scenario simulations are going to pin down the baseline parameters, denomination could ride along as one more scenario dimension: builder carrying cost and DAO revenue under both units across your demand paths, with the conversion policy dotUSD would need spelled out as an input. The curve prices in abstract units anyway, so the mechanism itself would not move. Then whichever way the DAO fixes the unit, it fixes it with numbers in front of it. Happy to help spec those scenarios if that is useful.

9

Thanks for putting this together—this is one of the most practical discussions around JAMKB economics I’ve seen so far.

We’ve recently been building ComputeFlux, an AI compute infrastructure project for the Polkadot ecosystem, and have already been deploying and testing against Paseo while preparing for the future transition toward JAM.

So this proposal is particularly timely from our perspective.

From a builder’s perspective, I really like the idea of treating JAMKB as access rights to a scarce protocol resource rather than another speculative token.

One question I have is around long-term cost predictability.

AI infrastructure often maintains persistent state for agent memory, embeddings, caches, indexes, and user context over long periods of time.

As builders, we can usually tolerate prices that are high.

What is much harder is uncertainty.

Have you thought about how infrastructure projects should estimate long-term operating costs under a dynamically changing JAMKB price?

We’d be very interested in exploring how ComputeFlux could eventually build on JAM, and we’d be happy to share feedback from the perspective of a real AI infrastructure workload as these ideas continue to evolve.

10

Here the HIC take on this topic: Medium

11

Thanks for the perspective Max.

Useful.