Accelerating the Polkadot/JAM Ecosystem with the MiniJAM Incentive Protocol

Ecosystem
1

MiniJAM is a distinct community-driven project. JAM will create many new forms of applications, while also requiring a large amount of new infrastructure. We therefore want to use MINI as an incentive resource that can be continuously invested back into the ecosystem.

Even on the forum alone, the community launches new products almost every week. Many of them are valuable tools, applications, and infrastructure projects, yet they often struggle to reach a real market. This cannot simply be explained as “the market does not need them.”

For Web3 products, product discovery itself carries a cost. Users need to spend time understanding a project, trying the product, and accepting the risks of using something at an early stage. The more mature the infrastructure and the larger the user base, the lower this friction becomes. Otherwise, active incentives are needed to help products be discovered, used, and shared.

Treasury and committee funding played an important role in the early growth of the ecosystem, but they also have clear limitations.

First, these decisions are usually binary. A project either receives support or it does not. This makes it difficult to express the different preferences and levels of support held by different groups.

A more important issue is that projects initially face a small group of reviewers and governance participants rather than the market itself. A grant may help a project get started, but it cannot continuously answer a more important question: do users still need it?

1. The Incentive Market

Over the past period, we have extensively tested a range of incentive products across different ecosystems. They have given us many useful ideas.

Based on those experiences, we abstracted a general-purpose incentive protocol. It allows projects to face the market directly and receive a continuous stream of incentive resources based on their ongoing market performance.

Every project can establish its own market. Users express their judgment by trading, holding, and staking, while the protocol continuously distributes MINI according to these market signals.

A project’s incentives are therefore no longer determined by a single decision. They adjust continuously as its market performance changes.

2. Core Concepts

  • Alpha: Every project has its own Alpha. It is used to establish liquidity, participate in staking, and receive the incentives allocated to the project.

  • Project Market: A project creates an independent Alpha/MINI liquidity pool. User trading and holding activity produces continuously changing price and liquidity signals.

  • Staking Vault: Users can deposit Alpha into a project’s Staking Vault. By giving up some liquidity and taking on project risk, stakers express longer-term support.

  • Emissions: The protocol releases a fixed amount of MINI in each period and allocates it according to the market performance of each project. Part of the allocated MINI enters the liquidity pool together with newly issued Alpha, while the remaining emissions are distributed to stakers and builders.

  • Owner Share: Owner Share defines the portion of Alpha emissions allocated to the project’s builders, allowing them to receive continuing incentives as the project develops.

3. Sub-Protocols

The main protocol is intentionally simple. It does not care where the initial liquidity comes from, nor does it determine how Alpha should ultimately be distributed. Once a project has established an Alpha/MINI market, the main protocol allocates emissions according to its market performance.

The main protocol may not even need its own frontend. In practice, it does not directly serve users or projects.

Different projects require different launch and incentive mechanisms. Some may be better suited to crowdfunding, while others may use auctions. Some may want to reward early users, while others may release incentives according to product usage or development progress. A sub-protocol may also provide additional services, such as stricter project audits.

This allows the incentive protocol to serve different market needs.

A sub-protocol mainly controls three areas:

  • Initial Distribution: How Alpha is distributed among users, liquidity, and builders.

  • Ongoing Emissions: How the project uses its allocated emissions and under what conditions they are released.

  • Owner Share: How much is allocated to builders and how those allocations are unlocked.

By controlling these three areas, a sub-protocol can define a complete project mechanism, including how users enter, how the project raises funds, what happens if the launch fails, and under what conditions users and builders receive rewards.

For example, Workers could provide computation, data, or other services. AI could perform an initial evaluation, while validators review the results. The sub-protocol could then distribute the project’s Alpha emissions among Workers, validators, and builders according to those results. In this way, it would be possible to create a sub-protocol similar to a Bittensor subnet.

In return, a sub-protocol can receive the majority of the liquidity fees generated by its related markets. The sub-protocol is the actual user-facing layer.

4. Public Goods

Most public goods are not suitable for issuing their own Alpha. The protocol therefore reserves a separate portion of emissions for them.

When staking Alpha, users receive corresponding voting weight, which they can use to support different public goods. The incentive protocol then distributes the MINI reserved for public goods according to these votes.

5. Current Progress

The core contracts for the first phase have been completed. Once the MINI liquidity pool has been successfully established, the incentive market will officially launch.