The Monero Developer Stack

If you want to build your own Monero wallet, payment processor, or exchange integration, the first thing to understand is the stack: a small set of official components that do the heavy lifting, and a few well-worn patterns for wiring them together. The good news is that you almost never reimplement Monero's cryptography. The hard parts live in battle-tested C++ code, and you talk to them over plain HTTP. This lesson maps out the pieces and shows where your own code fits.

The core components

The official Monero software ships several programs that share a common foundation. Knowing what each one does is the key to choosing an architecture.

• monerod — the daemon, or full node. It downloads and stores the entire blockchain, validates every block and transaction, handles P2P networking with other nodes, and exposes the Daemon RPC for queries plus a ZMQ publish interface for streaming new blocks and transactions. Everything else ultimately depends on a monerod somewhere.
• monero-wallet-rpc — a headless wallet exposed as a JSON-RPC service. This is the main integration tool for servers: it opens a wallet file, talks to a monerod, and lets your application create addresses, build transactions, and check balances via methods like create_address, get_transfers, and transfer. If you are building a backend, this is usually the component you target.
• monero-wallet-cli and the GUI — interactive wallets for humans. They are great for testing and for managing keys by hand, but they are not what you automate against in production.
• wallet2 — the C++ wallet library inside the official software. Every program above is built on it. monero-wallet-rpc, the CLI, and the GUI are all thin layers over wallet2, which handles key management, output scanning, and transaction construction.

Light Wallet Servers

A normal wallet scans the blockchain looking for outputs that belong to it, which is expensive for a phone. A Light Wallet Server (LWS) solves this: the user hands the server their view key, the server scans the chain on their behalf, and it returns just the outputs that belong to that wallet. The client can then display a balance and build transactions without downloading and scanning everything itself.

The trade-off is privacy — the LWS sees your incoming transactions because it holds your view key, though it can never spend, because the spend key never leaves the client. The reference implementation is the open-source monero-lws, and MyMonero pioneered this model.

The three integration patterns

Almost every real Monero product is one of three shapes. Pick the one that matches what you are building.

• Full node plus monero-wallet-rpc. You run a monerod and point monero-wallet-rpc at it, then drive the wallet over JSON-RPC. This is what merchants, payment processors, and exchanges use. BTCPay Server's Monero support is exactly this pattern under the hood.
• Embedded wallet2. You compile the wallet library directly into your application so it manages keys and builds transactions on the device. Mobile and desktop wallets like Cake Wallet and Monero.com work this way: they sync against a remote node for blockchain data but validate locally, so the keys and the spending logic stay on the user's hardware.
• Light-wallet server plus view key. The lightweight option for mobile clients that should not scan the whole chain. The client offloads scanning to an LWS using the view key, as described above.

Everything speaks JSON-RPC

Here is the detail that makes Monero approachable: both the Daemon RPC and monero-wallet-rpc expose JSON-RPC over HTTP. That means your integration code can be written in any language — Python, JavaScript, Go, Rust, whatever your team already uses. You send an HTTP POST with a method name and parameters, and you get JSON back. The cryptography, the output scanning, and the ring signature construction all stay in the C++ core where they belong; your job is to call methods like get_balance or transfer and react to the results. You are gluing components together, not implementing a blockchain.

Real products mapped to patterns

To make this concrete, here is how well-known software lines up:

• BTCPay Monero plugin — full node plus monero-wallet-rpc, watching for invoice payments.
• An exchange — monerod plus a monero-wallet-rpc hot wallet for deposits and withdrawals, usually with cold storage behind it.
• Cake Wallet / Monero.com — embedded wallet2 compiled into the mobile app.
• MyMonero — LWS plus view key, so the phone never scans the full chain.

What the rest of this course covers

Now that you have the map, the rest of Building on Monero: Developer Integrations works through the stack hands-on. You will set up and operate monerod for an integration, drive monero-wallet-rpc from code to create addresses and send funds, watch for incoming payments reliably, handle confirmations and subaddresses, and harden a hot-wallet deployment. If you plan to expose infrastructure to others, the operations side is covered in running a public remote node. By the end you will be able to build a payment flow end to end on components you control.

Next: Running monerod for Integration