Openloop SDK
Specifications
Version v0.8.1 ｜ Last updated 2026-10-11
Haudi Crypto,
Inc. President and CEO Kazunori Asada
Architecture Overview
What is the Openloop SDK?
The Openloop SDK is a multi-language library for communicating with the Openloop hardware wallet.
| Language / format | Main deliverables | Purpose |
|---|---|---|
| TypeScript / npm | @openloop/sdk-core,
@openloop/transport-* |
Web dApps, Node.js / Electron, React Native |
| Swift / SPM (planned) | — | Native iOS apps |
| Kotlin / Maven (planned) | — | Native Android |
| C# / NuGet (planned) | — | Native Windows |
About licensing: Use of the Openloop SDK requires a license agreement with Haudi Crypto, Inc. We can also customize the SDK to suit your requirements — please feel free to contact us at info@crypto.haudi.jp.
The single most important principle: private keys stay inside the device and never leave it. The SDK only sends and receives APDU (Application Protocol Data Unit) commands, and builds and verifies the data that goes to and comes back from signing. All signing is performed inside the device’s secure element.
Layer Structure
What each layer does
| Layer | Role |
|---|---|
| dApp | User interface, transaction construction |
| App class | Builds chain-specific APDU commands and parses responses |
| Bitcoin module | (Optional) Address derivation and validation, UTXO selection, PSBT building, and more. It does not talk to the device (see below) |
| ITransport | Physical communication with the device (USB / BLE / WebSocket, etc.) |
| Device | Private key management, signing, user approval |
Security Model
What the SDK does
- Builds and sends APDU commands
- Parses responses (addresses, signatures, and so on)
- Manages transport connection and disconnection
- In the Bitcoin module (
@openloop/sdk-core/bitcoin): derives and validates addresses, selects UTXOs, builds PSBTs, extracts the signed transaction, and broadcasts it (an HTTP request to the endpoints the caller passes in)
What the SDK does not do
- Generate, hold, or operate on private keys
- Perform signing
- Manage seed phrases
Security on the device side
- Private keys are generated and stored inside the device and never leave it
- All signing is performed inside the device
- Transaction details are shown on the device’s screen and the user approves them with a physical button
- When rejected or busy, the device returns status word
0x6985and no signature is produced
Supported Chains
| Chain | App class | Elliptic curve | BIP44 coin_type |
|---|---|---|---|
| Bitcoin | BitcoinApp |
secp256k1 | 0' (mainnet), 1' (testnet) |
| Ethereum (EVM) | EthereumApp |
secp256k1 | 60' |
| XRP Ledger | XrpApp |
Ed25519 / secp256k1 | 144' |
| Solana | SolanaApp |
Ed25519 | 501' |
| TRON | TronApp |
secp256k1 | 195' |
Bitcoin addresses come in three types: Legacy P2PKH
(44'), Nested SegWit P2SH-P2WPKH (49'), and
Native SegWit P2WPKH (84').
EVM-compatible chains
EthereumApp works not only with Ethereum but with any
EVM-compatible chain. Specify the chain through the chainId
parameter of signPersonalMessage and
signTypedData.
Transport Connection Methods
The SDK offers six transport packages, plus WalletConnect built into
@openloop/sdk-core, covering a wide range of platforms.
| Transport | Package | Use case |
|---|---|---|
| WebHID (USB) | @openloop/transport-webhid |
Chrome/Edge on desktop |
| Web Bluetooth | @openloop/transport-webble |
Chrome/Edge + Android |
| LocalWS | @openloop/transport-local |
All browsers (via Connect) |
| Safari Extension | @openloop/transport-safari |
iOS Safari |
| USB HID (native) | @openloop/transport-usb |
Node.js / Electron |
| BLE (native) | @openloop/transport-ble |
Node.js / Electron |
| WalletConnect | Built into @openloop/sdk-core |
All browsers (remote signing) |
See the Transport Guide for details.
Package List
npm packages (TypeScript)
| Package | Description | Dependencies |
|---|---|---|
@openloop/sdk-core |
Core library (OpenloopSDK, App, Types, Errors,
Constants, WcTransport), with the subpaths ./verify
(signature verification) and ./bitcoin (the Bitcoin
module) |
@noble/curves, @noble/hashes
(./verify also uses viem and
@scure/base) |
@openloop/transport-webhid |
WebHID (USB) transport | sdk-core |
@openloop/transport-webble |
Web Bluetooth transport | sdk-core |
@openloop/transport-local |
LocalWS transport | sdk-core |
@openloop/transport-safari |
Safari extension transport | sdk-core (peer) |
@openloop/transport-usb |
Native USB HID transport | sdk-core (peer), node-hid |
@openloop/transport-ble |
Native BLE transport (Node.js / Electron) | sdk-core (peer), noble |
Dependency graph
sdk-core is a TypeScript package with no dependency on
browser APIs or native modules (the one exception is the
fetch that ./bitcoin calls, which comes from
the runtime; you can replace it with the fetchImpl
argument). Each transport package supplies the platform-specific
implementation. Swift / Kotlin / C# libraries for native apps are
planned.
Entry points of
@openloop/sdk-core
| Import from | Contents |
|---|---|
@openloop/sdk-core |
OpenloopSDK, the App class of each chain,
ITransport, WcTransport, the errors
(OpenloopError, ApduError,
TransportError), constants, and utilities |
@openloop/sdk-core/verify |
Verification of signatures the device returned (loads
viem) |
@openloop/sdk-core/bitcoin |
The Bitcoin module: functions for addresses, UTXOs, fees, PSBTs and
broadcasting, plus BtcError. Does not load
viem |
The Bitcoin Module
BitcoinApp is the layer that talks to the device. The
subpath @openloop/sdk-core/bitcoin, by contrast, provides
the Bitcoin work that can be done outside the device as
stateless functions.
- Derive receiving addresses from an account’s extended public key, validate a destination address, build paths
- Query endpoints (Esplora-compatible) for balance scans, UTXOs, fee rates and previous transactions
- Select UTXOs, build a PSBT, extract the raw transaction from a signed PSBT, and broadcast it
The network, endpoints, timeouts, paths, account and cache
are all passed in as arguments. The module holds no defaults
and no state, so you can work with several networks and accounts at
once. Errors come back as a BtcError (classified by
code). Only the step that has the device sign is
BitcoinApp.
A typical flow: fetch the account xpub with
BitcoinApp.getExtendedPubkey → fetch balances and UTXOs
with scanAccount → build a PSBT with
selectUtxos and buildPsbt → have the device
sign with BitcoinApp.signPsbtWithPaths → broadcast with
extractRawTx and broadcastTx. See the API Reference for
the API.
APDU Protocol Overview
Communication between the SDK and the device uses APDU (Application Protocol Data Unit) commands.
Command structure
[CLA] [INS] [P1] [P2] [Lc] [Data...]| Field | Size | Description |
|---|---|---|
| CLA | 1 byte | Class byte (0xE0: Ledger-compatible, 0xF0:
Openloop-specific) |
| INS | 1 byte | Instruction code |
| P1 | 1 byte | Parameter 1 (chunking control, etc.) |
| P2 | 1 byte | Parameter 2 (curve selection, etc.) |
| Lc | 1 byte (3 bytes when long) | Data length. When the data exceeds 255 bytes, the extended form is
used: 0x00 plus a 2-byte length (the SDK chooses it
automatically) |
| Data | Lc bytes | Command data |
Response structure
[Data...] [SW1] [SW2]| Field | Size | Description |
|---|---|---|
| Data | variable | Response data |
| SW1-SW2 | 2 bytes | Status word (0x9000 = success) |
CLA bytes
| CLA | Purpose |
|---|---|
0xE0 |
Ledger-compatible commands (BTC getAddress, ETH, XRP, SOL, TRON) |
0xE1 |
Openloop extension command (extended public key for any path,
GET_EXTENDED_PUBKEY) |
0xF0 |
Openloop-specific commands (chain_id-aware signing, PSBT, BTC xpub and message signing, EIP-712 streaming, device info) |
See Error Handling for the full list of APDU status words.
Next Steps
- Quick Start — a getting-started guide for developers
- Transport Guide — the platform support matrix
- API Reference — all type definitions and interfaces