As announced in the Global R&D of January 2025, DFINITY is working on a Solana RPC canister that will leverage HTTPs outcalls to interact with the Solana blockchain. This canister will be managed as a service (under NNS control) and will extend the Chain Fusion capabilities of ICP. Together with the already available support for threshold EdDSA signatures, the Helium milestone will be complete.
What to expect
You can expect a similar experience in terms of features and API as offered by the EVM RPC canister for EVM chains. In particular:
The canister will be under NNS control, where API keys will be managed by DFINITY.
Developers can pay for their requests with cycles and do not need to manage API keys or JSON RPC providers.
No single point of failure: by default, multiple providers are queried and their responses aggregated.
To make it easy to use, we plan on building a client to facilitate the interaction with the SOL RPC canister and also provide various examples.
Supported RPC methods
The list of methods that we plan to support at launch is not set in stone but would currently include the following:
getLatestBlockhash: currently cannot be supported directly with HTTPs outcalls due to fast changing responses, which would often result in consensus errors. There are some workarounds as mentioned here.
Do chime in if you have a use case in your dapp for a method that is not in the list. As for the EVM RPC canister, we also plan to have a generic method to forward any JSON payload so that the lack of support for some specific method at launch does not constitute a blocker.
Related projects
Special thanks to ic-solana which paved the way to interact with Solana via HTTPs outcalls. As far as we are aware of, the developers of that project do not intend to run it as a service. How much code will be shared between both canisters is yet to be defined, but it should not impact users of the SOL RPC canister (this is a pure implementation detail).
This is a pre-release, currently deployed on a staging canister (titvo-eiaaa-aaaar-qaogq-cai) on the fiduciary subnet (pzp6e). The only difference with the upcoming production canister is that the staging canister is controlled by our team, while the production canister will be controlled by the NNS. In particular, the production canister will also be deployed on the fiduciary subnet, meaning that latency and cycles cost should remain the same.
It comes with examples and a Rust client library to hopefully make it as easy as possible to build right away . Check out the repository for more details.
What’s missing for the first production release? We would like to add support for a few more methods (as listed in the first post) and maybe a few more providers but the most important part is actually your feedback . We would be very grateful for community projects to be willing to try out that first pre-release and let us know what they think .
I remember the mention of a difficulty with Solona RPC being that the hash needed to write a transaction was difficult to get through the RPC due to response times and the 13 nodes getting different responses.
Was this issue resolved and/or what is the best way to mediate it? Is there a suggested strategy for pulling the required info and then writing a transaction when there is not a user involved(in which case I’d assume your dapp code could get this more quickly and feed it in).
Hey
I’ve already built a fully on-chain cross-chain bridge on ICP, enabling secure and decentralized transfers:
EVM to EVM
EVM to Solana
EVM to Stellar
All key processes — from transaction construction, signature generation (ECDSA/Ed25519), on-chain indexing, and relaying — are handled entirely on-chain via ICP canisters. No off-chain relayers or centralized services involved.
The only part still in progress is extending the bridge to Bitcoin → Memecoin → Solana, which is actively under development.
Would love to bring this experience to your project and help build something iconic on ICP.
@gregory-demay Hello，thanks for your amazing work on sol-rpc-canister, I’m integrate the canister with our canisters. I found that the interface named getTransaction is not support the JsonParsed encoding. Could you let me known why? If you are working on it, when can the interface support the JsonParsed encoding ?
@StewartYe Thank you for your interest in the SOL RPC canister! That’s correct, we currently don’t support the jsonParsed or json encodings for the getTransaction endpoint primarily because of their limited support with the Rust Solana SDK (see e.g. here). Using a binary encoding (i.e. base58 or base64) also minimizes the response size.
Would you have an example use-case where using the jsonParsed encoding format would be valuable to you and/or where you cannot use a binary encoding instead?
It comes with examples and a Rust client library to hopefully make it as easy as possible to build right away . Check out the repository for more details.
We’ve integrated Solana, along with Stellar and EVM chains (testnet), into Kosh Wallet. The indexer runs fully on-chain within ICP canisters, and signing is done using threshold cryptography.
if you have a use case in your dapp for a method that is not in the list. As for the EVM RPC canister, we also plan to have a generic method to forward any JSON payload so that the lack of support for some specific method at launch does not constitute a blocker.
to ic-solana which paved the way to interact with Solana via HTTPs outcalls. As far as we are aware of, the developers of that project do not intend to run it as a service. How much code will be shared between both canisters is yet to be defined, but it should not impact users of the SOL RPC canister (this is a pure implementation detail).
.
. Check out the 
A Solana RPC method is not supported? There is an endpoint (
.
Projects that tried out the staging canister (
Also check out the blog post: