Solana VM on Polkadot SDK

[conr2d]

Project Abstract

Run Solana programs in the Polkadot ecosystem.

This project aims to integrate Solana execution environment into the Polkadot SDK enabling Solana programs (smart contracts) to run on Polkadot SDK-based chains. This integration will allow Solana programs to be deployed on Polkadot parachains and facilitate interaction with Solana wallets.

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read and followed the program guidelines.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.

[brunopgalvao]

Can't wait for this to be a service on JAM :)

[semuelle]

Thank you for the application, @conr2d, and congrats on being the first.
Please bear with us as we are still in the process of setting things up. In the meantime, I left some comments below.

[semuelle]

Could you elaborate what these ongoing projects are?

[conr2d]

I am building a non-profit project named by Noir, an extension to Polkadot SDK for building a multi-vm chains. This aims to solve diversified protocol specification issues by integrating EVM, WASM, SVM (Solana VM) and MOVE VM, so that any wallet users, any dapps can connect to Polkadot ecosystem seamlessly.

[semuelle]

This seems to overlap, but in functionality and in name, with Polkadot Hub. I doubt that the community would be keen to have two competing multi-VM hubs; what's your angle here?

[conr2d]

I don't believe these two chains are in a competitive relationship. The scope of the Polkadot Hub is limited to supporting an EVM-compatible YUL interpreter (pallet-revive) and PolkaVM (pallet-contract), which primarily target Polkadot and Ethereum (EVM) users. As such, its focus is narrower, addressing only users within the Polkadot and Ethereum ecosystems.

In contrast, our solution allows users from various ecosystems, including Polkadot, Ethereum, Cosmos, Solana, and Sui, to connect seamlessly to the Polkadot ecosystem without requiring changes to their wallets or the creation of new addresses. This enables users to directly hold DOT using their existing tools, a feature not supported by the Polkadot Hub.

Moreover, our solution benefits not only end users but also dApp developers. Developers can deploy their existing dApps without any modifications, significantly reducing migration costs and making it easier to attract them to our platform.

[Tomen]

Hub atm is not intended as a multi-VM hub, so I don't see competition here.

However, "system chains" specifically are chains that are maintained by the Technical Fellowship. Previous proposers put themselves in a bad situation where they proposed a system chain and the Technical Fellowship did not intend to maintain it. It would be better to suggest it simply as a parachain. I believe if Solana VM compatibility is there, a common good chain where fees are paid in DOT has a chance to be funded by OpenGov in the future

[conr2d]

@Tomen Thank you for your advice. We are a small team and want to focus more on the technical aspects, so we were considering having a support from the Fellowship in node operations. The code itself will be maintained by us. The reason we mentioned this is that once a token is issued, projects can sometimes drift regardless of technical maturity due to token price fluctuations. That said, we will also consider applying for support from OpenGov as one of the options.

[ditavia-br]

@conr2d thanks for applying. Here are some questions about the application:

From the technical perspective

• You plan to do something similar to the Solang compiler (https://github.com/hyperledger-solang/solang), which allows you to compile Solidity into Solana and Polkadot executable contracts. Grants Program funded a related project, Solang Playground (https://github.com/hyperledger-labs/solang-playground). It would be interesting to compare what the application proposes with what the Solang compiler does.
• How do you plan to test it? Ensure that all types of Solana programs will be compatible with Polkadot SDK look quite complex to me. It would be nice to have an idea of what is the test plan in this case.
• What kind of interface will the user have to translate or run Solana programs in Polkadot SDK? It would be a CLI? Can you exemplify how the user (programmer) would interact with that?

From the business perspective, thanks @LucaPolimec for adding that:

• What is the advantage of having a Solana compiler? More specifically who are the initial users you are attracting?
• If we are lacking the infrastructure (not competitive vs the one in Solana) for the use cases the Solana devs are aiming for why should it generate traction? See Solang compiler as reference which didn't pick up in mainstream traction by having it

[conr2d]

• You plan to do something similar to the Solang compiler (https://github.com/hyperledger-solang/solang), which allows you to compile Solidity into Solana and Polkadot executable contracts. Grants Program funded a related project, Solang Playground (https://github.com/hyperledger-labs/solang-playground). It would be interesting to compare what the application proposes with what the Solang compiler does.

We don’t believe the Solang compiler is similar to our proposal. Solang is a project that allows Web3 developers to write Polkadot contracts using Solidity, which they’re already familiar with. Meanwhile, we consider both Solana end users and developers as part of our user group, and our goal is to remove the hurdles that currently prevent them from accessing the Polkadot ecosystem, so they can connect with it immediately.

• How do you plan to test it? Ensure that all types of Solana programs will be compatible with Polkadot SDK look quite complex to me. It would be nice to have an idea of what is the test plan in this case.

You have a valid point. Heavy cryptography-related computations are too expensive to run inside a VM unless they’re supported at the core layer. Therefore, features such as zero-knowledge functionalities (which Solana supports but the Polkadot SDK does not yet) can’t offer identical capabilities. However, aside from these exceptional cases, asset-related programs like SPL Token (Solana’s equivalent of ERC-20) can run without any problem. That’s why we plan to test it by running pump.fun (a memecoin minting platform), which is currently one of the hottest dApp services on Solana.

• What kind of interface will the user have to translate or run Solana programs in Polkadot SDK? It would be a CLI? Can you exemplify how the user (programmer) would interact with that?

As far as I know, Solana program developers typically rely on CLI interfaces to build their programs. Since we're providing a full emulation of the Solana execution environment, they can continue using their existing CLI tools without modification.

We’re not just providing a VM. We’ll also provide a Solana RPC emulation layer, which is similar to building a Frontier for Solana. For testing, it should be possible to use a Solana wallet. However, because Solana doesn’t have a multichain ecosystem like Polkadot or Ethereum, many Solana wallets only offer limited network-switching features. In that case, you could use specific Solana wallets (e.g., Nightly) for testing.

Once the project is production-ready, we’ll reach out to major Solana wallet providers like Phantom or Backpack to request Polkadot network support. This shouldn’t be too difficult since we don’t need to rebuild wallet features for Polkadot; we just need to add the ability to switch the Solana RPC endpoint, as they normally do.

• What is the advantage of having a Solana compiler? More specifically who are the initial users you are attracting?

This isn’t just a Solana compiler; it’s a much broader project. In fact, this can’t be fully developed with a $30K grant. However, it aligns with our long-term plan to tackle protocol fragmentation in Web3 and use Polkadot as a hub for all possible blockchains. That’s why we’re generalizing certain capabilities so they can also be applied to other parachains.

With this feature, Solana users won’t have to install a Polkadot wallet or create a Polkadot address just to hold DOT. They can simply hold DOT with their existing Solana wallets. Also, developers who built dApps for Solana can deploy them on Polkadot without having to learn entirely new programming languages or protocols, eliminating those hurdles.

When we use the internet, we can open any website on browsers like Chrome, Firefox, or Safari. But in Web3, users have to switch wallets depending on the protocol a service is deployed on. This heavily disrupts the user experience. We want to let people expand their Web3 experience without having to discard the knowledge they’ve already gained on one protocol.

• If we are lacking the infrastructure (not competitive vs the one in Solana) for the use cases the Solana devs are aiming for why should it generate traction? See Solang compiler as reference which didn't pick up in mainstream traction by having it

This solution does not aim to make Solana developers immediately abandon Solana for Polkadot. The biggest issue right now is that, despite Polkadot’s strong infrastructure, most people don’t even know it exists. By allowing Solana programs to also be deployed on Polkadot, developers who want to expand their dApps to a multichain environment—without high costs—can move over first. If Solana SPL tokens can be transferred to the Asset Hub and use XCM, it will help introduce Polkadot’s infrastructure to Solana developers.

The same applies to end users. They might start simply by holding DOT, but once they get a taste of the Polkadot ecosystem, we believe that in the long run, they can be attracted by features that only Polkadot can offer.