Continuing from yesterday's article, PolkaWorld today continues to bring you explanations from the JAM implementation team regarding JAM and shares about the current development status!
Whether you are a developer wanting to join JAM or an ordinary user optimistic about JAM's future development, this article is worth reading and learning!
This content is lengthy; PolkaWorld will publish it in two parts. This is the second part, mainly covering the following content:
Is the core application scenario of JAM to serve as national-level infrastructure?
How to join JAM development?
- How to join JAM development?
What is the goal of JAM DAO?
Is JAM unable to retain data? Will it disappear after 24 hours?
There is nothing that cannot be done on Polkadot; it’s just that some things are easier and more efficient on JAM.
Why is the governance of Polkadot moving to Asset Hub instead of running directly on JAM?
What impact does JAM have on the entire blockchain market?
How many stages is the development of the JAM protocol divided into?
Will so many JAM clients ultimately be put to use?
What features or tools do developers expect in the JAM ecosystem?
How does JAM enhance the user experience of Polkadot in the future?
Continue reading to see the full content!
Previous article (Is JAM the only way to build a truly Web3? Listen to what these builders have to say)
Is the core application scenario of JAM to serve as national-level infrastructure?
Q1: Regarding the claim that Polkadot is ahead of other blockchains in terms of decentralization, do you think governments, institutions, and large companies are really ready to be completely decentralized? Or are they more inclined to choose chains like Ethereum, which have centralized control points, for regulatory or censorship purposes?
Daniel: Let me answer this. I firmly believe that the core application scenario of JAM is to serve as national-level infrastructure. Just think about it, there are only a few countries in the world that have complete autonomy over their technological infrastructure. The vast majority of countries actually rely on centralized cloud service providers like Google and Amazon. For example, I am Brazilian, and Brazil has a population of 200 million, but even with such a large population base, Brazil cannot keep up with the infrastructure levels of Amazon and Google. In the end, most countries can only rely on large companies from the U.S. or China.
But if these countries can build their own infrastructure based on blockchain and systems like JAM, they can truly achieve technological sovereignty, without needing to trust a particular country or large company. So I believe that Polkadot and JAM are the only ways for countries to achieve technological autonomy. If they trust Ethereum, they are essentially trusting two major centralized nodes hosted in the U.S., which cannot be called sovereignty. Only Polkadot and JAM can provide these countries with true sovereignty, which is why I value them so highly.
How to join JAM development?
Q2: Hello, most projects are not very open at the moment, and many details are not transparent. Suppose I just completed a two-and-a-half-week intensive training course where I learned a lot about Rust and other knowledge, and now I want to find opportunities to participate in your project. How should I contact your team?
Maciej: I have some suggestions. First, you can check out the gray paper page. Read through the gray paper; you don't have to understand it 100%, just browse it for an overview. Then on the gray paper page, there is a ‘list of implementation teams’ that lists various teams involved in the implementation; about 40-50% of the teams have left contact information (like Telegram accounts or email addresses). You can search for them by name on Google or directly message them to get in touch. If you want to join an existing team directly, this is a recommended path. Of course, you can also find classmates or friends to form a new team, which is also a good choice.
Tomek: Yes, another way is to join the Element group (a decentralized chat platform). There are links to Element groups on the gray paper website, mainly two groups: one is for gray paper discussion, and the other is the main JAM group. You can send a message in the group, introduce yourself, and say you want to join the project. Many JAM developers are in there, and some even have their own smaller team groups that will invite you in. Each team may have a different path, but this way you can find opportunities that suit you.
Daniel: Yes, currently there are about 35 teams working on it. Some teams may temporarily not accept new members, but there are also many teams that are open. I suggest you reach out to several teams and see which one suits you. If there really isn't a suitable one, you can completely form your own team and push forward together.
How will the governance system of JAM evolve in the future?
This content is long, PolkaWorld will be published in two parts. This article is the second part, mainly covering the following contents:
Maciej: This question is indeed difficult to answer because it essentially asks how the governance system of JAM will evolve in the future. As of now, the current vision is:
1. DOT holders will participate in JAM governance through existing OpenGov, but the authority may be narrowed, and they will not vote directly on runtime upgrades of the Relay Chain as before—because the JAM chain itself is non-upgradable (only supports hard forks);
2. The importance of the technical alliance (Fellowship) will increase, as most of its members will come from JAM implementation teams and possess expertise in protocol iteration.
3. The developing JAM SDK and contributors involved in development can also quickly join Fellowship through a certain mechanism, forming a technical expert DAO that helps manage the future of the protocol. However, this is just my personal understanding; others may have different views.
Alistair: Yes, there is indeed still no definitive answer. The governance model will certainly evolve, and the Fellowship will become more important. In the future, it may resemble a multi-client (multi-implementation) ecosystem like Ethereum, but we hope to achieve this faster than Ethereum, without waiting five years to finalize a feature. However, how to do this is still a difficult question.
Daniel: But you look at the reality; while we don’t know exactly how things will work in the future, at least compared to other chains, we have OpenGov to work with. Other chains, like Ethereum, have almost no real on-chain governance, and token holders have little say. Polkadot at least gives us the space to explore the combination of governance and technology, which, although difficult, is already the best option.
Tomek: From an engineer's perspective, we can still make some predictions:
Parachains can still be upgraded without forks; this will not change. Fellowship will likely continue to be subject to OpenGov constraints, meaning that DOT holders still have the highest authority. JAM services are permissionless, and anyone can deploy new services. The services themselves can also be set to support upgrades, such as allowing developers to authorize updates to service code. To deploy and run services, ‘core time’ is needed, and obtaining core time will likely still require payment in DOT.
So you can see that the system of DOT, OpenGov, and Fellowship, although its form has changed, essentially still operates around these core elements. And don't forget, although the JAM infrastructure is decentralized and censorship-resistant, the services built on it can completely choose whether to be open or centralized, which is where the flexibility lies.
What is the goal of JAM DAO?
Q4: I heard that a JAM DAO was recently established. You should all be in this DAO, right? Can you elaborate on its goals and your vision for the future, say five or ten years from now? After all, you are personally building JAM and should hope to play a role in its future development.
Daniel: Well, JAM DAO was actually just established in the past few weeks, very new. The core idea of this DAO is: we have now set up the JAM Prize, and the rewards will be distributed in locked DOT tokens. This means that a large amount of locked DOT will be concentrated in the hands of JAM developers in the future, equivalent to holding a lot of voting power within Polkadot's open governance system.
Thus, the original intention of establishing the JAM DAO is: since we hold so much governance voting power, we need to start coordinating actions, understanding each other, and actively participating in discussions of other proposals. To be honest, I knew almost nothing about OpenGov at the beginning. As an ordinary developer, I actually don't like getting involved in political affairs. But the reality is that after this period of work, we all realize that some key decisions must be participated in; if we don't speak up, others will make decisions for us.
Thus, the establishment of JAM DAO is to enable developers to act together and voice our vision for the future of Web3. Of course, the DAO is still in a very early and loose stage, but as time goes on, I hope more people will participate in voting and making decisions for the protocol's development. This is what we are working on now.
Is JAM unable to retain data? Will it disappear after 24 hours?
Q5: Yesterday I had the opportunity to ask Gav about the distributed data lake and erasure coding. My understanding is that most of the data used for computation will come from this data lake, and ultimately only be submitted to the chain in hash form. So the question is, since these erasure-coded data blocks will be cleared after 24 hours, does that mean our financial data will disappear after 24 hours?
Join the PolkaWorld community and build Web 3.0 together!
So in JAM, we hope to develop a whole set of data backup networks that go beyond basic validators. This means that in the future, there should be some dedicated services or nodes responsible for keeping this data longer, rather than just for 24 hours. However, these are not fully established yet because the JAM ecosystem is still in its early stages, and even the basic validators and chains are still being built. But it is certain that there will be ways to ensure that data can be stored for longer.
Q6: So does this mean we still need to deploy dedicated collators or block builders for service deployment? Is the service on JAM that is truly viable more like running a project similar to a parachain? Rather than deploying a smart contract and then not having to manage the infrastructure?
Alistair: Not entirely correct. We can indeed store all state data in the data availability layer, but to keep the data beyond 24 hours, you need to rely on external participants. However, these participants storing data are not limited to only preserving the historical data of one chain, nor do they need to store everything. We have already introduced data sharding and encoding mechanisms. This gives us the opportunity to create a model similar to Ethereum light nodes, where many decentralized nodes store partial data, and this mechanism allows you to use existing data recovery mechanisms to obtain erasure-coded shard data from nodes outside of validators. Theoretically, this data can be stored permanently. Of course, it does require someone to build the infrastructure, but these facilities do not need to be centrally operated nor tied to a specific chain.
Q7: My only concern is that we still face the same game theory problem—we need to incentivize external parties to store our data. Although the underlying chain based on JAM can ensure the safety of state transitions, it cannot guarantee the ‘activity’ of the data. So we must find a way to make others willing to permanently store our data.
Alistair: Yes, you can never save all the data yourself; you must incentivize others to participate in storage. But the possibility of decentralization lies in letting each participant only save a small data shard, which keeps storage costs low. This is not an insurmountable problem; we do not need to rely on a centralized service to store all historical data. Of course, the incentive mechanism for validators faces the same challenge—we incentivize them to save data through the system mechanism, but we cannot require them to store it permanently; otherwise, storage demands would become impractical.
Maciej: To add a bit more, services like Polkadot Hub may still exist in JAM. For example, if you only want to deploy a smart contract without managing too much, someone can implement the corresponding incentive protocol on Polkadot Hub to run the collator in JAM. You would just need to deploy the smart contract and not have to worry about the rest. This is an option and sounds like the model you want.
Tomek: I think the key point here is that while the demand for data storage still exists, JAM has relaxed this requirement and returned control to developers. You can choose to store everything on-chain, but you will be limited by on-chain capacity, and you will have to pay accordingly. Conversely, you can choose to put all your data in an off-chain data lake, which requires you to consider how to incentivize others to help you store this data and pay accordingly.
There is nothing that cannot be done on Polkadot; it’s just that some things are easier and more efficient on JAM.
Q8: What current user needs or features cannot be implemented on Polkadot and must turn to JAM to meet?
Maciej: The first thing that comes to mind might be the concept of ‘Coreplay’. Though I'm not particularly knowledgeable about this, as I understand it, Coreplay can achieve an unrestricted execution—code can be executed gradually across multiple blocks on the chain and supports using ordinary programming languages to write for loops and other logic. Such functionality is currently not possible on Polkadot, but JAM may achieve this, though I’m not quite clear on the current progress of Coreplay.
Alistair: My view is that there is nothing that cannot be done on Polkadot; it’s just that some things will be easier and more efficient on JAM.
Moreover, the way people currently use Polkadot does not fully leverage its potential. Everyone is still stuck in the mindset of ‘one team working on one chain, and they are all quite similar.’ When we originally designed Polkadot's Crowdloan system, it somewhat mimicked the mechanisms from the ICO craze back then, which may not be a good direction. With the launch of new features in Polkadot 2.0, we are already exploring paths beyond the parachain model, and JAM is the next step in this evolution. In summary, theoretically, there is nothing that parachains cannot do; it's just that no one has really tried to address these challenges.
Why is the governance of Polkadot moving to Asset Hub instead of running directly on JAM?
Q9: I want to ask about the migration of the Asset Hub to JAM. As I understand it, the reason we are migrating core functions such as governance and tokens to the Asset Hub is to prepare for the future transition to JAM. However, my question is: since JAM ultimately runs under a runtime, we will still have GrandPa (consensus mechanism) and core virtual machine (core VM). If that's the case, why can't we implement governance directly on JAM's core VM? Doesn’t this instead introduce more security issues regarding data loss and node operation?
Tomek: Let me explain. The core virtual machine service still needs someone to run it—you can't expect JAM to just deploy and run automatically. That means, as a service, it requires 'core time', which must be provided by certain nodes or participants to execute your service. While validators will ensure that the service executes correctly, the question of ‘who provides core time’ still needs to be clarified. The network of nodes we currently refer to as 'collators' is meant to address this issue.
In fact, Gavin mentioned the proposed structure for Coreplay yesterday. You can check the relevant recording; I won't repeat it here. Secondly, you asked why governance cannot be implemented directly on the core VM? From an implementation perspective, the simplest path is to move our existing system to JAM first, and then gradually transform some of its parts into native JAM services.
Alistair: I understand your question is more like: since we will make JAM more universal in the future, why not put all functionalities (such as governance) directly on the relay chain from the beginning? The answer is that the relay chain is not meant to do everything. What we want is a modular, comprehensible architecture. If everything is placed on the relay chain, it will become very complex and difficult to maintain and will have poor scalability. Therefore, we must migrate the core functions of Polkadot to the Asset Hub as preparation for moving to JAM. One of the core reasons for this is to simplify the relay chain, making it more ‘elegant’ and maintainable.
Of course, this also brings up a new problem: we need to ensure that the data in Asset Hub is not lost, and that there are enough full nodes to ensure its availability and resistance to censorship. Otherwise, we would be moving from the high security of the thousand validators that Polkadot previously had to a more vulnerable structure, which is unacceptable.
Maciej: Another reason is that we hope the future governance system is upgradable, while the core protocol of the relay chain itself is not upgradable. If you embed the governance mechanism directly into the core protocol, updating it in the future will be cumbersome, if not impossible. Therefore, our final conclusion is that it is better to run it as a ‘service’, which is more flexible, simple, and modular. Otherwise, once changes are needed, it not only wastes effort but also increases the complexity of the system, making it difficult to maintain and develop.
What impact does JAM have on the entire blockchain market?
Q10: Hello everyone, there was a mention before about how JAM will affect Polkadot's development and the Relay Chain. What impact do you think the JAM standard will have on the entire blockchain market? Will it become the industry standard in the future?
Maciej: This question actually forces us to make the next bet. All of us are committed to this project because we believe that JAM has the potential to become the industry standard. Looking back, for example, at the migration of Polkadot Hub and Asset Hub, many people prefer to develop on Solidity, so we provided them with Solidity smart contracts on Polkadot. Similarly, JAM will support more cross-chain bridging to allow everyone to migrate assets from Ethereum or other ecosystems. If someone needs Solidity, that can certainly be implemented; if high throughput and low fees are needed, that can also be satisfied; and if someone prefers the development model of parachains, suitable solutions can also be provided. In general, JAM will cover different niches and user groups. As long as the ecosystem has a complete set of smart contract tools, I find it hard to imagine what needs the future Polkadot ecosystem won't be able to meet.
Alistair: Indeed. We initially have a technical advantage, and now we are further strengthening that advantage. But we also realize that Polkadot is not friendly enough in deployment and user experience, so improvements in this area are very important for JAM to succeed. If the JAM protocol is to succeed, it must enable more developers to easily build applications on it.
Following yesterday’s article, PolkaWorld continues to bring you the JAM implementation team’s explanation of JAM and sharing of its development status!
Q11: How many development teams are genuinely committed to producing a JAM node that can go live in a production environment? Or is everyone just looking to ‘complete a milestone’? Do you have an understanding of how many teams are truly aiming for the final product?
Daniel: This question is indeed not easy to answer, because JAM is an open protocol, and anyone can secretly develop in the corner. In theory, there could be hundreds of teams working on it. But from my observations:
On the official gray paper website, 38 teams have publicly announced that they are working on JAM. Among them, about 20 to 25 teams are quite active in chat groups, asking questions and providing feedback, indicating that they are genuinely working. We are also organizing offline meetups for JAM, and about 15 to 20 teams are willing to participate and communicate at these meetups. Most of these teams should at least reach the third milestone.
Of course, whether you can reach the fifth milestone still depends on future developments. My guess is that there will ultimately be at least eight mature JAM implementation versions—this number far exceeds that of any other blockchain protocol. But this is just my guess; we can make a bet now and see who guesses correctly in five years, haha.
Alistair: In fact, everyone still has time. If you want to participate and sprint to milestone five, there is still an opportunity.
Daniel: Yes, if you want to ask, ‘Can rewards still be received?’ the answer is: Yes! It’s not too late to join now.
Alistair: One thing I'm slightly concerned about is whether the rewards in the later stages four and five are sufficient, as this will affect whether people can stick with it until the end. Additionally, parts of the gray paper regarding the consensus mechanism haven't been fully detailed yet, and no one is seriously working on that right now, but eventually, someone has to.
Maciej: I agree. As everyone delves deeper into development, more detailed issues will emerge, and everyone will continuously discuss and ask in the chat group, ‘Is this part too vague?’ This will constantly push for the refinement of the protocol. We have already begun to touch on core modules like Elves consensus, which excites me, as it feels like the entire protocol is slowly taking shape.
Tomek: I also agree with what was said earlier. From my perspective, the leap from milestone one to two is the hardest. Those who manage to cross from one to two can be seen as genuinely serious about their work. After crossing from two to three, while there are still some challenges (like performance optimization), the overall difficulty is not as steep. If you see a team complete milestone three, you can almost be certain that they will stick it out until the end.
Q12: You talk about the ‘fifth phase’, but what does that mean? Also, how much of the gray paper has been clearly defined, and how much has not yet been clarified?
Daniel: Okay, let me briefly explain the five milestones of JAM:
Milestone 1: is to achieve correct execution of ‘block import’ and ‘state transition function.’ Although not a complete implementation of the protocol, it can be considered about halfway done. Milestone 2: involves building a complete node, including all off-chain relevant modules. For example, the data availability layer and the communication network between nodes all belong to the off-chain part. By the second milestone, you basically have a full node that can run, although performance may still be poor. Milestone 3: is to optimize performance to a level comparable to Kusama. This means the node can be used smoothly at least in a testing environment. Milestone 4: further optimizes to approach the production environment performance level of Polkadot and can support going live. Milestone 5: is to confirm this software is safe and reliable through independent auditing, allowing it to be safely deployed anywhere.
So overall:
Phase one is to ensure the correct import of blocks. Phase two is to get the nodes fully operational. Phases three and four are for performance tuning. Phase five is to confirm software quality through auditing.
Phase five actually also relies not just on the teams themselves; the auditing parties will propose modification suggestions, and they must be corrected as required to pass.
Will so many JAM clients ultimately be put to use?
Q13: There are many incentives now to encourage everyone to develop various different implementation versions, right? So after the rewards are distributed, what future motivation will ensure that there is always a diversity of implementations in the ecosystem? Won’t we be left with just one or two versions in the end?
Kian: I can briefly answer this. In fact, the JAM rewards are not just a one-time thing; they also promise an opportunity—to join the Fellowship. We hope that those teams that can complete all five milestones will have most of their key members join the Fellowship. The Fellowship itself has a salary—if viewed purely from a monetary perspective, it is a form of long-term economic incentive. Additionally, as Daniel mentioned just now, teams that complete all five milestones will receive a large amount of locked DOT as a reward, which itself is also a form of ongoing incentive.
Daniel: It's not just that. If you can develop JAM to milestone 5, it means you have a very deep understanding of blockchain development. After that, you will be able to propose various improvement proposals on OpenGov and get on-chain funding support to develop more new things. Your knowledge and reputation can be converted into real resources. So completing JAM means that you become an influential person in the entire ecosystem, and it will be relatively easy to get support for any project you want to do afterward.
Tomek: Yes, to add on what Kian said: according to the rules, for each milestone delivered, one member of the team can be nominated as a level-three member of the Fellowship. Additionally, joining the Fellowship is not just about getting paid; it comes with responsibilities. The Fellowship's duty is to maintain the protocol long-term. So once these implementers of JAM join, their responsibility may be to continue maintaining the versions they have developed. If one day it is found that maintaining so many versions is unnecessary, everyone may combine resources to maintain one or a few core versions together.
Maciej: To add, the so-called 'mysterious incentive' of Fellowship is essentially just a salary—it’s the salary you receive as a protocol maintainer.
Q14: What I just asked is not just about money. I want to ask how to ensure client diversity in the future? It shouldn't be the case that everyone ends up using the best implementation and the others are left unused, right?
Tomek: I have two thoughts on this question.
The first reason for choosing different implementations is to enhance the network's fault tolerance. For example, Bitcoin once encountered a situation where a certain mining pool almost reached 51% of the hash rate. At that time, although that mining pool had the highest profits, many people chose to exit and transfer their hash power to other pools. Why? Because the community had a consensus: we cannot let one mining pool hold too much power. This kind of 'social consensus' mechanism helps the network avoid the risk of centralization. Similarly, in the implementation of JAM, if the entire network only runs one client version, if that implementation has a bug, the whole network could be in trouble. Therefore, for safety and stability reasons, people tend to maintain a certain degree of implementation diversity.
The second point is: it also depends on the strategy of the JAM implementers themselves. I can imagine that different implementations may be optimized for different operational modes or specific scenarios. For example, one implementation may be particularly well-suited to run on Apple Silicon, while another may perform better on AMD processors. Some implementations may also add additional features—such as (though I wouldn't necessarily encourage it) features related to MEV. This gives implementers a space for innovation: they can develop unique functions based on different needs to attract users to choose their client.
Daniel: Let me add one more point: since each implementation is written in a different programming language, they will naturally attract their respective developer communities. For example, our team uses Elixir, so in the future, developers from the Elixir community will be more willing to use our version and continue developing on it. Everyone knows that developers have a strong affection for their programming languages, so different languages and communities will naturally maintain the versions they prefer.
Alistair: Yes, I want to emphasize that even if 95% of validators are currently using a certain high-performance implementation, that doesn't mean it will still be the case two years from now. The ecosystem is dynamic and constantly changing.
What features or tools do developers expect in the JAM ecosystem?
Q15: Hello, previously Tomek mentioned that his team developed a tool for reading the gray paper. I want to know if there are currently other teams developing similar tools or if other teams are sharing and using these tools? Were these tools created collaboratively? If not, do you have any tools you’d like to see others develop?
Daniel: I haven’t seen many tools, so there is actually a lot of space for innovation in this area. Let me talk about our team; our current focus is entirely on developing JAM, so we don’t have time to work on other tools, nor do we want to waste time. Right now, our team is quite small, only two people. Different teams have different situations; some teams may spend more time on tool development. As milestones are progressively completed, you can expand your team and recruit more developers to do these things.
Whether you are a developer who wants to join JAM, or an ordinary user who is optimistic about the future development of JAM, this article is worth reading and learning!
In addition, the PVM also has a gray paper reader. Also, I noticed that there is currently a very promising tool missing: JAM nodes will have internal statistics, and this data will be stored in the chain's state, recording metadata about the JAM chain.
Currently, we do not have a visual way to present this data; we can only view it through logs or similar methods. If there could be a visual interface that displays the nodes running on-chain and their statuses, providing some graphical representations, that would certainly be very useful in the short term, especially when starting to run the testnet.
Tomek: Yesterday, Gav showcased the JAM top tool he developed, or one of his team members did, which is a tool that can convert between JSON and JAM encoders/decoders. Additionally, the Graymatter team is maintaining a complete documentation website that includes documentation for the JAM chain, excerpts from the gray paper, and links to other resources.
Another interesting idea was proposed at the JAM implementers’ meeting: to develop a search engine for the Element chat group that could index all messages. Since the built-in search function of Element is not very useful, this would be a practical tool.
Kian: I can also add that one of the requirements for JAM prizes is that each team must demonstrate their submission history to ensure that the submission records are transparent and that no non-compliant operations have been conducted. Therefore, our team developed a tool that, as part of GitHub Actions, publishes a note with the commit hash on the Asset Hub or a chain’s system every time a commit is made. Thus, our Git commit history is publicly available on-chain. As for my wishlist, I don’t have anything particularly special to share.
How does JAM enhance the user experience of Polkadot in the future?
Q16: You mentioned before that the user experience of Polkadot is somewhat lacking. I would like to ask how JAM or the JAM era will address this issue? What expectations do you have for the future user experience of Polkadot?
Daniel: I think this actually falls outside of JAM’s scope; JAM mainly focuses on building the underlying protocol. I agree that Polkadot does need improvement in user experience, but that is not within JAM's responsibilities. JAM is merely laying the groundwork, and how vehicles travel on it, what color they are, all these considerations are outside of JAM’s scope. Of course, we are paving a better, smoother ‘asphalt road,’ so applications built on it will inherently have more possibilities, but this does not mean it will directly improve the developer experience; that needs to be improved in parallel.
Maciej: I completely agree. I think the solution to this problem is not JAM, but the work currently being done on Polkadot Hub, such as Polkadot applications and surrounding tools that are working hard to address this issue. I believe this is a problem worth paying attention to.
Q17: I don't think this issue is very serious. In fact, I'm quite confident that the user experience of Polkadot is much better now than it was three or four years ago. I remember when I first joined the ecosystem, we only had Polkadot JS, and as a newcomer, the experience was very poor. Now we have Nova Wallet, SubWallet, and various mobile options. I believe these are top-notch products, and soon there will be a Polkadot App released. So my point is that JAM is making architectural changes at the base level, but our interaction with Polkadot is still through these front-end tools, which are continuously improving and are already doing quite well.
Maciej: I agree that the situation with wallets has indeed improved significantly, and there is still a lot of room for progress. For example, Ethereum smart contracts are supported on Polkadot Hub, and we can start utilizing Ethereum tools, IDEs, and other ecosystem resources. I don’t know how many of you encountered Solidity smart contracts in your course, but we already have some prototypes and branches of Ethereum tools in use here that you can leverage directly in our ecosystem.
Tomek: Yes, I think another point worth noting is that there may be two parallel development paths in the future.
On one hand, the existing things on Polkadot are likely to migrate to JAM. We will not start from scratch but will continue to evolve and optimize based on existing foundations.
On the other hand, as Maciej just mentioned, new services built on JAM may face even greater UX (user experience) challenges in the future because the architecture of JAM is relatively complex, involving more components, and it may be more difficult to create smooth and user-friendly products in the early stages of development.
But it is precisely because of this that developers can start from scratch, building services that meet their own needs. How the user experience on JAM will develop in the future ultimately depends on you developers and how other teams create services and SDKs to build this ecosystem.
Kian: It seems the questions have been asked. Thank you to all the guests for sharing and thanks to the audience for their questions. Congratulations to everyone, today is the last day of the Academy, and it's also the last phase of your time here. You can go and rest now. Good night, thank you!
