On this page
Devices
Hardware SDK 1.2.0 supports two protocol families on one public API. Pick the device constraints here; keep calling the same methods.
| Device | Code | Protocol | USB | BLE | Air-Gap (QR) |
|---|---|---|---|---|---|
| OneKey Classic | classic | V1 | Yes | Yes | No |
| OneKey Classic 1s | classic1s | V1 | Yes | Yes | No |
| OneKey Classic 1s Pure | classicpure | V1 | Yes | Yes | No |
| OneKey Mini | mini | V1 | Yes | No | No |
| OneKey Touch | touch | V1 | Yes | Yes | No |
| OneKey Pro | pro | V1 | Yes | Yes | Yes |
| OneKey Pro 2 | pro2 | V2 | Yes | Yes | Yes |
| OneKey Neo | neo | V2 | Yes | Yes | No (no camera) |
The SDK reports the connected protocol on the device object as connectProtocol ('V1' or 'V2'). That value is the result of a live probe, not a lookup from the model name.
What you should do with the model
- Use model for capability and UX: Mini has no BLE, Neo has no QR Air-Gap, Pro / Pro 2 can do Air-Gap.
- Do not use the model name to decide Protocol V1 vs V2. Read the protocol confirmed by the active connection.
- Firmware update API follows the protocol family: Pro uses
firmwareUpdateV3; Pro 2 / Neo usefirmwareUpdateV4.
Integrator checklist
- Cache
connectIdper transport. USB and BLE IDs for the same unit are different. - Refresh
deviceIdafter wipe / recovery. See Identifiers. - Serialize calls per device. Keep input and signing flows serialized so prompts and results stay associated with their operation.
- Never replay a firmware update, wipe, or other side-effecting call after a transport error.
See also: Chain Support · Protocol V1 and V2 · Wallet Sessions
Last updated on