Ensuring JAM Development Sustainability: Is It Time for a Dedicated JAM Bounty Program?

[danicuki]

Introduction

The JAM initiative represents one of the most ambitious undertakings in the Polkadot ecosystem. Many independent teams have invested over a year of work into implementing clients, tooling, and research based on the evolving Graypaper. However, recent economic and structural changes raise real concerns about the sustainability and continuity of this effort.

This post aims to open an ecosystem-wide discussion on whether Polkadot should introduce a dedicated JAM funding scheme (e.g., a JAM Bounty or JAM Working Group) to support ongoing development outside the narrow boundaries of the JAM Prize.

1. Economic Context Shifted Dramatically

The intention here is not to debate market prices — they fluctuate — but to acknowledge that funding mechanisms designed under one set of assumptions may no longer match the reality teams are operating in.

When the JAM Prize was announced:

• DOT was ~$5

• A milestone payment of 100k DOT ≈ $500k

Today:

• DOT is ~$2

• The same milestone now represents ~$200k

This means prize funding has effectively shrunk by 60%, while expectations and required work have not changed. For full-time teams, this massively increases the risk profile of participating in JAM. To put this into perspective: the current ~$200k equivalent per milestone does not even cover the cost of two senior blockchain engineers working full-time for 18–20 months. Many teams have already exceeded this level of effort, effectively self-funding substantial development time with no guaranteed payout.

2. Timelines Have Drifted – Increasing the Burden on Teams

Several expectations set early in the process have not materialized:

2.1 JAM Prize Submissions (M1)

• Initial ecosystem discussions suggested a rough timeline of around one year for early M1 progress, but the evolving complexity of the protocol and lack of a formal submission guidance means teams cannot confidently plan long-term development,

• Many teams have now been building for 20 months,

• Yet no M1 submission process or timeline has been announced.

This lack of clarity makes coordinated progress difficult across dozens of independent teams and may unintentionally disincentivize long-term investment into JAM.

2.2 Graypaper Stability

• Current Graypaper is v0.7.2, nearing v1.0 but progressing slower than initially expected.

• Every change requires teams to refactor large parts of their implementation.

• This adds recurring engineering overhead that teams must continuously absorb as the protocol evolves.

3. The Actual Number of Actively Conformant Teams Is Smaller Than Expected

This is not a criticism of teams — it is a reflection of the reality that without predictable support, fewer teams can justify maintaining full conformance.

Of the 43 “self-announced” JAM teams listed on graypaper.com:

• Only 10 are conformant with GP v0.7.2

• Another 4 are still on v0.7.1

• Total actively updated & conformant teams: 14

Source: https://github.com/davxy/jam-conformance/tree/main/fuzz-reports

This suggests the ecosystem is already experiencing dropout, which is expected when teams must choose between unpaid JAM work and paid work elsewhere.

4. The Chicken-and-Egg Problem of Funding

Teams need long-term funding to:

• Work full-time on their clients

• Build tooling (SDKs, profilers, debuggers, fuzzing frameworks, networking tools)

• Reach M1 and beyond

• Support future JAM services developers

However:

• Without M1-ready clients, no funding is flowing.

• Without predictable support mechanisms, only a small subset of teams can justify allocating full-time resources to JAM for long periods. This slows collective progress toward M1.

This circular dependency threatens the entire decentralization and multi-implementation vision of JAM.

Parity alone cannot—and should not—be the only team able to sustain full-time JAM development.

5. Downstream Ecosystem Impact

This is about enabling the broader developer ecosystem — not just protocol implementers — to build confidently on JAM.

The Polkadot Blockchain Academy (PBA) announced a JAM-focused course for March 2026.
They planned:

• A mature JAM testnet

• A stable JAM SDK

• Fully working clients

• Hands-on materials for JAM service developers

If independent client teams cannot sustain their work, the entire downstream developer ecosystem (courses, tooling, service builders) risks stalling.

6. Proposal for Discussion: A JAM Bounty Program

To break the deadlock, we could consider creating a JAM Bounty (or JAM Working Group) funded via OpenGov, with the following goals:

6.1 Funding Scope

Support areas not covered by the JAM Prize, such as:

• Tooling (profilers, fuzzers, analyzers, test harnesses)

• Developer experience (SDKs, libraries, templates)

• Documentation, education, course material

• Reference implementations of key JAM components

• Testing infrastructure (clusters, CI systems, conformance tooling)

• Research into performance, networking, and security

6.2 Governance Model

A small technical committee (e.g., 5–7 members):

• Selected by OpenGov or via a transparent application process

• Responsible for reviewing proposals and allocating micro-grants/bounties

• Reporting periodic outcomes to the community

6.3 Funding Amount

Enough DOT to:

• Support multiple teams simultaneously

• Provide predictable multi-month development runway

• Reduce dropout risk

The exact amount should be calibrated during this community discussion.

7. Key Questions for the Community

1. Should Polkadot create a long-term funding mechanism dedicated to JAM development?

2. Is a JAM Bounty the right structure, or should we explore something like a JAM Fellowship or Working Group?

3. How do we preserve decentralization and avoid a future where only Parity has a fully functioning JAM client?

4. What level of DOT funding is appropriate given the current market conditions?

5. How can we better align incentives between prize timelines, Graypaper evolution, and team sustainability?

8. We Cannot Ignore Market Momentum

This is not about rushing JAM — correctness is paramount — but about ensuring that the teams building it have enough runway to maintain momentum while competitors continue shipping.

While we’ve been building JAM for 20 months, the broader blockchain ecosystem has not stood still. Competing platforms continue to:

• Ship new developer environments

• Launch scalable execution layers

• Improve smart contract tooling

• Attract capital and talent through aggressive funding programs

Polkadot’s technology is exceptional—arguably best-in-class for deterministic distributed compute. But technology alone is not enough.

In fast-moving markets, time-to-market becomes a competitive moat.

If JAM takes too long to reach a production-ready state, we risk:

• Losing mindshare to ecosystems that move faster

• Losing developers who need real environments to build on today

• Losing investors and partners who follow visible momentum

• Becoming technologically “correct” but strategically irrelevant

This is not a theoretical risk. The history of technology is full of examples where the best architecture did not win—because it shipped too late.

A modest acceleration now, through targeted funding of critical teams, could mean the difference between:

• JAM launching into a strong, growing market, versus

• JAM launching into a future where competitors already captured the narrative and developer base.

Polkadot is at an inflection point. The ecosystem has a brief window to transform JAM from an experimental initiative into a real, live system with developer adoption. The market momentum is real, and we should not underestimate its impact.

A dedicated JAM funding scheme would not just help teams survive—it would help Polkadot win.

Conclusion

This discussion is not about any individual team’s needs — it is about ensuring Polkadot maintains a diverse, resilient, and competitive JAM ecosystem.

JAM is a once-in-a-generation opportunity to redefine decentralized compute.
But without sustainable funding, we risk losing teams, momentum, and the multi-client resilience that has always been a core value of Polkadot.

This post is not a complaint—it’s an attempt to spark constructive discussion on how we can support JAM builders today so that the ecosystem can thrive tomorrow.

I welcome feedback, alternative ideas, criticism, and of course: collaboration.

[xiscocv]

@danicuki I understand your concern about paying Jam developers—I’ve even made a thread about this a few weeks ago, pointing out how the price of DOT directly affects Jam’s development. But I think we’re falling into the same mistake Polkadot has been making for the last four years: assuming that selling DOT or creating reserves will somehow make payments more stable for contributors.

We keep relying on selling DOT because the price keeps dropping, instead of fixing the tokenomics so that the price stops falling, goes up, and developers can be paid without any issues.

The real question is: why are we waiting until March to reduce staking rewards? We already saw what happened during the recent migration, when a staking error caused validator rewards to drop to 30%—the price went up 25% in a single day.

And on top of all this, we urgently need the release smart contracts. Polkadot needs real, tangible utility right now, . Without smart contracts running we don’t have nothing. The community has been waiting far too long, and Parity needs to accelerate this—because real usage is what will ultimately support DOT’s value and long-term sustainability.

We need to focus on removing sell pressure from the token. Honestly, Dani, the idea of creating reserves or selling even more DOT will only make the token so worthless that, after Jam, there won’t be a single euro left to pay future developers.

It feels like the people currently getting paid by Polkadot live inside a bubble—because they’re earning salaries, it doesn’t seem to matter to them that the token is dying. It’s incredible that a project with so much talent is at risk of collapsing due to overspending and the unwillingness to make urgent tokenomics changes.

But Dani, ordinary community members have been saying this for months—in forums, on Twitter—and no one listens. It’s unbelievable that a decentralized project could fail because of wasteful spending and a lack of decisive action.

And this message is directed at PARITY:
Act now. Take the bull by the horns and revive the protocol. There are millions of euros from investors who trusted you, and thousands of developers who have invested their time and risked their future on Polkadot. Value them. Protect them.

This is not an attack on you, Dani—you, as a developer, have done an incredible job. But we need to fix the problem at its root.

[danicuki]

Thanks for sharing your perspective — I think many people in the ecosystem share concerns about DOT tokenomics, staking parameters, release timing for smart contracts, and broader market perception. These are all valid strategic discussions, and they definitely deserve their own focused debates.

At the same time, the intention of my post is a bit different:
I’m trying to look specifically at the operational reality of JAM development across multiple independent teams.

Regardless of:

• DOT price

• staking reward schedules

• tokenomics changes

• migration incidents

• upcoming features like smart contracts

…the fact remains that JAM development is a multi-year, multi-team effort, and we need to make sure it remains:

• decentralized

• sustainable

• predictable

• attractive for contributors

Even in a perfect tokenomics environment, we would still need clarity around:

• M1 submission timelines

• long-term support structures

• tooling and SDK funding

• coordination across dozens of teams

So while tokenomics is an important layer to address (and I fully support more discussion on that topic), my goal here is simply to focus the conversation on what JAM needs to succeed as an ecosystem, independently of price dynamics.

If the community later decides changes to tokenomics can reinforce this effort, that’s great — but it doesn’t remove the need for a structured approach to JAM development funding.

Thanks again for the thoughtful contribution. These discussions complement each other, and I’m glad we’re having them openly.

[xlc]

The core fellowship will be the JAM fellowship. According to JAM prize rule, after M1 submission, people can be fast tracked to rank 3 fellowship member and receive a stable salary. This is not going to solve the problem but should help a bit.

I don’t think we need another bounty committee. We could just utilize the fellowship treasury, which is governed by fellowship members.

Maybe we should start making some JAM related RFPs? GitHub - polkadot-fellows/RFPs: Request for Proposals administered by the Fellowship.

Another thing we could do is induct JAM devs into fellowship (via usual path). In that way JAM devs can get familiar with fellowship (as a candidate or rank 1 member) before they get promoted after milestone acceptance.

As a rank 4 member in fellowship, I am happy to induct JAM client devs as candidate and help with rank 1 promotion. Let me know if you are interested.

[clearloop]

All of us want JAM get succeed

1. Two main issues: Funding and Marketing

1.1. Lack of fundings - w3f

JAM prize is organized by w3f, while DOT price shrunk significantly, as the foundation, w3f need to introduce the proper solution, and need to take actions for making sure devs can at least make lives ASAP

DOT’s risk is JAM’s risk, cross leverage

1.2. Lack of marketing support - polkadot mkt & teams got grant for this

I’m not a marketing guy, but I’m sure the purpose of marketing is making the pie bigger (solana can work with base even zcash, polkadot plays lonely all of the time) but not getting high in our own ecosystem repeatedly, for the expected results of the marketing work, implementors should be easier to promote their work, get tractions on social media, get funded by outside capital & VCs

2. The JAM community & governance & bounty

IMO the problem here is actually the sum of 1.

1. OpenGov or W3F should not be the single funding source of JAM development as we can see the risk in the DOT tokenomics, we need funds from the outside (who cares about their investment and will provide help to push JAM), teams who declared they will work on BD & marketing stuffs related to JAM and got the grants need to take the responsibilities of this, from the results we may need to shut down some of the supports / doing blacklisting immediately, and as said there will be new governance for JAM, which will manage the funds, and JAM governance should not being like opengov
2. if there is no obvious team working on this, we need to build the team, setting up connections between BD & Marketing with JAM implementors directly, make things running in parallel while implementors are waiting for W3F to review the implementations, to make things efficient (except gav, I believe JAM implementors (including the polkajam team) are the ones who care about the success of JAM most, not just because of the prize but also because we have spent really a lot of time on it, we want our work being meaningful.)
3. We need a leader for this, discussions or votes won’t work, gav or guys from parity/w3f, someone would take the responsibility, if things not work, it’s his/her fault but not opengov’s, the impact of the implementors are very limited since we neither wrote the graypaper nor running the polkadot ecosystem

3. NOTEs

3.1. The tokenomics need to be solved but it can not be solved by JAM development / developers, as a pressure test on 10/10, DOT drops to $0.6 on binance, which means building the entire new chain with mb the most complex tech in the world (taking years), could not touch even 1/3 of a simple wallet integration grant from opengov (could be done in weeks)

3.2. Besides the risk of payments, while developing JAM, we don’t have any marketing support, I built the implementation with almost the best performance, except other JAM devs, I hardly can share my happiness and finally lost the passion to make my implementation more advanced, I built a ready-to-hack open source rust sdk with everything needed (even wrapped a VM ABI), still hardly can get tractions after spending days on twitter, mb I’m stupid on marketing, while nobody from the ecosystem come and help as well, contributors asking me when to get online, if there are futures joining my work, I have nothing to promise but just repeating we need to wait

[prasad]

Thank you for raising this; it’s something many teams are feeling as we’ve been concerned about sustainability. We started with a large team and beyond node client work (M1, M2 & M3), we’ve even built SDKs in C, C++, and Python, an IDE playground, testnet tooling, and an explorer. After ~18 months of self-funded development with no M1 delivery in sight (many now estimating mid-2026), we’ve seen several teams drop off and have had to cut our own resources significantly. JAM Prize has attracted some of the most talented teams in web3 to work on JAM; however long timelines and uncertainty around milestones make it hard to sustain long-term development for any team, and even tooling, services, and ecosystem infra that extends beyond client milestones which many teams are interested in

[dandan]

Polkadot’s core problem is pouring massive money into things before anyone even knows if they’re actually viable.

1. Already-failed parachains (tons of slot auctions ended up as ghost chains or straight-up dead projects)

2. OpenGov that’s completely ineffective in practice (endless spam proposals, treasury bleeding out with zero real governance improvement)

3. PoP (Proof of Personhood) has been tried and failed on multiple chains already, yet they’re about to throw huge bounties at it without even a working PoC

4. JAM’s (Join-Accumulate Machine) whose design keeps changing every few months, but they’re already burning insane amounts of manpower on tooling and surrounding infrastructure

Keep wasting money and enjoy the death spiral

[alice_und_bob]

I don’t think the Treasury should be paying for a dozen or more clients, when eventually we will see 3-5 competing clients.

Yes, it might be argued to have a R&D budget, but that should come from a position of "How much is JAM client diversity worth to the Treasury? (in addition to what the JAM prize already offers).

And it is worth whatever is neccessary to keep enough nodes online to keep the chain running in case a client fails. I would assume that the most dominant clients will be dependent on high performance, so if such a program is devised, I would only make the 3-5 first clients that reach the performance milestones to be eligible.

Last note: The JAM prize was offered in DOT, not USD, so anyone engaging in the competition should be aware of the risk. Risk and Reward go hand in hand. It could equally be argued that the JAM prize pool should be raised.

[radha]

Thanks for sharing your thoughts on JAM development sustainability @danicuki.

On behalf of Web3 Foundation, I am tasked with JAM conformance testing for over a month now and am bootstrapping a team to get started with evaluating the M1 submissions GitHub - w3f/jam-milestone-delivery

Regarding the valid concerns regarding the funding and timelines, I will discuss them with Web3 Foundation leadership and get back here.

[danicuki]

Thanks for your comment — this is a very helpful perspective, and I fully agree that the Fellowship will play a central role in the long-term stewardship of JAM.

That said, the sustainability gap I’m trying to highlight is a bit different from what the Fellowship or the Prize currently address.

1. The JAM Prize already covers node/client development

I don’t think additional funding is needed there — the incentive structure is already defined, and teams accepted it.

2. The unfunded areas are SDKs, services, tooling, infra, and ecosystem growth

Right now there are 0% incentives for:

• JAM SDKs

• JAM service frameworks

• standard libraries

• dev tools (profilers, debuggers, conformance infra)

• example services / reference apps

• developer onboarding

• documentation

• marketing, events, DevRel

• education & content

• ecosystem bootstrapping

Without these layers, even a perfect JAM protocol will not achieve adoption.
A blockchain without at least one compelling use case or reference implementation simply doesn’t gain traction.

3. Fellowship doesn’t realistically cover whole teams

Even after M1:

• Only one team member can be fast-tracked to Rank 3.

• Other team members have to follow the regular path, which typically takes years.

• As far as I am aware, fellowship stipends are designed for protocol maintenance — not for multi-person teams building tooling or services.

So Fellowship is extremely valuable, but not a practical sustainability path for full teams working on ecosystem components.

A related structural challenge is that Fellowship members and Parity engineers have predictable, inflation-backed funding, which makes long-term, multi-year commitments feasible. Independent teams, on the other hand, operate without that stability and therefore carry significantly higher risk when contributing to something as large and evolving as JAM. If we want JAM to remain decentralized and supported by multiple independent teams, we need mechanisms that allow more than just the already-funded groups to participate sustainably.

4. Fellowship’s mandate is protocol correctness, not ecosystem growth

The Fellowship focuses on:

• protocol design & maintenance

• core implementations

• runtime and system logic

But not on the items I mentioned before (developer experience, SDKs, tooling, onboarding, community growth, real-world adoption, education, etc)

I think those pieces are essential if JAM is to succeed after launch.

5. So the conversation is not “pre-M1 vs post-M1”

It’s:

“Protocol implementation” vs “Ecosystem readiness and adoption.”

The Prize (seems to) cover the first.
The Fellowship partially supports protocol contributors.
But the ecosystem layer has no support structure at all, and is equally important for JAM’s real-world success.

I really appreciate your openness to induct JAM contributors into the Fellowship — that’s a great initiative. My argument is simply that we also need a mechanism to incentivize the ecosystem components that fall outside the Prize and outside the Fellowship’s current mandate.

Thanks again for engaging in this discussion — aligning these pieces will be crucial for the success of JAM as a whole. And please feel free to correct me if any of my assumptions about the Fellowship structure or incentive mechanisms are inaccurate — I’m raising these points so we can better understand how all the pieces fit together.

[danicuki]

Thanks for the thoughtful points — and I agree that the Treasury shouldn’t fund a dozen clients. The JAM Prize already covers node implementations, and in the long run we probably only need half a dozen strong ones anyway.

What I’m trying to highlight is something different:
the ecosystem layer around JAM (SDKs, tooling, services, docs, onboarding) currently has zero incentives.

Even with great clients, JAM won’t get real adoption without these pieces.
So the discussion I’m raising isn’t about increasing client funding — it’s about ensuring the rest of the stack can actually be built.

This also creates a path for teams already deeply familiar with JAM internals to contribute beyond node implementations — for example by building SDKs, tooling, or services, which is where the ecosystem really needs support now.

Would love to hear your thoughts on that part.

[danicuki]

@radha

Thanks for sharing your thoughts on JAM development sustainability @danicuki.

On behalf of Web3 Foundation, I am tasked with JAM conformance testing for over a month now and am bootstrapping a team to get started with evaluating the M1 submissions GitHub - w3f/jam-milestone-delivery

Regarding the valid concerns regarding the funding and timelines, I will discuss them with Web3 Foundation leadership and get back here.

Thanks, @radha — really appreciate the update.
Good to know the conformance testing effort is already moving and that a team is forming for M1 evaluation.

Even a rough idea of how the submission/review flow will look would help teams plan their work better, but no rush — just happy to hear this is in progress.

Let me know if there’s anything I can help with.

[radha]

Thank you very much for offering support. @PieWol from W3F will reach out to you to discuss this and share the progress on conformance testing effort.

[eldaniklk]

@danicuki Hi Dani. You’re absolutely right that JAM needs much better organization. There must be a consensus among 4–5 people, or a dedicated team inside Parity, that coordinates developers efficiently. It’s enough to look at the fact that an entire year has passed and milestone 1 is still not completed; meanwhile, developers haven’t been paid a single euro after 12 months of work. On top of that, there’s constant uncertainty and the drop in DOT’s price, which reduces the real value of their compensation.

As you said, speed is essential right now. That’s why I believe the most effective path is for Parity to take responsibility for organizing the teams and giving them stability. Without clear direction and continuous support, it’s very difficult for the project to progress at the pace it needs.

The point that xiscocv mentioned is also crucial, and I raised it myself a few weeks ago (link medium). We must take care of the JAM developers. Even if they complete milestone 1, if they end up exhausted and demotivated, it will be extremely hard for new engineers to take on milestone 2 without having gone through the whole process, the problems, and the challenges of the first milestone. There is acquired knowledge that cannot be easily replaced.

This is why it is essential to keep our current developers: they might be moving slower now, but they are learning, consolidating the system, and building the foundations of JAM’s future. Parity, please support them and guide them. This is why you’re behind the development as a private company: to provide structure, support, and direction at crucial moments.

[haiko]

This is just the ancient problem of funding OSS work. It’s slightly different because there is this inherent economic component, but not substantially. The JAM Prize is a fun idea, but ultimately just a convoluted form of spec work. Implementing JAM is, and always has been, a hobby for rich people.

We need to be honest with ourselves about this, most of all the incredibly skilled hackers who quit their jobs and are burning through savings to work on JAM. I don’t want to be too doom and gloom, but there’s lots of instability in the world and entirely too much talk about a looming global economic crisis. Just sayin’…

[PieWol]

Thanks @danicuki for discussing current issues of JAM teams with me directly.

We at the Web3 Foundation are pleased to announce that we will begin processing Milestone 1 deliveries for the JAM Prize starting January 2026.

We now have access to the necessary tooling (including the fuzzer) to test client conformance. With Gavin confirming that milestones may be accepted based on conformance to graypaper v0.7.2, we are ready to begin evaluations.

Teams are invited to submit their Milestone 1 delivery via the following repository:
https://github.com/w3f/jam-milestone-delivery

We will evaluate all clients that conform to the most recent graypaper version. Meaning graypaper v0.7.2 or later.

Further details about the evaluation process will be communicated at a later stage. This will include, among other things, the required number of block imports a client must be able to process without error in order to be eligible for Milestone 1 payment.

We’re looking forward to reviewing your submissions and taking another important step toward greater client diversity for JAM.

[HopeClary]

This is a very thoughtful post and clearly shows me that outside of the Gray Paper we all read there is a need for Business Onboarding and Implementation Processes! Outside of the SDK and other Infrastructure items, you defined DevRel, BD and Marketing. DevRel to me is Implementation Onboarding documentation and support, this occurs after BD/Sales where there is technical guidance for businesses to adopt the protocol and become one through software connections. Speaking from experience, I understand how difficult this task can be for some businesses and their certification teams. These are hurtles for adopting businesses and they will evaluate the costs of onboarding.

I appreciate this post so things outside of the design scope can be reviewed and planned accordingly, as many of us are looking forward to JAM protocols.

[tomusdrw]

While it’s super good to see Milestone 1 submissions acceptance starting and the prize becomes more tangible for all of the teams that participated in the fuzzing rounds, I feel it would be good to clarify a few things that go beyond M1 before paying out anything to maximize the outcomes.

1. What are the expectations for the rank 3 fellows that are newly appointed from all of the JAM teams?
2. What methodology will be used for M2 compliance?
3. What exactly is M3 & M4 about?
4. What’s the exact goal of the JAM Prize contest?

Below please find a mix of clarifications and my personal views on these matters. My goal is to provide some context for the above questions and why I think it would be best to plan that upfront instead of simply focusing on paying out the M1 prizes.

Ad 1. Given we can expect around 10 new rank 3 members (with a potential salary of $6667 each) I think it would be good to clarify what their role is supposed to be in the fellowship. The manifesto didn’t see any updates for 3y afaict, and it only mentions Polkadot-specific activities that may not clearly translate into JAM-related ones. Also given that the implementation cost is supposed to be covered by the JAM prize, I think the expectations of the new fellows should be a bit higher than giving a monthly status update and occasionally speaking at conferences or writing couple of blog posts. Not sure what that should be yet, but for instance taking care of writing JIPs, helping with milestone conformance tooling and process sounds like a natural fit. Whatever that is, I think it might be good to at least softly formalize that on top of the polkadot-generic manifesto.

Ad 2. It was mentioned that there isn’t going to as much hand-holding as with M1, but it seems to me that the complexity and edge cases of M2 are at least one order of magnitude greater than M1 (there isn’t a simple state root to compare that all networking works fine) and it would be great to either see a viable testing roadmap or a clear indication that this is outsourced to the JAM teams so that we can start working on one. I really hope the work expectations and testing plans on future milestones can be clarified upfront to avoid the current (arguably slow) waterfall model.

Ad 3. IMHO there is a great amount of complexity hidden in M2, however M3 seems trivial compared to that. Since the performance requirement is implicit in other milestones anyway, some of the teams already implemented their recompilers, it seems that M3 and M4 will not involve much of work. Am I missing something? Perhaps given that we have a better understanding of the protocol and the coordination & testing process it’s best to split these milestones differently (for instance move full networking compliance and auditing further down the line, or specify smaller component-level acceptance criteria with fuzz-like protocol interface for testing, e.g. for grandpa, auditing, refinement, etc).

Ad 4. One would expect that the incentives should be aligned around having multiple, up-to-date, fully functional implementations of JAM that are ready to support the network launch and a bunch of services that would be launched alongside. However, as of my read of the rules, there isn’t that much incentive to support that. We might see teams drop-off right after M1 (or any other milestone) or we might simply see multiple more M1 implementations for whatever version of the protocol the submissions open. Given it’s also possible to just do KYB we might even see submissions for M1 from the same ppl (hidden under different nicknames) under a different business entities and in different language sets. Even if the existing teams would be willing to take it all the way down to M5, there have been voices that so many independent implementations are not really needed and we will end up with 2-3 (or maybe just 1?) at the end. It seems to me that the goal of the contest is not really well defined and the incentives are not fully aligned to keep the implementations (or the developers) running in the ecosystem. I think it would be good to clarify if that’s the intention and if not, perhaps rethinking if that money can’t be spent in any better way that would support the issues outlined in this thread.

[danicuki]

Stunning comments and questions. Thanks for bringing this!

[danicuki]

I thank you @PieWol and the Web3 Foundation team for the prompt reply. We are happy to move on with these next steps for JAM Prize. It would be amazing if, at some point, you could also answer @tomusdrw questions: they are as relevant as the prize to the JAM success.