First of all, thank you for keeping Solnet alive. I understand that maintaining such a large project is not easy, and I really appreciate BMResearch’s efforts to continue its development.
Background
Our company has been using .NET backend servers for our projects. At the initial design phase, we considered using Solnet directly to interact with Solana from C#. However, we found that Solnet was designed several years ago, and after BlockMountain transferred the repo, there have not been many updates. Features like Message V0 with address lookup table compilation, as well as some newer Solana functionalities, are still not implemented. Therefore, in practice, we adopted a hybrid architecture: C# WebAPI + a Python bridge for on-chain interactions.
Observations
As Anza now takes over the development of the core Solana SDK, I expect Solana’s feature updates to accelerate. I am concerned that Solnet might fall further behind.
I have noticed that, from the beginning, this repo seemed to attempt a line‑by‑line translation of Rust logic into C#. From wallet generation, to instruction composition, to legacy message compilation, a great deal of effort went into building an elegant C#‑style API. This complete rewrite kept dependencies clean, but it also makes it very hard to keep up with the latest Solana updates, especially when the main maintainers are no longer highly active. Analysing changes in the Rust SDK and porting them manually is a heavy burden.
A Possible Direction
As the main maintainer of solana-py, I have seen how solders (its companion library) uses PyO3 to automatically expose Rust SDK types and methods to Python. This made me think about a similar approach for other languages.
What if we create a library that directly references solana-sdk and exports a set of C interfaces via FFI? Then higher‑level languages (C/C++, Go, Java, C#, etc.) could each build a thin, memory‑safe wrapper around that FFI layer, plus adapt to their own API design conventions. The core capabilities of the Rust SDK would then be shared across all these ecosystems.
When Solana updates, we would only need to bump the FFI library version, maybe add one or two new functions, and downstream consumers could quickly get the latest features.
I admit that C interfaces are ugly—they require handling complex multi‑level array nesting and pointer safety. But this approach solves a major pain point: it offloads the most difficult and error‑prone tasks (versioned message compilation, wallet generation, signing, etc.) to FFI. These tasks otherwise force each native language to pull in many complex dependencies or rewrite everything from scratch.
Meanwhile, higher‑level languages can still handle JSON RPC request/response structure definitions themselves. Although defining those structures line‑by‑line against the Solana SDK is tedious, it is much simpler than message compilation. With AI assistance, validation and updates can be done relatively easily. Solnet already has a solid JSON RPC architecture, which is a good foundation.
Current Status and My Proposal
I have already implemented some basic FFI C API export prototype and passed local smoke tests. My favorite language is C#, so I would like to try introducing FFI call capabilities into Solnet first, as a Solana.Native module.
Therefore, I would like to discuss with the maintainers:
Does this approach sound feasible for Solnet’s future?
What would a possible roadmap look like? Are there any concerns or preferences regarding integration?
I am happy to contribute and work together on this. Looking forward to your thoughts.
Thanks for your time and consideration.
@BifrostTitan
Reference
https://github.com/kingsznhone/solana-native
First of all, thank you for keeping Solnet alive. I understand that maintaining such a large project is not easy, and I really appreciate BMResearch’s efforts to continue its development.
Background
Our company has been using .NET backend servers for our projects. At the initial design phase, we considered using Solnet directly to interact with Solana from C#. However, we found that Solnet was designed several years ago, and after BlockMountain transferred the repo, there have not been many updates. Features like Message V0 with address lookup table compilation, as well as some newer Solana functionalities, are still not implemented. Therefore, in practice, we adopted a hybrid architecture: C# WebAPI + a Python bridge for on-chain interactions.
Observations
As Anza now takes over the development of the core Solana SDK, I expect Solana’s feature updates to accelerate. I am concerned that Solnet might fall further behind.
I have noticed that, from the beginning, this repo seemed to attempt a line‑by‑line translation of Rust logic into C#. From wallet generation, to instruction composition, to legacy message compilation, a great deal of effort went into building an elegant C#‑style API. This complete rewrite kept dependencies clean, but it also makes it very hard to keep up with the latest Solana updates, especially when the main maintainers are no longer highly active. Analysing changes in the Rust SDK and porting them manually is a heavy burden.
A Possible Direction
As the main maintainer of solana-py, I have seen how solders (its companion library) uses PyO3 to automatically expose Rust SDK types and methods to Python. This made me think about a similar approach for other languages.
What if we create a library that directly references solana-sdk and exports a set of C interfaces via FFI? Then higher‑level languages (C/C++, Go, Java, C#, etc.) could each build a thin, memory‑safe wrapper around that FFI layer, plus adapt to their own API design conventions. The core capabilities of the Rust SDK would then be shared across all these ecosystems.
When Solana updates, we would only need to bump the FFI library version, maybe add one or two new functions, and downstream consumers could quickly get the latest features.
I admit that C interfaces are ugly—they require handling complex multi‑level array nesting and pointer safety. But this approach solves a major pain point: it offloads the most difficult and error‑prone tasks (versioned message compilation, wallet generation, signing, etc.) to FFI. These tasks otherwise force each native language to pull in many complex dependencies or rewrite everything from scratch.
Meanwhile, higher‑level languages can still handle JSON RPC request/response structure definitions themselves. Although defining those structures line‑by‑line against the Solana SDK is tedious, it is much simpler than message compilation. With AI assistance, validation and updates can be done relatively easily. Solnet already has a solid JSON RPC architecture, which is a good foundation.
Current Status and My Proposal
I have already implemented some basic FFI C API export prototype and passed local smoke tests. My favorite language is C#, so I would like to try introducing FFI call capabilities into Solnet first, as a Solana.Native module.
Therefore, I would like to discuss with the maintainers:
Does this approach sound feasible for Solnet’s future?
What would a possible roadmap look like? Are there any concerns or preferences regarding integration?
I am happy to contribute and work together on this. Looking forward to your thoughts.
Thanks for your time and consideration.
@BifrostTitan
Reference
https://github.com/kingsznhone/solana-native