MiniJAM: A Parachain Running a Streamlined JAM

Ecosystem
1

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:

  1. The original JAM consensus process will be replaced by Polkadot parachain security and the MiniJAM worker validation mechanism;

  2. Core JAM mechanisms such as PVM, service, refine, and accumulate will be preserved;

  3. Data availability and D3L will be replaced by the bulletin-chain approach in the early stage;

  4. The accumulate process will be moved into the runtime;

  5. JAM’s assurance, guaranteeing, auditing, and adjudication processes will be replaced by an off-chain Worker mechanism;

  6. 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:

  1. 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.

  2. Transparent migration: Users should not need to care about the underlying migration process as much as possible.

  3. 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:

  1. A production-grade chain and client;

  2. Improvements to basic tooling;

  3. Consistency testing;

  4. Documentation.

The following are optional items and should not be treated as commitments:

  1. Multi-client coordination;

  2. 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.

2

This is a very interesting direction, especially the focus on preserving JAM services, refine and accumulate while allowing applications and tooling to develop before the JAM mainnet is ready.

We are currently building ComputeFlux, an OpenAI-compatible AI gateway designed to connect AI applications and agents with distributed GPU compute, with verifiable execution and TEE-based attestation as part of the longer-term architecture.

We previously deployed an early integration on a Polkadot test environment, but that network has since been sunset. We are now preparing the next stage of the project and have opened our early-user waitlist.

MiniJAM may be highly relevant to us in two ways:

  1. As the coordination and settlement layer for AI inference requests executed by off-chain GPU workers;
  2. As infrastructure for AI-assisted acceptance, where multiple AI models or verifiable workers evaluate contributions, service quality or task completion.

I would be interested to understand the expected application integration model:

  • Will a MiniJAM service be able to initiate requests to external compute or AI worker networks?
  • How will off-chain Workers submit authenticated or verifiable results back to a service?
  • Would TEE attestations or signed inference results be suitable inputs for refine or accumulate?
  • Will the upcoming testnet include documentation, RPC access, a faucet and examples for teams interested in building early applications?

If the architecture is compatible, we would be interested in exploring whether the next ComputeFlux testnet integration could be built on MiniJAM and later migrate toward JAM.

3

Is there a twitter for the miniJAM?

Our founder made a post about miniJAM:

DrCAO | AIWeb3 | ComputeFlux on X: "1/11 Polkadot may have just revealed one of its most important steps toward the JAM era. It's called MiniJAM. The most interesting part of the new MiniJAM proposal isn't MiniJAM itself. It's what it says about the future of AI, developers, and how applications may be built https://t.co/6ogupNhSTY" / X

4

Thank you for the reply. ComputeFlux sounds highly relevant to the direction of MiniJAM, especially around the off-chain GPU workers, verifiable execution, TEE attestation, and AI-assisted acceptance that you mentioned.

Regarding the application integration model, my current understanding is as follows:

  1. A MiniJAM / JAM service itself will not directly initiate outbound network requests.

  2. How off-chain Workers submit results depends on the specific application design.

  3. TEE attestations and signed inference results can both be used as inputs. In essence, this is still done by submitting a transaction.

  4. The upcoming testnet will try to provide the core infrastructure in parallel.

I have created a Matrix room so that we can better understand the ComputeFlux architecture and discuss how MiniJAM could support your testnet integration:

Separately, we have also been exploring AI-related applications for some time. More recently, however, we found that infrastructure, launch mechanisms, and real user adoption may be more urgent problems at this stage. Therefore, through MiniJAM, we are shifting our focus toward lower-level coordination and execution infrastructure.

Recently, we also carried out some small-scale experiments. We performed preliminary post-training on a 3B model. The base model already had fairly strong mathematical capability. Inspired by the LoopLLM idea, we first introduced a higher-level loop and were able to recover around 50% of previously wrong answers. We then reproduced a similar effect at the token-level loop.

This is still a very early and small-scale experiment, but it suggests that small models may still contain reasoning capacity that has not yet been fully unlocked. It also makes us think that directions such as explicit MoE, verifier-guided execution, multi-model acceptance, and AI-assisted validation may be approaching a point where they can be explored as practical engineering systems.

Here is our note:

We would be very happy to discuss this direction further.

Thank you for the excellent Twitter thread. Our team account on Twitter / X is:

At the moment, we do not yet operate a separate MiniJAM project account. MiniJAM-related updates will first be shared through the ArcheLabs account.

5

Hello @libingjiang47,

Interesting project! Does it mean your system will offer transactionlessness as a property?

6

Yes. In this respect, MiniJAM is no different from JAM.

7

Thank you for the detailed explanation. This is extremely helpful and aligns closely with how we’ve been thinking about ComputeFlux.

We completely agree that MiniJAM services themselves should remain deterministic and avoid making outbound network requests. From our perspective, ComputeFlux naturally fits into the off-chain execution layer, where GPU workers perform inference, generate TEE attestations or other verifiable proofs, and submit signed results back on-chain for verification.

What excites us even more is your comment that “how off-chain workers submit results depends on the application design.” We see this as an opportunity for the ecosystem to define reusable standards rather than isolated integrations. Instead of simply connecting ComputeFlux to MiniJAM, we’d love to explore common interfaces for AI job specification, worker execution, TEE attestation, verifier outputs, and acceptance workflows so that different AI providers and worker networks can interoperate.

We also found your LoopLLM experiments very interesting. We believe the future is not just about larger models, but about better execution pipelines: verifier-guided inference, multi-model acceptance, iterative reasoning, and confidence-aware execution. These ideas align well with our long-term vision of ComputeFlux as a verifiable AI execution layer rather than simply an AI API gateway.

We’d be happy to continue the discussion in the Matrix room. We believe MiniJAM’s execution model and ComputeFlux’s decentralized AI infrastructure complement each other very well, and together could provide a practical foundation for verifiable AI services on Polkadot.

8

MiniJAM Stage 0 Testnet is now live and is expected to run for around 12 days.

The primary goal of this stage is to collect operational data and prepare for the next phase: the full testnet. We have now implemented nearly the complete end-to-end JAM workflow on a parachain, and expect to need another three to four weeks to reach the full testnet stage.

At the moment, you can:

  1. Write services in C/C++ directly in your browser, compile them, deploy them to the network, and interact with them:
    https://playground.minijam.xyz/
  2. Compile services locally and deploy them to the network through the API:
    Playground API | MiniJAM Documentation

More resources:

Official website:

Documentation:

As mentioned previously, we will also launch the economic system soon. The incentive protocol design is now largely complete, and an initial version of the contract library has been implemented.

9

LIVE: https://genesis.minijam.xyz/