A proposal pitches JamScript, a Web2-style language for Polkadot's JAM
Victoria Shinder2 min readA Polkadot forum post dated 20 September 2026 introduces JamScript, described as a language for building applications on JAM — Polkadot's planned successor execution model. The pitch is that a developer could target JAM while writing something close to ordinary application code, without having to hold JAM's internals in their head. The proposal frames JamScript as the language and application model, with a separate SDK supplying the tooling around it, such as clients.
⚠ This is a forum post, and a proposal. It is discussion, not a decision and not a shipped platform. We cover it as what it is: an early design being put to a community, by a single author, on a forum.
What it means
The abstraction being sold is the interesting claim, and also the hardest to deliver. "Build like Web2, without understanding the underlying mechanism" is the promise every higher-level chain language makes. It is genuinely valuable when it holds and actively dangerous when it leaks — a developer who does not understand JAM's execution model will write code that is correct until the abstraction stops covering the case that matters.
JAM is unshipped, so JamScript is a language for a target that is still moving. Building the developer experience before the execution model is finalised can go two ways: it pulls the platform toward what applications actually need, or it commits to assumptions the final JAM contradicts. Which one this is will not be clear from the proposal.
Read it as a signal of where Polkadot's ecosystem is putting effort, not as a tool to adopt. A community proposal for a JAM language says the ecosystem is far enough along to argue about developer ergonomics. That is worth knowing. It is not a reason to write anything against it yet — and the forum is where its assumptions will get tested first.