Questions on JAMKB Distribution, Pricing and DOT Value Capture

Ecosystem
1

Gavin’s recent post on JAMKB helped clarify why JAM likely needs a separate state footprint resource-access token rather than using DOT directly.

My understanding is:

  • JAMKB would represent access to JAM state footprint.

  • 1 JAMKB would map to 1 KB of JAM state.

  • Supply would be fixed, possibly around 21 million JAMKB.

  • All JAMKB would initially be owned by DOTDAO.

  • DOT would continue to be used for governance, staking, collateral and coretime payments.

  • JAMKB would not replace DOT, but would represent a scarce JAM resource.

This makes sense from a protocol-design perspective. JAM state footprint is an inelastic resource because all validators must hold it in RAM. A separate resource-access token allows this scarce resource to be priced and allocated more cleanly.

However, I think the community needs clarity on the economic design.

Questions:

  1. How will developers or services acquire JAMKB from DOTDAO?

  2. Will JAMKB be sold for DOT, dotUSD, or another asset?

  3. If JAMKB is sold for dotUSD, how does that value flow back to DOT holders?

  4. Would it make more sense for JAMKB sales or auctions to be denominated in DOT, so that demand for JAM state creates direct demand for DOT?

  5. If JAMKB is released through an on-chain exchange, who determines the release schedule?

  6. Should some JAMKB be reserved for grants, loans, early JAM builders, or public-good services?

  7. If developers need both coretime and JAMKB, what is the intended relationship between DOT, coretime payments, and JAMKB acquisition?

  8. Could DOTDAO use proceeds from JAMKB sales to buy back or burn DOT, fund validators, fund ecosystem development, or replenish the treasury?

  9. What mechanisms will prevent JAMKB from becoming primarily speculative rather than being held by services that actually need state?

  10. What reporting should exist so DOT holders can see how much JAMKB remains under DOTDAO control, how much has been released, and what proceeds were received?

My main view:

JAMKB may be technically necessary, but its economic design must clearly preserve and strengthen DOT value capture.

If DOTDAO owns the JAMKB supply, then DOT holders effectively own the scarce state resource of Polkadot JAM. But for that to matter economically, the path from JAM usage back to DOT needs to be clear.

For me, the central question is:

Should JAMKB be acquired using DOT?

If the answer is yes, then JAM state demand can become direct DOT demand.

If the answer is no, then the community needs to understand how DOT holders benefit from releasing one of JAM’s most important scarce resources.

2

One additional technical question that occurred to me while thinking through JAMKB:

Will JAMKB be divisible?

If 1 JAMKB corresponds to the right to hold 1 KB of JAM state, can a service hold 0.5 JAMKB for 512 bytes or 0.1 JAMKB for roughly 100 bytes?

I assume divisibility would be important for efficient state allocation, but I haven’t seen it discussed yet.

3

Thanks for laying this out and I think it can be said in very plain words too.

Here’s the simple version. JAM is the new engine Polkadot wants to run on. Inside that engine there’s only so much room, and JAMKB is basically the set of keys to that room. To start, all the keys would belong to the community pot, which sounds reassuring. But keys sitting in a drawer help no one until they’re handed out. And the whole thing comes down to two small questions nobody has answered yet:

When the keys are handed out, what do people pay with? And does a normal DOT holder get anything back?

If people pay in DOT, then more folks using JAM means more demand for DOT, and every holder shares in that. If it’s something else, then a brand-new valuable thing gets sold off, and it’s unclear how regular holders come out ahead.

And let’s be honest about the bigger picture, because it’s the part most people quietly accept. The core of Polkadot is really built by one team. That’s not a conspiracy, it’s just the reality of who has the skills and has done the work. But it does mean that the direction, the design, and in practice the outcome of the votes all revolve around a small circle of people. So when something like this arrives as a blog post and then heads toward a vote, it’s fair to ask how much an ordinary holder’s voice actually moves it or whether it’s mostly settled before it opens.

I’m not saying that’s good or bad here. I’m saying it’s the deal you take on as a DOT holder, and it’s better to name it openly than pretend the vote is wide open when it usually isn’t.

None of this is anti-JAM. Quite the opposite: if JAM matters this much, the simple money questions deserve a clear, written answer, in plain language, before anything is locked in.

That’s really all most of us are asking for.

4

if JAM is coupled with the polkadot network as a service, and polkadot holds all the supply, the benefits are intrinsic for polkadot.

The dot holders voice and choices when confronted with proposals still leaves a sour taste in my mouth, still I believe that the direction/design should be a community wide consensus on how to move forward clearly, till then no community will be fruitfully build on the ecosystem. and no matter how good the systems are, a failure will follow.

I also thing we need better ways to communicate and start opening channels for expert, visionaries to pitch in. We need to be inclusive to succeed on this.

5

As a quick brainstorm…

I think it is fair to say that DOT holders have paid for JAM, and I would actually say that a hefty price tag.

JAM was sold out to the community as essentially Polkadot 3.0. With the brand promise: Dot is the only token.

Unfortunately, the Polkadot DAO is perceived by many members as too centralized. Despite the efforts made by the Foundation to distribute voting power. I would say that there are strong arguments to support those perceptions as being true.

As a community, we must ensure that if any other token is introduced, effectively breaking our “DOT only token” brand promise, there should be a direct and unquestionable positive economic impact to each DOT token holder.

For that reason, I think we should consider issuing the token directly to DOT holders 1 to 1 or whatever ratio that makes sense. Still the treasury and foundation would get an enormous amount of tokens, and the DAO would have a bag to keep running, yet the fairness to the DOT holders would be unquestionable.

6

My proposal:

Mint JAMKB by locking pUSD. When JAMKB is redeemed, it is burned and the corresponding pUSD is returned, similar to DAI.

According to Gavin’s proposal, this would happen:
Speculator buys JAMKB
↓
Doesn’t use state
↓
Reduces available capacity
↓
Developers pay more
That would be an inefficiency.
The RAM is physically available, but it is economically locked up.

According to the mechanism I’m proposing:
You lock pUSD
↓
You obtain JAMKB
↓
You use state
You release state
↓
You recover pUSD

The main motivation for holding JAMKB is to use RAM,
not to accumulate an asset while waiting for it to appreciate.

7

@ultracoconut

Speculation is a fair objection to Gav’s idea. I argued the same in my post, and your mechanism does eliminate it. But in eliminating it, you’ve quietly thrown away the thing that made Gav’s design work in the first place.

Minting against pUSD pins the JAMKB price to the mint rate: nobody buys on the secondary market above the cost of minting a fresh one, so the mint rate becomes a hard ceiling.

That recreates the flat, administered price for state that the fixed-supply design exists to avoid; when the lot is 99% full, minting still costs the same, so there’s no rising price pulling junk out.

You’ve solved speculation by removing the market, but the market was the point.

The speculation problem is better handled with demurrage or distribution policy than by making supply elastic.

8

Presuming the only usefulness of the proposed JAMKB token is for RAM allocation to JAM services, is it possible that the only owners of JAMKB should be JAM services? My immediate concern with an open market is another core time Barron situation.

DOT is still the token of transaction value, but the JAMKB just becomes a tokenized asset for the footprint resource. If the DOT DAO becomes the ownership stewards of the JAM system, it makes sense to me if the services purchase their needed JAMKB directly from the DAO. When no longer needed, they are returned to the DAO. There may also be an expiry which the service must renew periodically, similar to core time sales.

By keeping transactions between services and the DAO only, serves the necessary purpose without diluting the existing utility of DOT or converting the JAMKB into a speculative asset itself.

9

I think If JAM is designed to support, for example:

Target capacity: 20 GB
Current usage: 19.8 GB

then being at 99% utilization is not a failure.

It’s a success.

It means that nearly all of the available RAM is being put to productive use.

The goal of the system is not to keep memory artificially scarce or expensive. The goal is to ensure that memory is not over-allocated. As long as usage remains within the physical limit, high utilization is evidence that the resource is being used efficiently, not that the system is under stress.

On the other hand, I think what eliminates the state of usage is not the market price, which could be counterproductive, but rather the justification for keeping the RAM occupied while its deposit remains restricted, so I think it would work well.

10

Agreed that 99% utilization is success, not stress. nobody’s arguing for keeping RAM artificially scarce, and high usage is exactly what we want.

But that’s not the question the price is answering. The price isn’t there to prevent the lot filling up; it’s there to decide who yields once it’s full. “19.8/20 GB used” doesn’t mean 19.8 GB of valuable data. it means 19.8 GB of something, including junk that got in cheap and has no reason to leave.

“Full” isn’t the same as “well-allocated”.

When a high-value service shows up at 99%, a rising price is what makes the lowest-value occupant clear out so the slot goes to better use; the lot stays full but the composition keeps improving. A deposit can’t do that; you get your full deposit back whenever you leave, so nothing ever pushes low-value data out.

So “what frees the RAM is the justification for occupying it, not the price”. But in a deposit model, what enforces that justification? Either nothing does (junk stays, newcomers are walled out), or an administrator judges whose data deserves to stay, which is exactly the discretionary base-layer complexity the design is trying to avoid. Price is just the automatic, permissionless version of that justification.

11

So what you would be saying is that whoever pays more is necessarily placing something of higher quality into the RAM.

Does AWS do something like that?

12

“Quality” is your word, not mine. Price doesn’t measure how good the data is; it measures how much the holder will give up to keep the slot. When the slot is scarce, that’s exactly who should get it.

And, actually, yes, AWS does do this; spot instances are a live auction where AWS reclaims your capacity for a higher bidder when it’s tight. But AWS can allocate by fiat because it owns the hardware. JAM doesn’t own anything.

That’s the whole point: AWS replaces price with ownership, and JAM has no owner to do that. So decentralization is precisely why JAM needs a price; it’s the only allocator left when no one’s in charge to reclaim the RAM for you.

A refundable deposit with no eviction is the one model AWS doesn’t use; because nothing would ever free a full machine.

13

First, let’s cover the necessity of JAMKB. JAMKB serves as the storage credential for the JAM system, while CORETIME acts as the computing power credential. One represents storage space(RAM), and the other represents computing time(CPU). As we all know, any modern program requires both storage resources and computing resources to operate.
Given this, JAMKB and CORETIME are essentially the same type of instrument. We should not regard JAMKB as a new token; it is merely a credential granting the right to use storage space.
The solution therefore becomes clear: JAMKB should adopt acquisition rules analogous to coretime—obtained via auction with DOT as the only payment asset. Buyers may renew their rights upon expiry, or expired JAMKB will be reclaimed by the DAO automatically.
DOT functions as the underlying currency, whereas JAMKB is simply a functional “utility” we rely on. Its launch expands the real-world use cases of DOT, and DOT remains the sole medium to acquire JAMKB, bound by this criticalpremise.
We should actively deliberate on mechanisms for acquiring JAMKB through DOT.
My proposals are as follows:

  1. Anyone may bid with DOT through the DAO auction to secure a cycle of JAMKB usage rights. The DOT proceeds collected by the DAO will be split into two portions: one portion will be burned, and the other will flow into the treasury.
  2. When an individual obtains JAMKB usage rights, they may freely transfer these rights to others within the valid cycle. All such transfers must be settled in DOT, and the DAO may levy a nominal transaction fee (or zero fee at all).
  3. The DAO may allocate a portion of JAMKB directly to development teams or individual contributors via governance. Critical caveat: JAMKB distributed through this allocation method shall be non-transferable to third parties.
14

So what you’re saying is that the RAM should end up in the hands of whoever has the most money?
I think that if someone holds RAM but isn’t really using it, they’d rather get their deposit back than keep the RAM if it’s not providing any benefit.

By the way, IOTA used a similar mechanism, so it has already been tested in the real world and it works.

15

This is a good option thats reasonable.

16

Most of this thread keeps coming back to the same worry: how does demand for JAM state actually turn into demand for DOT? I think that depends on the pricing model more than it’s getting credit for.

It’s easy to forget that state already costs DOT today. Polkadot makes a service lock up DOT in proportion to the state it holds (the §9.3 threshold balance in the Gray Paper). So the real question isn’t whether state should cost something. It’s what the cost is priced in, and whether you pay it once or keep paying.

Gavin’s fixed-supply token is a pay-once model. State becomes a JAMKB holding, and even if you buy that token with DOT, the DOT demand is one-time. It’s tied to how fast usage grows, so it fades as the network matures. ultracoconut’s pUSD-mint has the same problem for DOT, just priced in pUSD, and as @Abdulbee pointed out, pinning the price to the mint rate kills off the market you wanted in the first place.

A recurring DOT charge keeps state priced in DOT for the long run. You pay out of a prepaid balance, and the slot frees when the balance empties. DOT demand then rises and falls with how much state is actually in use.

This is also where @9God and Nukeme3 are already heading. An auction in DOT with expiry and automatic reclaim is a flow, just a chunky one, and so is renewing periodically like CoreTime. That CoreTime comparison is the right one, and it cuts against the deed: CoreTime is already a flow. You don’t buy a core forever, you buy time, it lapses, you renew. That’s rent. The odd one out is the perpetual holding, not the flow. I’d only make it continuous instead of sold in blocks.

It also handles the speculation worry without killing the market. ultracoconut wants idle holders to simply hand the slot back, and a flow does that on its own, since you only keep what you’re paying for. Abdulbee’s demurrage idea is the same instinct, really. A draining balance is demurrage under another name. Price still decides who gets the slot, and not paying becomes eviction that happens automatically, which a refundable deposit can’t do.

I wrote up the longer version, including the lost-key and abandoned-state problem and how fixed-term leases would cover the long-lived services, here: On $JAMKB: should state footprint be a perpetual holding, or a metered flow?

§9.3 (‘Account Footprint and Threshold Balance’) already ties a service’s minimum balance to its item and octet count, so the DOT-for-state link is in the spec today. The open question is whether a held threshold counts as a real cost the way I’m treating it.

18

@ultracoconut

I get where you’re coming from, but pUSD is not the answer for me.

We all bet and believe in a decentralised, independent, powerful network. Owned by the many from all over the world.

Making this indirectly reliant on one countries currency - no matter how strong or widely used - would take things backwards. Peronally, I don’t want this promissed new world to be dominated by the decissions of one crazy person or administration, nor do I see the global community aspect taken into account.

What’s the point of moving to borderless, universal innovation if, at the same time, you remain stuck in the digital equivalent of an outdated value system?

19

This is terrible for DOT holders. The most valuable asset in the ecosystem gets its own token while DOT gets sidelined. No value capture, no real demand—just dilution of the DOT investment thesis.

There’s nothing worse than arrogance and ignoring community feedback. Let’s be honest: nobody in the community wants a second token. Stop diluting DOT’s value proposition.

20

Would you support the proposal if it involved locking DOT instead of pUSD?

There are some people on the telegram forum who aren’t too keen on pUSD. So we could steer the course in that direction. :ok_hand:

21

Updated proposal:

Mint JAMKB by locking DOT. When JAMKB is redeemed, it is burned and the corresponding DOT is returned, similar to DAI.

According to Gavin’s proposal, this would happen:
Speculator buys JAMKB
↓
Doesn’t use state
↓
Reduces available capacity
↓
Developers pay more
That would be an inefficiency.
The RAM is physically available, but it is economically locked up.

According to the mechanism I’m proposing:
You lock DOT
↓
You obtain JAMKB
↓
You use state
You release state
↓
You recover DOT

The main motivation for holding JAMKB is to use RAM,
not to accumulate an asset while waiting for it to appreciate.

Additional features:

  • JAMKB is non-transferable (preventing resale).
  • 5 DOT must be locked for each JAMKB minted.