After a long period of exploration, we have made the final decision: we will launch a streamlined version of JAM as a parachain, and build applications on top of it. After the JAM mainnet goes live, MiniJAM will continue to run as an L2 on JAM.
WTF?
In simple terms, MiniJAM makes the following replacements and preserves the following parts of the JAM protocol:
-
The original JAM consensus process will be replaced by Polkadot parachain security and the MiniJAM worker validation mechanism;
-
Core JAM mechanisms such as PVM, service, refine, and accumulate will be preserved;
-
Data availability and D3L will be replaced by the bulletin-chain approach in the early stage;
-
The accumulate process will be moved into the runtime;
-
JAM’s assurance, guaranteeing, auditing, and adjudication processes will be replaced by an off-chain Worker mechanism;
-
JAM state will be managed by the parachain runtime.
This allows JAM’s core experience to run earlier, in a parachain form, while preserving the parts that matter most.
What Will This Bring?
JAM is different from existing blockchains. It introduces a new execution model and opens up a new design space for applications. In fact, JAM developers have already built a number of useful tools, such as:
-
Building applications with C, C++, and Python;
-
An IDE for building services in C;
-
An EVM-resistant, order-book-based DEX.
You can learn more about SDKs and tools at GitHub - DrEverr/Awesome-JAM: Awesome JAM - Curated list of JAM resources, tools, SDKs, tutorials, videos, and articles · GitHub. In a few months, you will be able to experience these things directly in real products.
But it is precisely because JAM is so disruptive that its development cycle is longer. This creates a long vacuum before JAM officially goes live. Ecosystem development can easily lose continuity, while JAM also depends heavily on its own tools, SDKs, middleware, wallets, and development patterns.
To solve these problems, we have set the following goals for MiniJAM:
-
Seamless project migration: After the JAM mainnet matures, projects in MiniJAM that need to migrate should be able to move to the JAM mainnet with minimal friction. After that, MiniJAM will continue to operate as an L2 for JAM.
-
Transparent migration: Users should not need to care about the underlying migration process as much as possible.
-
Tooling compatibility: Ecosystem products built for MiniJAM, including tools, SDKs, frameworks, middleware, wallets, and more, should be able to adapt quickly to the JAM mainnet.
This preserves continuity for the JAM ecosystem, prevents developers and users from being lost during a long waiting period, and makes JAM a de facto progressive upgrade. Meanwhile, JAM itself can continue to develop at a more deliberate pace. When the JAM mainnet goes live, we hope it will not be facing an empty field, but an ecosystem that already has tools, experience, and real applications.
MiniJAM also allows the community to accumulate real operational experience in advance, including around JAMKB. This means that after the JAM mainnet goes live, the community can adopt solutions and set parameters based on more mature experience, rather than starting from zero.
Ecosystem Development
Early developers shape the initial implementation of a product, and that also solidifies the initial values of an ecosystem to a large extent. We believe these values should be treated as part of the public contract.
Community Launch
We seriously evaluated whether MiniJAM could run directly with DOT, but this is not realistic.
MiniJAM workgroups do not perform ordinary tasks. They perform validation work that is closely related to consensus security. If DOT were used directly, the attacker’s cost and potential reward would become severely asymmetric, making it almost impossible to guarantee system security.
Therefore, MiniJAM must have a native token. To avoid any confusion with the JAM name and brand, it will be named MINI.
To ensure a fully community-driven launch, MINI will have no private allocation of any kind, except for treasury and liquidity. Another benefit of MINI is that it allows us to implement ecosystem incentives more flexibly. MINI will be launched as soon as possible, so that there is enough time for price discovery and holder distribution before the MiniJAM mainnet goes live, allowing the network to meet its basic economic security requirements.
Governance and Incentives
MiniJAM will follow the principle of governance minimization. OpenGov will only be responsible for strategic and security-level decisions, and each strategic track should have a clearly defined team and owner.
For ecosystem incentives, MiniJAM will prioritize user experience and maintain openness as a principle.
In the early strategy, MiniJAM should treat incentive mechanisms themselves as products, and prioritize incentivizing the creation of those mechanisms, such as incentive market protocols and launchpads. The advantage is simple: if even one incentive mechanism truly works, the entire ecosystem can be pulled forward.
Therefore, in its early stage, MiniJAM will encourage projects built around incentive mechanisms themselves, including but not limited to:
-
Acceptance-based streaming incentives: Automatically verify and distribute incentives based on continuously verifiable service quality, such as RPC availability, latency, and stability.
-
AI-assisted acceptance: In more complex scenarios such as user growth, content quality, and developer contributions, AI can help assess real value and reduce incentive misalignment.
-
Launch platforms: From low-barrier rapid launches to more selective screening mechanisms, launch platforms can provide entry points for projects of different stages and types.
-
Bidirectional incentives: Early users should not only be users, but also discoverers and promoters, allowing projects to face real users from the very beginning.
-
Public goods incentives: Provide continuous support for ecosystem public goods such as documentation, SDKs, wallets, indexers, and infrastructure.
-
Passive incentives: Allow users or communities to actively express needs and attach incentives to them. Even if a project team has not yet started or has already paused, market demand can still be expressed and satisfied immediately.
These mechanisms are not unique to MiniJAM. They have already been widely adopted in other ecosystems. In essence, this is a necessary follower strategy based on the principle of remaining open toward competitors.
Only by first acknowledging that effective mechanisms already exist, and being willing to absorb them, can MiniJAM have a real chance to surpass others in new application directions.
JAMKB
You may also care about how MiniJAM will handle JAMKB.
I have been closely following the JAMKB solutions proposed by the community. Before the testnet, I will publish a separate JAMKB evaluation post, assessing whether MiniJAM should implement it in advance from the perspectives of developer friendliness, effectiveness, recoverability, and more.
In an optimistic scenario, we will find an effective solution and implement it after it passes MiniJAM governance, avoiding the complexity of later upgrades. Otherwise, MiniJAM will adopt the most conservative approach.
What Happens Next?
We have already completed the core on-chain part. The plan going forward is:
-
Testnet: launch within 1–2 months;
-
Mainnet: launch within 3–4 months.
During this period, we will complete the following work:
-
A production-grade chain and client;
-
Improvements to basic tooling;
-
Consistency testing;
-
Documentation.
The following are optional items and should not be treated as commitments:
-
Multi-client coordination;
-
JamScript: JamScript is JavaScript for JAM. The initial design has already been completed.
This will serve as a fast update thread. We will continue to share the latest progress here.