@onekeyfe/hwk-keystone-adapter 1.2.2-alpha.100

package/dist/index.d.mts

@@ -0,0 +1,468 @@
+import { ChainCapability, IHardwareWallet, IConnector, TransportType, SearchDevicesOptions, DeviceInfo, Response, ChainForFingerprint, UiResponseEvent, HardwareEventMap, DeviceEventListener, AllNetworkGetAddressParams, AllNetworkAddressResponse, NullableCallArg, IHardwareCallParams, EvmGetAddressParams, EvmAddress, EvmSignTxParams, EvmSignedTx, EvmSignMsgParams, EvmSignature, EvmSignTypedDataParams, BtcGetAddressParams, BtcAddress, BtcGetPublicKeyParams, BtcPublicKey, BtcSignTxParams, BtcSignedTx, BtcSignPsbtParams, BtcSignedPsbt, BtcSignMsgParams, BtcSignature, SolGetAddressParams, SolAddress, SolSignTxParams, SolSignedTx, SolSignMsgParams, SolSignature, TronGetAddressParams, TronAddress, TronSignTxParams, TronSignedTx, TronSignMsgParams, TronSignature } from '@onekeyfe/hwk-adapter-core';
+
+/**
+ * A UR payload in the wire shape the reserved `QrDisplayData`/`QrResponseData`
+ * (from `@onekeyfe/hwk-adapter-core`) already commit to: `urType` + `urData`.
+ *
+ * `urData` is the hex-encoded raw CBOR payload (equivalent to `ur.cbor.toString('hex')`),
+ * NOT a `ur:type/…` bech32-style string and NOT a pre-fragmented animated-QR frame
+ * list. Turning this into single- or multi-part QR frames is a rendering concern the
+ * app/UI layer owns (via `@ngraveio/bc-ur`'s `UREncoder`), not something the engine
+ * or the event payload should bake in — `QrDisplayData.animated` is only a hint that
+ * the payload is large enough to need fragmenting.
+ */
+interface KeystoneUr {
+    urType: string;
+    urData: string;
+}
+interface KeystoneParsedAccount {
+    chain: string;
+    path: string;
+    publicKey: string;
+    extendedPublicKey?: string;
+    /** Per-key source fingerprint, hex. Usually equals the account's masterFingerprint. */
+    xfp?: string;
+    name?: string;
+}
+interface KeystoneParsedMultiAccounts {
+    /** BIP32 master fingerprint of the seed (lowercase hex, 8 chars) — the cross-channel wallet identity. */
+    masterFingerprint: string;
+    /** Model string (e.g. "Keystone 3 Pro"), present on both channels but not unique per unit. */
+    device?: string;
+    /**
+     * Hardware-derived id (sha256(sha256(serial))). Only populated in specific
+     * wallet-branded QR sync menus — firmware omits it on the generic
+     * KeyDerivation path USB uses. Enrichment only; never key identity on it.
+     */
+    deviceId?: string;
+    deviceVersion?: string;
+    accounts: KeystoneParsedAccount[];
+}
+interface KeystoneEthSignRequestInput {
+    requestId: string;
+    /** Hex, no 0x prefix — raw unsigned payload matching dataType. */
+    unsignedTxHex: string;
+    dataType: 'transaction' | 'typedTransaction' | 'personalMessage' | 'typedData';
+    path: string;
+    xfp: string;
+    chainId?: number;
+    address?: string;
+    origin?: string;
+}
+interface KeystoneEthSignatureResult {
+    requestId?: string;
+    r: string;
+    s: string;
+    /** Hex, no 0x prefix. Legacy tx: recovery id/27-28 form. EIP-1559/2930: 0/1 parity. */
+    v: string;
+}
+interface KeystoneBtcSignRequestAccount {
+    path: string;
+    xfp: string;
+    address?: string;
+}
+/**
+ * Standard BIP-44/49/84/86 purpose → script-type mapping. `p2tr` is a
+ * recognized value but `KeystoneUrEngine.deriveBtcAddressFromXpub` doesn't
+ * support it yet — taproot output-key tweaking needs an elliptic-curve
+ * library (`bitcoinjs-lib`'s `initEccLib`) this package doesn't wire in.
+ */
+type BtcScriptType = 'p2pkh' | 'p2sh-p2wpkh' | 'p2wpkh' | 'p2tr';
+interface KeystoneSolSignRequestInput {
+    requestId: string;
+    /** Hex, no 0x prefix. */
+    unsignedPayloadHex: string;
+    dataType: 'transaction' | 'message';
+    path: string;
+    xfp: string;
+    address?: string;
+    origin?: string;
+}
+interface KeystoneSolSignatureResult {
+    requestId?: string;
+    /** Hex, no 0x prefix. */
+    signature: string;
+}
+interface KeystoneBtcSignatureResult {
+    requestId: string;
+    publicKey: string;
+    /** Hex, no 0x prefix. */
+    signature: string;
+}
+/** SLIP-10 for secp256k1 (EVM/BTC) and ed25519 (SOL); Cardano-style BIP32-Ed25519 is out of scope. */
+type KeystoneDerivationCurve = 'secp256k1' | 'ed25519';
+interface KeystoneKeySchema {
+    path: string;
+    curve?: KeystoneDerivationCurve;
+}
+interface KeystoneKeyDerivationRequestInput {
+    schemas: KeystoneKeySchema[];
+    origin?: string;
+}
+interface KeystoneTronSignRequestInput {
+    requestId: string;
+    /**
+     * Hex, no 0x prefix — a standard TRON protobuf `Transaction.raw` message
+     * (the same bytes `TronSignTxParams.rawTxHex` already carries for Ledger).
+     */
+    rawTxHex: string;
+    path: string;
+    xfp: string;
+    origin?: string;
+}
+interface KeystoneTronSignatureResult {
+    requestId?: string;
+    /** Hex, no 0x prefix — 65-byte secp256k1 signature. */
+    signature: string;
+}
+
+/**
+ * Thin wrapper around `@keystonehq/keystone-sdk`. Owns every touch point with the
+ * vendor SDK so the rest of the adapter never imports it directly: same UR
+ * construction/parsing serves both the QR and USB channels (USB carries the
+ * identical UR payloads inside EAPDU framing — see the Keystone USB SDK's
+ * `sendURRequest`), so this engine has no channel awareness at all.
+ *
+ * Deliberately uses the bare constructor, never `KeystoneSDK.create()` — `create()`
+ * fetches remote fragment-size config from keyst.one at call time, which this SDK
+ * must not depend on.
+ */
+declare class KeystoneUrEngine {
+    private readonly sdk;
+    constructor(origin?: string);
+    parseMultiAccounts(ur: KeystoneUr): KeystoneParsedMultiAccounts;
+    parseHDKey(ur: KeystoneUr): KeystoneParsedAccount;
+    /**
+     * Build a `qr-hardware-call` (KeyDerivation) request: the host asks for
+     * specific paths instead of waiting for whatever the device happens to be
+     * showing. The device replies with a `crypto-multi-accounts` UR — parse it
+     * with `parseMultiAccounts`. Used for the implicit "sync this wallet's xfp
+     * before the first sign" round trip as well as an explicit account import.
+     *
+     * `version: V1` is required — verified against real Keystone hardware and
+     * `keystone3-firmware`'s `CheckHardwareCallRequestIsLegal` source: an
+     * unversioned/V0 request is validated as a legacy Cardano-only request
+     * (`m/1852'/1815'/...`) and firmware rejects every other chain's path with
+     * `PRS_PARSING_ERROR` (device-shown message: "路径不受支持" / "path not
+     * supported"), regardless of the path's shape. V1 is what actually enables
+     * the general per-chain path whitelist (includes `m/44'/60'` for ETH, the
+     * standard BTC purposes, etc.). The SDK itself defaults to V0 unless a
+     * truthy `version` is passed — omitting this silently produces a request
+     * every non-Cardano device rejects.
+     */
+    buildKeyDerivationRequest(input: KeystoneKeyDerivationRequestInput): KeystoneUr;
+    /**
+     * Parse the response to a KeyDerivation request (or a device-initiated
+     * account export): `crypto-multi-accounts` for a multi-schema request,
+     * `crypto-hdkey` for a single-key response some firmware paths use instead.
+     * Both are normalized to the same `KeystoneParsedMultiAccounts` shape — a
+     * single `crypto-hdkey` becomes a one-entry account list, with its own
+     * `origin.sourceFingerprint` promoted to `masterFingerprint` (correct for a
+     * key derived directly from the seed, which every request this engine
+     * builds asks for).
+     */
+    parseAccountResponse(ur: KeystoneUr): KeystoneParsedMultiAccounts;
+    buildEthSignRequest(input: KeystoneEthSignRequestInput): KeystoneUr;
+    parseEthSignature(ur: KeystoneUr): KeystoneEthSignatureResult;
+    /**
+     * Derive one EVM address offline from an already-synced account xpub —
+     * verified against the same `@keystonehq/bc-ur-registry-eth` helper the
+     * Keystone-based OneKey air-gap demo uses in production
+     * (`generateAddressFromXpub`), so no unverified assumption about what a
+     * leaf-path KeyDerivation request would return. `relativeDerivePath` is
+     * relative to the xpub's own depth, e.g. `'0/0'` for an account xpub.
+     */
+    deriveEvmAddressFromXpub(xpub: string, relativeDerivePath: string): string;
+    /**
+     * Derive one BTC address offline from an already-synced account xpub, the
+     * same way `deriveEvmAddressFromXpub` does. Keystone's `CryptoHDKey`
+     * always emits standard mainnet-xpub version bytes (`0488B21E`) regardless
+     * of the account's purpose/script type (verified against
+     * `@keystonehq/bc-ur-registry`'s `CryptoHDKey.getBip32Key`, which hardcodes
+     * that version rather than switching to a SLIP-132 ypub/zpub prefix per
+     * script type) — so `hdkey.fromExtendedKey` parses it correctly for every
+     * `scriptType` without needing custom version bytes configured.
+     *
+     * `p2tr` is deliberately not handled: taproot output-key tweaking (BIP-341)
+     * needs an elliptic-curve library wired via bitcoinjs-lib's `initEccLib`,
+     * which this package doesn't set up yet — every other payment function
+     * here needs no such library.
+     */
+    deriveBtcAddressFromXpub(xpub: string, relativeDerivePath: string, scriptType: BtcScriptType): string;
+    buildBtcPsbtRequest(unsignedPsbtHex: string): KeystoneUr;
+    /** Returns the hex-encoded (possibly still-unsigned-in-part) PSBT the device replied with. */
+    parseBtcPsbt(ur: KeystoneUr): string;
+    buildBtcMessageSignRequest(params: {
+        requestId: string;
+        /** Hex, no 0x prefix. */
+        messageHex: string;
+        accounts: KeystoneBtcSignRequestAccount[];
+        origin?: string;
+    }): KeystoneUr;
+    parseBtcSignature(ur: KeystoneUr): KeystoneBtcSignatureResult;
+    buildSolSignRequest(input: KeystoneSolSignRequestInput): KeystoneUr;
+    parseSolSignature(ur: KeystoneUr): KeystoneSolSignatureResult;
+    /**
+     * `@keystonehq/keystone-sdk`'s own bundled `sdk.tron` module is
+     * deliberately NOT used here — see `TronSignRequest.ts`'s doc comment for
+     * why: it's a different (gzip/protobuf) protocol with response semantics
+     * this package has no way to verify, whereas `TronSignRequest`/
+     * `TronSignature` are a direct port of OneKey's own already-proven
+     * production QR-wallet TRON implementation (a plain CBOR-native
+     * sign-request/signature pair, same shape as eth/sol). The device decodes
+     * `rawTxHex` itself — no client-side contract-type pre-parsing or
+     * `tokenInfo` needed, unlike the public SDK's module.
+     */
+    buildTronSignRequest(input: KeystoneTronSignRequestInput): KeystoneUr;
+    parseTronSignature(ur: KeystoneUr): KeystoneTronSignatureResult;
+    /**
+     * Derive one TRON address offline from an already-synced account xpub.
+     * TRON reuses EVM's exact secp256k1-pubkey → keccak256 → last-20-bytes
+     * derivation (verified against Keystone's own `formatAddress()` in
+     * `keystone-sdk`'s TRON chain source) — only the final text encoding
+     * differs (base58check with a `0x41` version byte, not checksummed hex).
+     * Reusing `generateAddressFromXpub` here means no new hashing dependency:
+     * strip its "0x" and re-encode the same 20 bytes.
+     */
+    deriveTronAddressFromXpub(xpub: string, relativeDerivePath: string): string;
+}
+
+interface ImportFromQrOptions {
+    /**
+     * 'request': host asks for specific paths via a `qr-hardware-call`
+     * (KeyDerivation) UR — precise, works regardless of what screen the device
+     * is on. 'scan': just wait for whatever multi-account/HD-key export the
+     * device is already showing. Defaults to 'request' with `paths`, or the
+     * default EVM/BTC/SOL account set if `paths` is omitted.
+     */
+    mode?: 'request' | 'scan';
+    paths?: Array<{
+        hwkChain: ChainCapability;
+        path: string;
+    }>;
+}
+/**
+ * Keystone hardware wallet adapter — QR and USB channels merged behind one
+ * `IHardwareWallet` surface, keyed by the wallet's master fingerprint (mfp):
+ * a caller sees the same `evmSignTransaction(...)` call regardless of which
+ * channel actually carries it. Internally, a chain method's UR round trip
+ * either drives one or two `REQUEST_QR_DISPLAY`/`REQUEST_QR_SCAN` UI events
+ * (QR) or a direct `IConnector.call(sessionId, 'resolveUr', ur)` (USB) — see
+ * `_resolveUr`.
+ *
+ * QR needs no physical enumeration or explicit connect step: a caller can
+ * call any chain method with `connectId`/`deviceId` both null and the
+ * adapter drives its own implicit cold-start sync. USB is the opposite —
+ * WebUSB device pickers require a user gesture, so a USB session only comes
+ * into existence via an explicit `searchDevices()` + `connectDevice()` (see
+ * `_connectUsb`). Once a USB session exists for a wallet's mfp, later calls
+ * for that same wallet route over USB automatically (unless pinned via
+ * `switchTransport`) — matching docs/design/keystone-integration/README.md §4.3.
+ */
+declare class KeystoneAdapter implements IHardwareWallet {
+    readonly vendor: "keystone";
+    private readonly urEngine;
+    private readonly emitter;
+    private readonly _uiRegistry;
+    private readonly _jobQueue;
+    private readonly _devices;
+    private readonly _origin;
+    /** How long to wait for the app to answer a `REQUEST_QR_DISPLAY`/`REQUEST_QR_SCAN` before failing. Defaults to the registry's own 10-minute default. */
+    private readonly _qrTimeoutMs;
+    /** Optional USB `IConnector` — supplied by the host app (DI, same pattern as Trezor/Ledger), e.g. via `createKeystoneWebUsbConnector()` from `@onekeyfe/hwk-keystone-connector-usb`. Undefined means QR-only. */
+    private readonly _usbConnector;
+    /** Explicit `switchTransport` pin. `undefined` means "auto": USB when a live session exists for the target wallet, else QR. */
+    private _forcedTransport;
+    constructor(options?: {
+        origin?: string;
+        qrTimeoutMs?: number;
+        usbConnector?: IConnector;
+    });
+    get activeTransport(): TransportType | null;
+    getAvailableTransports(): TransportType[];
+    /** Pins subsequent calls to 'qr' or 'usb' (routing otherwise defaults to "USB when the target wallet has a live session, else QR" — see `_resolveUr`). Any other value clears the pin back to auto. */
+    switchTransport(type: TransportType): Promise<void>;
+    init(_config?: unknown): Promise<void>;
+    dispose(): Promise<void>;
+    /**
+     * QR-synced wallets are always included (this instance's own state — no
+     * enumeration exists for QR). When a USB connector is configured, its raw
+     * scan results are appended as-is: a USB descriptor has no mfp until
+     * `connectDevice()` actually opens+claims it (see
+     * `KeystoneUsbConnectorBase.searchDevices`), so these entries carry an
+     * empty `deviceId` and exist purely so a host can list "plugged in, click
+     * to connect" candidates.
+     */
+    searchDevices(_options?: SearchDevicesOptions): Promise<DeviceInfo[]>;
+    connectDevice(connectId: string): Promise<Response<string>>;
+    /**
+     * QR has no persistent connection to tear down — the account cache
+     * survives so a later call resumes without re-syncing. For a USB session,
+     * this closes the connector session and either demotes the record back to
+     * QR-only (if it was ever QR-synced) or removes it entirely (pure-USB
+     * wallet that was never seen over QR) — see §4.2 of the design doc.
+     */
+    disconnectDevice(connectId: string): Promise<void>;
+    getDeviceInfo(connectId: string, deviceId: string): Promise<Response<DeviceInfo>>;
+    getSupportedChains(): ChainCapability[];
+    cancel(connectId?: string): void;
+    getChainFingerprint(connectId: string, deviceId: string, chain: ChainForFingerprint): Promise<Response<string>>;
+    uiResponse(response: UiResponseEvent): void;
+    on<K extends keyof HardwareEventMap>(event: K, listener: (event: HardwareEventMap[K]) => void): void;
+    on(event: string, listener: DeviceEventListener): void;
+    off<K extends keyof HardwareEventMap>(event: K, listener: (event: HardwareEventMap[K]) => void): void;
+    off(event: string, listener: DeviceEventListener): void;
+    importFromQr(options?: ImportFromQrOptions): Promise<Response<DeviceInfo>>;
+    allNetworkGetAddress: (connectId: string, deviceId: string, params: AllNetworkGetAddressParams) => Promise<Response<AllNetworkAddressResponse[]>>;
+    evmGetAddress(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<EvmGetAddressParams>>): Promise<Response<EvmAddress>>;
+    evmSignTransaction(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<EvmSignTxParams>>): Promise<Response<EvmSignedTx>>;
+    evmSignMessage(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<EvmSignMsgParams>>): Promise<Response<EvmSignature>>;
+    evmSignTypedData(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<EvmSignTypedDataParams>>): Promise<Response<EvmSignature>>;
+    btcGetAddress(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<BtcGetAddressParams>>): Promise<Response<BtcAddress>>;
+    btcGetPublicKey(_connectId?: NullableCallArg<string>, _deviceId?: NullableCallArg<string>, _params?: NullableCallArg<IHardwareCallParams<BtcGetPublicKeyParams>>): Promise<Response<BtcPublicKey>>;
+    btcSignTransaction(_connectId?: NullableCallArg<string>, _deviceId?: NullableCallArg<string>, _params?: NullableCallArg<IHardwareCallParams<BtcSignTxParams>>): Promise<Response<BtcSignedTx>>;
+    btcSignPsbt(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<BtcSignPsbtParams>>): Promise<Response<BtcSignedPsbt>>;
+    btcSignMessage(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<BtcSignMsgParams>>): Promise<Response<BtcSignature>>;
+    btcGetMasterFingerprint(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>): Promise<Response<{
+        masterFingerprint: string;
+    }>>;
+    solGetAddress(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<SolGetAddressParams>>): Promise<Response<SolAddress>>;
+    solSignTransaction(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<SolSignTxParams>>): Promise<Response<SolSignedTx>>;
+    solSignMessage(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<SolSignMsgParams>>): Promise<Response<SolSignature>>;
+    tronGetAddress(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<TronGetAddressParams>>): Promise<Response<TronAddress>>;
+    tronSignTransaction(connectIdArg?: NullableCallArg<string>, deviceIdArg?: NullableCallArg<string>, paramsArg?: NullableCallArg<IHardwareCallParams<TronSignTxParams>>): Promise<Response<TronSignedTx>>;
+    tronSignMessage(_connectId?: NullableCallArg<string>, _deviceId?: NullableCallArg<string>, _params?: NullableCallArg<IHardwareCallParams<TronSignMsgParams>>): Promise<Response<TronSignature>>;
+    private _mfpFromConnectId;
+    /**
+     * Handles both connectId shapes a caller might hand back: the QR-style
+     * `keystone-qr:<mfp>` prefix, and a bare mfp — which is exactly what a
+     * USB session's `sessionId`/`connectId` is (see `KeystoneUsbConnectorBase`
+     * and `_connectUsb`).
+     */
+    private _findByConnectId;
+    /**
+     * Folds a parsed account-response UR into the device table. `viaUsb`
+     * (defaults false) says which channel actually carried this round trip —
+     * `_resolveUr` routes a KeyDerivation sync over USB when the target record
+     * already has a live session, so this must NOT unconditionally mark
+     * `qrSynced`, or a USB-only wallet would wrongly survive a later USB
+     * disconnect as a "QR-synced, demote to QR-only" entry instead of being
+     * dropped outright (see `disconnectDevice`).
+     */
+    private _upsertDeviceRecord;
+    /**
+     * Opens+claims whatever Keystone the USB connector currently has
+     * permission for, learns its mfp via `getAppConfig`, and merges it into
+     * the device table by that mfp — a QR-synced entry becomes
+     * `{qr, usb}`-capable in place (one `device-changed`, not a second
+     * `device-connect`); a wallet never seen before becomes a new USB-only
+     * entry. See §4.2 of the design doc.
+     */
+    private _connectUsb;
+    /**
+     * The one place that decides QR vs. USB for a UR round trip and carries it
+     * out. `record` is the (possibly not-yet-existing, for a true cold start)
+     * device row for the target wallet — USB is only used when `record`
+     * already has a live `usbSessionId` (a session comes from an explicit
+     * `connectDevice()`, never conjured mid-call — see the class doc). A
+     * `switchTransport('qr')` pin forces QR even for a USB-attached wallet;
+     * `switchTransport('usb')` on a wallet with no live USB session fails
+     * closed rather than silently falling back to QR.
+     */
+    private _resolveUr;
+    /**
+     * Resolve (syncing over QR if needed) the account cached for `hwkChain` at
+     * `syncPath`. Drives the "implicit account sync, then the real request" two
+     * hop flow the first time a wallet/path pair is seen; a cache hit skips
+     * straight to the caller's own round trip.
+     */
+    private _ensureAccountSynced;
+    /**
+     * Like `_ensureAccountSynced`, but for operations (PSBT signing, master
+     * fingerprint) that only need to know WHICH wallet is attached, not a
+     * specific cached path. Syncs the account-level path for `chain` as a
+     * throwaway probe when the mfp isn't already known.
+     *
+     * `CHAIN_FINGERPRINT_PATHS[chain]` is a 5-segment LEAF path for `evm`
+     * (`m/44'/60'/0'/0/0`) — sending that verbatim as a KeyDerivation request
+     * asks Keystone for a non-standard path. Keystone's own docs
+     * (dev.keyst.one's multichain KeyDerivation example) show the ETH
+     * account-level path as `m/44'/60'/0'` (3 segments), same as what
+     * `DEFAULT_IMPORT_SCHEMAS`/`_ensureAccountSynced` already request — so
+     * truncate through `splitAccountPath` here too instead of using the raw
+     * fingerprint leaf path. `btc`/`sol` are already 3-segment account paths
+     * and pass through unchanged.
+     */
+    private _ensureMfpKnown;
+    private _requestQrDisplayAndAwaitResponse;
+    private _requestQrScanAndAwaitResponse;
+    private static _throwIfAborted;
+    private static _assertRequestIdMatches;
+    private _unsupported;
+    private _errorToFailure;
+}
+
+/** `keystone-qr:<mfp>` is the QR-only connectId; a merged USB session gets its own (phase 4). */
+declare const QR_CONNECT_ID_PREFIX = "keystone-qr:";
+declare function qrConnectId(masterFingerprint: string): string;
+interface KeystoneAccountEntry extends KeystoneParsedAccount {
+    hwkChain: ChainCapability;
+}
+declare function accountKey(hwkChain: ChainCapability, path: string): string;
+interface KeystoneDeviceRecord {
+    /** Lowercase hex BIP32 master fingerprint — the cross-channel wallet identity; doubles as `deviceId`. */
+    masterFingerprint: string;
+    connectId: string;
+    /** Model string from the device (e.g. "Keystone 3 Pro"); not unique per unit. */
+    model?: string;
+    deviceVersion?: string;
+    /** Keyed by `accountKey(hwkChain, path)`. Holds whatever was directly synced — usually account-level (3-segment) entries for EVM, exact leaf entries for SOL. */
+    accounts: Map<string, KeystoneAccountEntry>;
+    importedAt: number;
+    /**
+     * Set to the connector's `sessionId` (== this record's own mfp, per
+     * `KeystoneUsbConnectorBase.connect`) once a live USB session exists for
+     * this wallet. Cleared by `disconnectDevice`. Presence of this field is
+     * what `KeystoneAdapter._resolveUr` uses to route a call over USB instead
+     * of QR.
+     */
+    usbSessionId?: string;
+    /**
+     * True once this wallet has completed at least one QR round trip.
+     * Distinguishes "USB session dropped but this wallet was also QR-synced —
+     * fall back to a QR-only entry" from "this was a USB-only wallet that
+     * never synced over QR — drop the entry entirely" on USB disconnect.
+     */
+    qrSynced?: boolean;
+}
+declare function createDeviceRecord(masterFingerprint: string): KeystoneDeviceRecord;
+declare function toDeviceInfo(record: KeystoneDeviceRecord): DeviceInfo;
+/** A device row for a wallet the adapter hasn't synced yet — used while a cold-start round trip is in flight. */
+declare function placeholderDeviceInfo(): DeviceInfo;
+
+/** Always returns an `m/`-prefixed path, regardless of the input's casing/prefix. */
+declare function normalizePath(path: string): string;
+/**
+ * Split a full BIP-44 leaf path (`purpose'/coin'/account'/change/index`, 5
+ * segments) into its 3-segment account path and the relative `change/index`
+ * path from that account to the leaf. Matches the OneKey Keystone air-gap
+ * demo's `removePathLastSegment({removeCount: 2})` convention, which is
+ * verified against real Keystone hardware.
+ *
+ * A path with 3 or fewer segments IS already an account path (or shorter) —
+ * BIP-44's account level is exactly 3 hardened components — so there is
+ * nothing to split off: `relativeDerivePath` is empty and `accountPath` is
+ * the (normalized) input unchanged.
+ */
+declare function splitAccountPath(path: string): {
+    accountPath: string;
+    relativeDerivePath: string;
+};
+/**
+ * Standard BIP-44/49/84/86 purpose → script-type mapping. Returns `undefined`
+ * for a path whose purpose isn't one of these four (or isn't parseable),
+ * rather than guessing.
+ */
+declare function btcScriptTypeFromPath(path: string): BtcScriptType | undefined;
+
+export { type BtcScriptType, type ImportFromQrOptions, type KeystoneAccountEntry, KeystoneAdapter, type KeystoneBtcSignRequestAccount, type KeystoneBtcSignatureResult, type KeystoneDerivationCurve, type KeystoneDeviceRecord, type KeystoneEthSignRequestInput, type KeystoneEthSignatureResult, type KeystoneKeyDerivationRequestInput, type KeystoneKeySchema, type KeystoneParsedAccount, type KeystoneParsedMultiAccounts, type KeystoneSolSignRequestInput, type KeystoneSolSignatureResult, type KeystoneTronSignRequestInput, type KeystoneTronSignatureResult, type KeystoneUr, KeystoneUrEngine, QR_CONNECT_ID_PREFIX, accountKey, btcScriptTypeFromPath, createDeviceRecord, normalizePath, placeholderDeviceInfo, qrConnectId, splitAccountPath, toDeviceInfo };