[Feature Request] Design a strict C-ABI / Cgo-friendly wrapper for wallet3 to facilitate Go/Rust backend integrations

[ChrisLattner03]

Hi Monero Core Team and contributors,

First of all, thank you for your incredible work on privacy and the ongoing massive architectural upgrades (Seraphis/Jamtis and wallet3).

As a backend engineer building multi-chain infrastructure (wallets and exchange gateways) heavily utilizing Golang, I want to raise a structural pain point regarding XMR integration and propose a low-maintenance solution that could massively boost Monero's adoption in modern tech stacks.

The Current Pain Point for Go/Rust Developers
Currently, integrating Monero into modern Go or Rust backends leaves us with two suboptimal choices:

Relying on monero-wallet-rpc: While robust, maintaining isolated RPC instances introduces significant operational overhead, especially for strict hot/cold wallet architectures where creating air-gapped offline signing flows via HTTP/RPC is clunky compared to native library calls.

Custom Cgo / FFI bindings: Wrapping wallet2 C++ classes manually is an engineering nightmare. Cross-compiling (e.g., macOS ARM64 to Linux AMD64) requires wrestling with complex LDFLAGS, Boost dependencies, and linker hell. Furthermore, these community-maintained wrappers frequently break during network upgrades.

To be absolutely clear: I am NOT suggesting rewriting any consensus-critical cryptography or wallet logic in pure Go/Rust. Maintaining dual implementations is a security hazard and a waste of your bandwidth. C++ is, and should remain, the core.

The Proposal: Native C-ABI Support in wallet3
Since the community is currently designing the architecture and API for wallet3, this is the perfect historical window to make the new wallet engine natively FFI-friendly (Foreign Function Interface).

Could the team consider the following architectural implementations for wallet3?

1. An Official C-Wrapper (extern "C"):
   Alongside the C++ API, expose a standardized, flat C-API header (e.g., wallet3_c_api.h). Modern languages like Go (via Cgo), Rust, Python, and Node.js can easily and safely bind to standard C functions, but they cannot directly bind to C++ classes or templates.

2. Pre-compiled Static Libraries via CI/CD:
   If the official GitHub Actions CI could output pre-compiled, self-contained static libraries (e.g., libwallet3_c.a / .so / .dylib) for major OS/Arch combinations (Linux/macOS/Windows, amd64/arm64) as release artifacts.

Why this matters?
By simply providing a clean C-ABI and static binaries, you instantly unlock the entire Go, Rust, and Node.js ecosystems. Backend engineers will no longer need to reverse-engineer C++ build flags or run heavy RPC nodes just to generate a stealth address or sign an offline transaction. It pushes Monero closer to the "Lego-like" developer experience currently enjoyed by Bitcoin (btcd) and Ethereum (go-ethereum).

I understand the team's priority is getting Seraphis and wallet3 safely deployed. I just wanted to put this on the architectural radar, as a clean C interface from day one would be an absolute game-changer for exchange and enterprise adoption.

Thank you for your time and dedication!

[vtnerd]

There is a C wrapper around the wallet API. It's a bit clunky, but very functional. Cake wallet uses this wrapper, so it's fairly well maintained. Comes with bindings for Dart, Typescript, and C#.

I also maintain a fork for light-wallets. In use by skylight wallet. The majority (99%) of the glue code is the same because everything uses virtual functions that can be swapped out.

If you need something beyond Wallets, it doesn't exist afaik. Updating "wallet3" to support C in this repo would be nice, but there is already an effort to get monero-wallet-cli and monero-wallet-rpc to use the C++ API instead of the internal interface it uses now.