Global architecture

A Ledger device application rarely runs in isolation. Understanding the pieces that surround it (the wallet app on the user’s computer, the network explorer, and the Ledger Manager) helps you decide what your device app must do, and what you can defer to the host. This page sketches the typical end-to-end architecture for a cryptocurrency app and shows where the device app fits in.

End-to-end architecture

End-to-end architecture of a Ledger OS application

A working setup has up to three pieces of software:

1. Ledger OS application. Written in C using the Ledger Secure SDK, running on the device under BOLOS. Handles the security-critical work: holding the private key, deriving addresses, displaying the human-readable transaction details, and producing the signature. The SDK targets the active Ledger devices: Nano X, Nano S+, Stax, Flex and Nano Gen5 (see the SDK’s API_LEVEL table for the exact device/OS pairs).
2. Wallet (or “companion”) app. Runs on the user’s computer or phone, talks to the device over USB or Bluetooth via the Device Management Kit. It owns the GUI, builds unsigned transactions, and forwards them to the device for signing. For most projects this is Ledger Live or a third-party wallet, so your team may not need to write one.
3. Transaction explorer / node. Speaks to the cryptocurrency’s network. Usually a remote light-wallet endpoint, sometimes a full node running locally. The wallet app uses it to fetch balances and broadcast signed transactions.

If your project does not add support for a new cryptocurrency (for example a plugin or a non-financial app), you can ignore the third piece, and the wallet app can be as simple as a CLI without a GUI.

The Ledger Manager

The Ledger Manager

The Ledger Manager is the service that distributes Ledger OS applications onto Ledger devices. It is the only path through which both Ledger’s own apps and third-party apps reach end users, and the entry point of the device-app submission process.

Why this matters

• Trust boundary. Anything that needs the user’s private key or has to be confirmed on a screen they fully control belongs in the device app. Everything else (UX, network calls, fee estimation, address book…) belongs in the wallet app.
• Memory and CPU budget. The device app runs on a constrained secure element. Heavy parsing and formatting are usually offloaded to the wallet app, then verified on-device against signed metadata. See Architecture good practices for concrete patterns.
• Distribution. Reaching users requires a Ledger Manager listing, which means going through the device-app submission process.

Key takeaways

• A Ledger app is one component of a three-part system: device app, wallet/host app, and network explorer.
• The device app is written in C against the Ledger Secure SDK and runs on BOLOS.
• The Ledger Manager is the single distribution channel for device apps.

See also

• Ledger OS introduction: what BOLOS is and how it isolates apps.
• Application environment: what an app sees at runtime.
• Hardware architecture: the secure element and MCU split.
• Architecture good practices: what to keep on-device vs. off-device.
• Device app role: the device app’s responsibilities in more detail.
• LedgerHQ/ledger-secure-sdk: source for the SDK.