In the past decade, we have witnessed two key innovations in the crypto world: one was the birth of Ethereum, and the other was the rise of the JAM protocol. And today, we are fortunate to invite a senior developer who has experienced both of these transformations to share his technical journey and outlook for the future.
In the 67th episode of the PolkaWorld interview, host Kristen converses with Polana co-founder Boy Maas to reveal the developer's perspective behind JAM, the birth story of Polana, and why introducing Solana's parallel execution model into JAM is a remarkable attempt.
Boy has witnessed the development of the entire Internet infrastructure during the early Web2 and has accumulated rich first-line experience in Ethereum, EOS, and Solana. Now, he and the team are at the forefront of JAM, building Polana from scratch—a new execution environment that merges the technological advantages of Solana with the decentralized vision of Polkadot.
This is not just a technical dialogue, but a deep review of two decades of internet evolution and a look into the future. If you want to understand the true potential of JAM or are curious about how a developer reconstructs the future of DeFi and on-chain services with 'continuous computation', this interview is not to be missed.
From writing code since 1996 to starting to build JAM today.
From not understanding the yellow paper to discussing the gray paper with Gavin.
Writing code on JAM without tools or documentation, starting with just one command line.
Thought of Polana while eating pizza, and then ported Solana to JAM.
Let Solana's smart contracts run infinitely on JAM and also stream videos.
Let Solana contracts run on Polana with zero modifications, just change one RPC address.
From SVM to PVM: Polana has already started running Solana contracts, and the next step is continuous DeFi.
From writing code since 1996 to starting to build JAM today.
Kristen: Hello everyone, I am Kristen. Today, our guest is Boy Maas from Polana.
Boy Maas: Hello everyone! I'm glad to see you.
Kristen: This is the PolkaWorld interview program, and this episode will focus on Polana and JamZig, which is an exclusive interview. We hope that through this conversation, everyone can gain a deeper understanding of Polana. The community has been continuously paying attention to the progress of Polana and wants to know what is happening. Many people are looking forward to this conversation, and I am also very excited about our upcoming exchange.
Before we dive into the topic, I want to talk about your background first. You have been working in the tech industry for over twenty years, and indeed, tremendous changes have occurred during these two decades. I left my hometown twelve years ago, and recently returned for a visit, only to find I could hardly recognize my home.
Regarding the internet, my feeling is that things seem to have stabilized over the past five years, but at the same time, we are starting to see many exciting innovations in areas like blockchain and artificial intelligence.
So we have actually experienced many significant transformations. You have personally experienced all these major shifts over the past twenty years. So I am curious, in this journey, have there been any key moments or special experiences that left a lasting impression on you?
Boy Maas: This is a very good question. I say this because I actually got involved in the early stages of the web, around 1996, when it was still in the early stages of Web2, and the entire internet world was still brand new. At that time, although everyone knew that the internet was about to bring about a revolution, its development was far from being as mature as it is today, and the various technologies of Web2 were still in their infancy. Therefore, having personally experienced the entire development process of the web creates a unique perspective. This is also like experiencing a historical evolution. Although history does not repeat itself entirely, it always rhymes.
I now see that many things happening in Web3 are very similar to the initial development of the web—whether it is the way it grows or the problems it encounters.
I remember back then, email was a very significant 'new technology'. At that time, if you wanted to set up an email address, you might need to assemble a team of 30 people to get it done. And now, it can be done in just a few minutes, right? So this gave me a deep realization: the power of network effects is enormous, and the early internet had already exhibited this power—though sometimes it was quite 'chaotic'.
Another point is that many people actually underestimate the potential of the web, especially the potential of the Web2 era. I still remember the first time I saw an interview with Jeff Bezos. He talked about a grand vision of what the internet could bring. But at that time, most people's reaction was, 'Maybe we can sell some CDs or small books online?' No one really realized what the internet world would look like today.
I have truly come from a very foundational stage. I have done very basic technology development, such as game development, financial application development, and the construction of many risk control systems. I can say I have 'touched' nearly every layer of the entire technology stack, which has given me a very special perspective on the development of technologies at different levels.
This is also why I like Web2 so much, because it feels like you have personally experienced the development of history, from 1996, or even earlier in 1994, all the way to now.
And now we see a similar evolutionary process again, only this time it has developed faster. Additionally, there are some things that humanity has never attempted before, such as cryptocurrencies.
From not understanding the yellow paper to discussing the gray paper with Gavin.
Kristen: So when did you start getting in touch with Web3?
Boy Maas: I started playing with it when Ethereum was just released, and I read its yellow paper at that time. But to be honest, I didn't really understand it back then. Because I didn't have a financial background at the time, and I wasn't very involved in social aspects. You know, cryptocurrency actually involves a kind of 'human attribute'—you need to coordinate a large number of people, and these people are actually interacting around 'value'.
At that time, my focus was mainly on the technical level. Although I read the yellow paper and thought it was cool and interesting, to be honest, there were many other things happening at that time. Then in the years 2016, 2017, and 2018, I regained interest in this field. At that time, I was involved in a project with a security company and a law firm, involving the token issuance of EOS. There were also many things happening in the entire industry at that time.
At that time, we encountered a very special opportunity, which was to participate in a brand new mechanism and become a block producer, and that mechanism is called Delegated Proof of Stake (DPoS). I was very fascinated by this brand new model, which allows you to replace the Proof of Work (PoW) mechanism with 'Delegated Proof of Stake' (DPoS). It is actually a socio-economic game theory model, in which validators have incentives to achieve consensus of more than two-thirds. As long as the majority of validators participate in voting according to the algorithm and remain honest, the security provided by this mechanism can rival that of Proof of Work, and its transaction speed is also very fast. So I joined that team, and we competed, eventually becoming one of the top 20 block producers.
At that time, we called ourselves EOS Amsterdam, and that was my true starting point in the crypto field. This experience was very motivating and very cool because our small team of validators actually brought a crypto network online. Especially when you are one of the genesis validators, that feeling is really different. Of course, we also encountered some unexpected situations. For example, on the day EOS went live, there was a small bug, and we actually had to call someone out of bed to fix this bug before the network could resume. But after that, the network operated completely as expected. This was also my first real exposure to blockchain technology.
Since then, I have started to delve deeper into this field. We initially started from the role of block production, but later I developed a strong interest in the 'transactions' aspect of blockchain. So, I built an arbitrage trading platform with a good friend, just in time for the launch of Uniswap. We discovered a wonderful mechanism called Flash Swaps. We could exploit the price differences between liquidity pools to do 'back-and-forth trading', and as long as there was a little price difference in between, we could make some profit. So we built a system that listened to all transactions on Ethereum in real time and tried to balance these liquidity pools. It was really a fun 'game'.
However, later on, the MEV (Maximum Extractable Value) problem emerged, making it very difficult to continue this business. Because at that stage, unless you are a block producer yourself, it is almost impossible to make money from it.
Later, I turned to blockchain development work, which lasted for two years. My partner and I ran a research department for a large blockchain network. We studied a lot of content, including Avalanche, false consensus mechanisms, MEV stability issues, and the construction of payment channels. Our focus was on how to make the system as decentralized as possible. This is actually a significant challenge. Then, one day, for various reasons, our research project ended. I attended a Web3 conference.
There I met Daniel, who is also a core developer from the JAM Elixir team. He told me, 'You know? Gavin Wood is building a brand new system.' He said this system has already 'liberated' itself from Ethereum.
I was very interested when I heard about it because I had previously worked on Ethereum-related projects, and I really liked Ethereum. Although many people may have opinions about it, I think its design is very smart and practical, and it does many things very well. I really enjoyed my time participating in the Ethereum system and greatly appreciate their designs and implementations in various aspects.
So I was immediately attracted to it. At that time, there happened to be a window of opportunity for me to start a new project. So I started reading that gray paper. In the first week, I wasn't very sure what I was reading, but it really challenged me.
At that time, I had two motivations: First, I am a Rust programmer, and I had been writing for about four or five years, even six years, very focused. I had also been interested in the Zig programming language. I admire its creator; he is very ambitious, and I resonate with his programming philosophy—writing code very close to the metal layer. So at that time, I thought, okay, this is interesting, and decided to learn this new language, which has many interesting features. The second is that I can gain a deeper understanding of Gavin Wood's latest design. He has initiated two heavyweight blockchain projects and has over 20 years of technical experience. For me, this is being at the forefront of technology, facing a system built by someone who has truly 'built things'.
So this also gave me the opportunity to truly absorb all the knowledge and understand all those design choices. Because for me, after years of R&D work and deep thinking, suddenly being able to access a system that has already thought through these issues, while I just need to focus on 'implementation' instead of 'rethinking'—this process actually makes me feel very relaxed.
So, this is why I am now in the crypto field, which is the path I've taken.
Writing code on JAM without tools or documentation, starting with just one command line.
Kristen: This journey has been truly amazing. Almost a decade ago, Gavin released the Ethereum yellow paper, kicking off what we now call the crypto 'golden decade'. And ten years later, JAM is igniting another technological revolution. Being able to participate in it personally is truly a great fortune.
As an experienced developer, you must be very clear about what developers really need. From your perspective, what different experience does JAM bring to developers? Especially since you also have many years of development experience at Ethereum, what are the differences between the two?
Boy Maas: That's a great question. To answer it clearly, we have to imagine a premise—what if nothing exists right now.
Because JAM is really built from the ground up, it is a truly foundational innovation that achieves many things that existing blockchains cannot do with a brand new architecture.
I think this is the most important point: JAM is not an iterative optimization of the old system, but fundamentally opens up new possibilities and brings a brand new application space. And these applications are almost impossible to achieve on traditional chains. Understanding the depth of this shift is actually very difficult; even if you have been working in this field for a few months, you may not immediately 'feel' its potential.
Going back to your question about 'What does JAM currently provide?' To be honest, there are very few development tools available now. For our Polana project, along with another project I did with Andy, many tools are developed by ourselves. Parity has provided some developer notes, and we have built a simple testing environment based on those notes, but if you ask if there is a complete set of mature toolchains or standardized methods for deploying services—there isn't yet. There are no complete documentation or development guidelines. Basically, everything has to be explored on its own.
Of course, this 'from scratch' process is also very interesting for us. For example, Andy has 25 years of development experience and is a very senior engineer. I am very impressed by his development efficiency and code quality. I also have a lot of experience, so we see this as a challenging but interesting experience.
Our team should be one of the earliest developers to truly start building products on the JAM network. And the JAM network is expected to take about a year to officially go live. One of our biggest challenges before that is: without any ready-made tools, how do we develop and test such a complex system? Especially since we are trying to port the entire Solana account structure to JAM.
There is certainly a reason for this: we want to immediately showcase JAM's capabilities once the testnet goes live. And the most intuitive way to do this is to demonstrate how it handles high-concurrency transactions, which allows everyone to truly see JAM's performance and potential.
So, back to your question: currently, JAM only has very basic tools, like a command line program that can compile code and generate services; beyond that, you have to rely on yourself.
Kristen: Although JAM is still in its early stages and many things are not yet released, that is precisely what makes it exciting. I believe the JAM client is a very key part of the entire JAM protocol because validators run the entire network through it.
At the same time, Polana is also deployed on the JAM protocol. So, where is JAM currently at? Can we understand it this way: once the JAM client is completed, the protocol is also formed, then it is truly ready for developers to use?
Boy Maas: Currently, several teams have completed the M2 stage of implementation, and about three teams have the capability of M2 implementation.
I can go back a bit and say—I probably started working on the implementation of JAM about seven or eight months ago.
We first need to understand one thing: the implementation of JAM is actually an unprecedented project. This may be the first time in history that someone, namely Gavin, has proposed an extremely outstanding design, mathematically defining the entire system's behavior pattern, known as 'observable behavior'. Then he said, good, now we need to promote the implementation of this system, so he set up incentive mechanisms, such as a 10 million DOT reward, to encourage the implementation of this design.
Currently, there are about 30 teams working on implementations simultaneously. We need a decentralized implementation approach. I believe this is the first time in history that so many teams are implementing different versions of the same protocol. But at the same time, this has also brought 'friction': everyone's understanding of the gray paper is not completely consistent, and communication between teams is relatively limited. Therefore, there may be deviations in understanding during the explanation and implementation process. Of course, some people have also begun to try to communicate and align proactively—only after comparing with each other can you know if your understanding of the gray paper is accurate. But so far, most teams are still fighting their own battles and interpreting it individually.
So the current situation is that each team is implementing certain components of this network based on their understanding.
You have to imagine this background: Parity is developing its own JAM client, the Java implementation of the JAM client is also being advanced, and the JamZig team is also developing their client. These different teams are all developing based on their own 'decentralized understanding' of the JAM protocol.
So now at this stage, each team is actually building the entire protocol implementation from its own perspective. And JamZig is one of the earliest teams to start introducing test vectors. The so-called 'test vectors' are a series of standardized test data provided by the community. These test vectors were mainly generated by the Colorful Notion development team, which is a very active team in the JAM ecosystem and has provided great value to other teams. The test vectors they built cover the entire block import process, so other teams can use this data to verify whether their implementations are correct.
The entire system needs to be tested, and there are many details to pay attention to. For example, the storage of state—the saving of data and states on the blockchain; and whether multiple teams can work together now. I think a very important point is that JAM is not just a technological innovation. It is also the first project designed from the very beginning with multiple teams working together simultaneously at different nodes.
The ideal outcome is that we will have about 25 nodes developed by 25 teams. All nodes will maintain valid data. I believe this will become the first truly decentralized network in blockchain history, capable of running simultaneously on more than 25 different nodes. This also means that if one node has a bug, it only affects a small portion of the nodes. As long as more than 2/3 of the node data is valid, the overall decentralization and security of the network can still be guaranteed.
Additionally, I think one particularly cool point that aligns with the Web3 philosophy is that there will not be a single interest party dominating the network. Instead, we suddenly have an ecosystem composed of the entire technical community. These teams have incentive mechanisms, willing to invest energy in this project for many years and long-term. They have a very deep understanding of technology, which will drive the entire network forward. I think this is not only a once-in-a-lifetime opportunity but also a true writing of blockchain history, creating a truly decentralized network.
Kristen: How long do we expect the testnet will take to go online?
Boy Maas: If various teams and the JAM project can start quarterly coordination, then ideally, the test net might go live within three months. However, this is still experimental technology, and performance has not been optimized.
There will be many subsequent version updates, such as M3, M4, M5, etc., and more experience will need to be accumulated to ensure certain performance.
But we can first have a very 'slow' test net to start developing services on it and gradually explore what this technology can do.
Thought of Polana while eating pizza, and then ported Solana to JAM.
Kristen: Awesome. Let's talk about Polana next, as it will help developers more easily develop on JAM and will be deployed immediately after JAM goes live. This way, everyone can learn about this project in advance. Regarding JAM and Polana, you previously worked at Ethereum, and now the project combines Solana, bringing Solana developers into the Polkadot ecosystem. How did this idea come about?
Boy Maas: I was actually also doing Solana development, which led to this idea. I have developed smart contracts on Solana and tested virtual machines to verify the correctness of smart contracts. If you have development experience across different ecosystems and technologies, gradually you will start combining these things, thinking about merging different technical advantages and seeing how it works.
A few months ago, I attended a conference in Lisbon, where all JAM developers gathered. We were visiting around, meeting many teams, and giving some progress reports. Gavin Wood was also present, explaining the upcoming phases to everyone. Through these interactions, I truly realized how much bandwidth and CPU resources we can utilize now. This really opened my eyes.
Then there was an opportunity where we were invited to visit Polkadot Palace. I noticed that, based on my experiences in different ecosystems, the Polkadot ecosystem is technically very excellent, and there are many people genuinely striving for technology. Moreover, the Polkadot community is one of the few that truly promotes the Web3 philosophy.
One important aspect is their palace construction. They built this palace in a very beautiful place, called 'Palace'. They hope to educate more people here and let everyone understand the infinite possibilities of Web3.
We were invited to visit the palace, and when we got there, we also ate pizza together. At one point, I communicated with Luke, who is also a JAM developer. I told him I suddenly had an idea: why not do something related to Solana? I thought this idea matched well because it could combine the advantages of both networks.
On one hand, the Solana network has invested a lot of effort in speed and has a very mature experience. Solana's ecosystem is great, with development tools and packaging tools done very well, and many people are participating in development. This is undoubtedly a very strong asset. Because the focus of Solana's network design is speed, it also brings some fundamental limitations.
For example, when I was using Solana, I remember there was a concept called account indexing. All these account indexes needed to be packed into a data packet and sent out, which limited how many accounts you could operate in a single transaction. Another point is that because Solana is optimized for speed, everyone knows that 'there is no free lunch'. So when you excessively pursue speed, there will inevitably be sacrifices in the level of decentralization.
So, on one hand, we have Solana, which is a network design that emphasizes speed. On the other hand, there is the Web3 philosophy represented by Polkadot, which is more general, more generalized, and also places more emphasis on bandwidth and decentralization, while JAM is the next evolutionary step for this chain. The combination of the two is simply a match made in heaven.
I began to think more deeply about this idea, and then while eating pizza with Gavin, I asked him if this idea was feasible.
He said directly, no problem. Then we went back to the whiteboard and planned the project together. I also called a friend and flew to Mursian, where everyone was fully committed to pushing the project forward. We all felt that although this project is complex, it is entirely feasible.
This is the starting point of the project. Now, we are having a lot of fun doing this.
We have now completed part of the porting work, so we can already execute some of Solana's code. We are working on cross-program calls and state storage related content. To be honest, the whole process is very interesting, and we are having a lot of fun. Currently, we can execute sample programs from Solana, such as Anchor and Sealevel. Everything is progressing smoothly according to plan. In fact, we are more fully committed to this project because we are all very excited. This is the story of how we got to this point.
Kristen: So Polana can be said to have originated from the 'Polkadot Pizza' festival!
Boy Maas: Completely correct, yes.
Let Solana's smart contracts run infinitely on JAM and also stream videos.
Kristen: So how is the integration between Polana and JAM?
Boy Maas: To understand the integration of Polana and JAM, you first need to understand how JAM operates.
JAM is a very abstract universal computing network, with a core concept called 'work package'. This work package will be sent to the network and processed in two stages—the 'refinement stage' and the 'combination stage'. The work package actually encapsulates the tasks of universal computing.
A very important point here is that JAM not only supports general computation but also supports 'continuous computation'.
For example, in traditional blockchains, you have blocks, and if you want to change the state, you need an external trigger to initiate a transaction to execute the state change. But JAM is different; it allows you to run an internal virtual machine in the network, which can run across multiple blocks. In other words, you can write a program that runs in an infinite loop, and it will keep running on the network. Everyone may have seen that demonstration, like Doom and Quake games running on JAM. This is its power: you can run any computational task on it.
So mapping Solana's Sealevel computing model to JAM is no small challenge. Because you need to understand the internal mechanisms of this system very deeply.
Although it is indeed difficult, we ultimately found a way to implement it.
Kristen: You just mentioned that continuous computation is the core innovation of JAM. This sounds like a fundamental shift in the blockchain transaction model. Can you explain to us what this means in practice? For developers, what is the difference between applications that execute continuously and traditional transaction-based models?
Boy Maas: This is a very, very good question because this is exactly what we are experimenting with now. JAM supports continuous computing, while you also have smart contracts like Solana.
For example, suppose you have a smart contract that can execute any use case. You deploy it to the network, and it continues to run, executing continuously. For example, it will run automatically with each block, and you don't need to initiate a transaction each time. This smart contract can monitor all lending pools in real time, calculate interest rates, monitor balances, and continuously adjust the flow of funds automatically.
So, you actually get a continuously running decentralized finance (DeFi) system. I say this spontaneously, but this is indeed something you can achieve. For example, algorithms can run continuously.
Another interesting application scenario we are also studying is video encoding. Someone mentioned at the conference that JAM's computing power is strong enough to support streaming video services. Although it consumes a lot of computing resources, it is entirely feasible because the network bandwidth is sufficient to support video streaming. You can write a smart contract that opens a streaming work package and starts transmitting video over the network—there will naturally be some latency, but it is feasible.
Additionally, there is a very cool feature where you can trigger any computational task you want to run through a transaction. It will start in the background, run on another JAM computing core, and return the result to you when completed.
These application scenarios will become possible. Imagine if you put Solana's programs on JAM, they would run in parallel across multiple computing cores. Countless transactions are initiated as individual work packages, and the system will automatically handle these tasks.
This is also why we refer to Polana as the 'Solana extension package', because we retain all of Solana's characteristics while adding additional functionality.
To run Solana contracts on Polana with zero changes, simply change one RPC address.
Kristen: As a Solana developer, what is the specific migration process through Polana?
Boy Maas: This is a very good question. In fact, there is no need for complex migration. You can directly move your contracts, SBF code, over to run.
What we currently plan to do is to create a work package builder, obtain a snapshot of Solana, then you just need to change your RPC node address to ours. If you already have funds on Solana, you can trade on Polana just like you would on the Solana network.
In fact, we will 'fork' the Solana chain at some point, which is more like a demonstrative 'copy', not the final product.
Our goal is not to replicate Solana, but to expand its functionality. The purpose of this is to demonstrate the powerful capabilities of JAM while being able to run and test this core technology. The migration process does not require any code modifications. You can directly take Solana's contracts and place them on Polana, and they will run. This is something we have already done.
Moreover, because Solana contracts essentially run on SBF Rust code, with the API being Anchor, you can also directly compile Solana contracts, then use PV coding, and execute them on Polana. It's like running locally, and the speed is very fast, no longer interpreted execution.
Kristen: So what about existing tools for Solana, like the KSD framework and development tools? Can they still be used?
Boy Maas: Of course, it can be done without any changes. In fact, teams developing on Solana can directly deploy on Polana.
For a team, deploying on two networks is as simple as flipping a switch; once deployed, it can be used directly.
Kristen: So if developers are willing to migrate to the Polkadot ecosystem, are the technical preparations completely ready? But their community atmosphere is completely different. The Solana ecosystem is particularly vibrant, especially in meme coins, NFTs, and some fast-paced, Degen-style communities. In fact, Polkadot has consistently attracted many technically oriented developers.
From your interactions with developers, why do you think the Solana team would be interested in migrating to Polkadot? What practical needs have they expressed?
Boy Maas: Yes, fundamentally speaking, as we mentioned earlier, Solana is very fast, but it does not fully align with the pure decentralization philosophy.
So for projects that value stability, running on Polana will be more advantageous. Additionally, Polana has extra features, such as supporting continuous computation, continuous DeFi, and being able to run computational tasks on other JAM servers. These features cannot be directly implemented on the Solana network.
Another significant advantage for Solana is that having more 'territory' is very beneficial. For example, on the Polkadot network, having more 'territory' means that they can achieve asset and value flow through bridges between them. This will allow value to enter the Polkadot ecosystem.
Another interesting aspect is that once we have value or DeFi services on JAM, this is something we haven't discussed yet. You can think of JAM as a network with 341 computing cores, all working in parallel. But every six seconds, the state of all computing cores will be synchronized to the blockchain. These are the contents processed on-chain. This is how we talk about how value can become coherent. In the demand phase, many computational tasks run in parallel. For example, performing calculations simultaneously on 341 cores, then aggregating in the accumulation phase to achieve consistency.
This also means that the network has bandwidth for nodes on different chains to communicate with each other. So if a chain runs on Polana, it can also immediately access the services of all other blockchains and the entire ecosystem running on JAM.
So, you suddenly connect to a vast network composed of many different chains, and various application scenarios will follow.
Kristen: But I'm worried, what if developers don't like the atmosphere here, or they prefer Solana or other ecosystems?
Boy Maas: We hope they can bring the atmosphere of Solana to Polana, so they will feel at home, right? But interestingly, my experience is that once you start executing a project, especially in the Solana ecosystem, everything starts to happen. It is actually very difficult to think too much about the future because we are accustomed to linear thinking and always think step by step.
However, once Polana goes online and has continuous computation capabilities, migration will become very easy. We will just wait and see what happens. Because at that time, it will be very interesting to see how people accept this new technology.
From SVM to PVM: Polana has already started running Solana contracts, and the next step is continuous DeFi.
Kristen: Let's wait and see. And I think about 85% of worries in life will naturally disappear. So, a few years from now, if everything goes according to plan, how do you imagine developers and users will interact with Polana? What do you think the successful look of the project will be?
Boy Maas: This is what project success looks like. You know, I entered the Web3 field because I genuinely believe in the idea of sovereignty. Even on a non-permissioned network, I believe everyone should be able to participate in this game of DeFi (decentralized finance). Polana will also launch in a similar way.
We do not want to own this project, but rather treat it as a use case, the first use case on the JAM network. In fact, it can showcase this technology. You can also think of it as a community project, trying to push it towards a decentralized state as quickly as possible, allowing the technology to be shared, everyone can participate, and everyone can have fun. Then we let it have its own vitality. When we release it and the technology is stable and usable, it should become an independent, viable entity.
Kristen: Like Polkadot's open goals, will Polana issue tokens in the future?
Boy Maas: We actually haven't thought deeply about this issue. Right now, we are mainly focused on building the technology.
But you also know, because this is the crypto field, the community needs to have the capability to drive and build this project. To be honest, we have not made specific decisions about the tokens yet. We are indeed considering whether we need to issue tokens, but if the project wants to enter the next stage, tokens may be necessary. However, we are not in a hurry because we are self-funded and do not need external financing. What remains is the technical preparation work, with the goal of having a sample project that can be called to showcase its powerful functionality.
Kristen: Okay, finally, please introduce our audience to the recent progress so that everyone can understand the latest status of the project.
Boy Maas: Currently, our progress is that we have implemented the integration of SVM (Solana Virtual Machine) with PVM (Polkadot Virtual Machine), so we can now run SBF (Solana BPF) bytecode in the JAM network. We have also developed corresponding development tools to support these functionalities. Now we can execute all sample programs, which come from different projects, and they all run normally. Next, we are developing cross-program applications, meaning we are starting programs in our virtual machine (VM) and running them across various services.
We will also continue to research continuous DeFi, meaning we need to allow programs to run for a long time, so we need to verify this in some form while combining Solana's design and the features of SVM (Solana Virtual Machine).
The most critical parts have been resolved, but optimizing everything still has a certain complexity, so we will be busy with this matter for the next few months. This is a continuous effort, with the goal of making the entire system run better and smoother.
Kristen: Great, I'm happy to hear this news. Our conversation contains a lot of knowledge; thank you for sharing. I hope the audience will pay attention to Polana and see how Polana brings 'magic' to the JAM protocol; this day is not far away.
Boy Maas: Absolutely, thank you, Kristen. You asked great questions, and this interview was enjoyable. It was also a pleasure to meet you.
Original video: https://www.youtube.com/watch?v=KSWzeWwBLXk