Cryptnox supports USDX only as the ERC-20 representation on Kava EVM, after you add the Kava EVM network or add the USDX token in the app. It does not hold native Kava/Cosmos-SDK USDX. For the supported Kava EVM route, USDX uses a 0x-prefixed 20-byte EVM address, while the private keys are generated inside the secure element and never leave it.

USDX needs a chain-route check before it is sent to a Cryptnox wallet. The canonical asset is native to the Kava Cosmos-SDK chain, while ERC-20 representations can exist on Kava EVM through Kava’s internal bridge model. Cryptnox support is for the EVM side only: the ERC-20 representation of USDX on Kava EVM, if that representation has been converted or deployed there.
That distinction matters because the ticker alone is not enough. A sender, bridge, or Web3 interface must be using Kava EVM for the ERC-20 representation before the Cryptnox card is the right destination. Native Kava/Cosmos-SDK USDX is not the Cryptnox holding route, even though it shares the same USDX name.
Kava describes its internal bridge as the connection between the Cosmos-SDK side and the EVM side of Kava, which is why USDX should be treated by chain route rather than ticker alone; the technical distinction is explained in Kava’s internal bridge deep dive.
The Cryptnox Crypto Hardware Wallet – Dual-Card Set ships uninitialised, so USDX is not waiting on the cards as a preloaded asset. After initialising the set, add the Kava EVM network or add the USDX token so the app can display the ERC-20 representation on Kava EVM. Adding the token view is still tied to the EVM route; it does not add native Kava/Cosmos-SDK USDX.
Before sending funds, check the asset and network information on the Cryptnox coin and blockchain support page. USDX is a case where that check matters because the Kava asset name can appear in more than one technical context, while the Cryptnox holding path is the ERC-20 representation on Kava EVM.
Use the Cryptnox hardware wallet tutorials before adding USDX if you want to prepare the card and app flow first. For this asset, the setup goal is specific: initialise the two-card wallet, add Kava EVM or the USDX token route, and receive only to the 0x-prefixed EVM address for the Kava EVM representation.
The supported USDX route uses an EVM address: a 0x-prefixed 20-byte address for the Kava EVM representation. That address format is part of the asset route. If a sending service is preparing a native Kava/Cosmos-SDK USDX transfer, it is not using the Cryptnox route for this asset.
For USDX, the network selection should be checked before relying on the token label. The correct combination is USDX as an ERC-20 representation on Kava EVM, sent to a 0x-prefixed EVM address controlled by the Cryptnox card keys. A native Kava/Cosmos-SDK route is a different technical path.
This is also why USDX should not be treated like a generic EVM token without checking its Kava origin. The asset’s canonical form is native to the Kava Cosmos-SDK chain, and the Cryptnox holding route depends on the EVM representation being available on Kava EVM. When the sender, network, token standard, and address format all match Kava EVM, the card can be used for the USDX holding path described here.
If you keep several networks in the same portfolio, give USDX its own receiving check. A 0x-prefixed address is appropriate for the Kava EVM representation, but the same ticker on a native Kava/Cosmos-SDK path should not be sent to that address.
When you hold the ERC-20 representation of USDX on Kava EVM with Cryptnox, the relevant private keys are EVM private keys. Those private keys are generated inside the secure element and never leave it. The card platform uses an EAL6+-certified chip, which is the chip property behind the hardware key-storage model.
The card is a contact and NFC smart card. For a USDX transfer on Kava EVM, that means you can tap the card to a phone for the app flow or insert it into a reader when using the contact interface. The form factor does not change the asset route: USDX remains supported only as the Kava EVM ERC-20 representation.
Unlocking the app flow uses the phone’s fingerprint or face unlock through the Cryptnox app. The card itself has no fingerprint or face sensor. For USDX, that separation is important: the phone helps unlock the app workflow, while the card secure element is where the EVM private keys for the Kava EVM address are created and kept.
The product built around this two-card, secure-element model is the Cryptnox Crypto Hardware Wallet – Dual-Card Set. For USDX buyers, the practical result is a card-held EVM key controlling the Kava EVM ERC-20 representation, not custody of native Kava/Cosmos-SDK USDX.
The Dual-Card Set ships uninitialised. During setup, the seed is generated inside both secure elements, so the second card is the backup for the same wallet setup. For USDX on Kava EVM, that means the backup card belongs to the same wallet setup used for the 0x-prefixed EVM address.
By default, there is no recovery phrase to write down. The backup is the second hardware card created during the same setup process. Importing an existing BIP39 recovery phrase is an advanced option, not the default setup for a new Dual-Card Set.
The second card backs up the wallet setup, not the token listing in every app screen. If you later use the backup card for USDX, the app still needs the Kava EVM network or the USDX token route so the ERC-20 representation is visible. The unsupported native Kava/Cosmos-SDK asset does not become supported because a second card exists.
Keep the two cards separate after initialisation. For a Kava EVM USDX holding, the useful backup is a second card tied to the same secure setup, while the app view should still be checked for the correct Kava EVM token route before receiving funds.
The free Cryptnox app is available on iOS and Android, connects to Web3 through WalletConnect, and works with MetaMask. For USDX, those Web3 flows apply to the ERC-20 representation on Kava EVM. They do not make native Kava/Cosmos-SDK USDX a Cryptnox holding route.
When using a Web3 interface, select the network path that matches Kava EVM before signing. If the interface shows USDX but asks for a native Kava/Cosmos-SDK destination, that is the wrong route for this card. If the interface uses the ERC-20 representation on Kava EVM, the receiving address should be the 0x-prefixed EVM address controlled by the Cryptnox card.
If you are comparing hardware-wallet coverage before choosing a setup, start from the Cryptnox crypto hardware wallet collection and then verify the USDX route before funding a Kava EVM address.
USDX on Kava EVM should be checked separately from other assets in the same portfolio because its holdable form is an ERC-20 representation of a Kava Cosmos-SDK stablecoin. Do not copy USDX assumptions across chains. The address format, network route, and token standard must match the asset.
A TRON holding has different network assumptions from USDX on Kava EVM, so the Cryptnox hardware wallet page for TRON should be checked on its own terms. Bitcoin is further from the USDX EVM route; use the Cryptnox hardware wallet page for Bitcoin when the holding is BTC rather than a Kava EVM token.
If you are comparing EVM-related holdings, the Cryptnox hardware wallet page for Polygon is a useful contrast because each EVM network still has its own asset route and receiving assumptions. The same card form factor can be used across supported holdings, but USDX still requires the Kava EVM ERC-20 representation and a 0x-prefixed 20-byte EVM address.
The right Cryptnox purchase decision for USDX depends on the route you intend to use. Choose the Dual-Card Set when you want a Swiss-engineered contact and NFC smart card setup for the Kava EVM ERC-20 representation, with private keys generated inside the secure element and kept there.
Buy the set from the Cryptnox Crypto Hardware Wallet – Dual-Card Set product page, then complete setup before adding USDX. The card choice and the token route need to match: Cryptnox hardware for Kava EVM ERC-20 USDX, not native Kava/Cosmos-SDK USDX.
No. Cryptnox supports USDX only as an ERC-20 representation on Kava EVM, if that representation has been converted or deployed there. Native Kava/Cosmos-SDK USDX is not the supported route. Before receiving funds, confirm that the sender is using Kava EVM and a 0x-prefixed EVM address.
No. The Dual-Card Set ships uninitialised, and USDX is not pre-programmed. After setup, add the Kava EVM network or add the USDX token route in the app. The supported asset is the ERC-20 representation on Kava EVM, not the native Cosmos-SDK stablecoin.
Use a 0x-prefixed 20-byte EVM address for the Kava EVM representation of USDX. That address format belongs to the supported ERC-20 route. If a sender asks for a native Kava/Cosmos-SDK destination for USDX, it is not using the Cryptnox-supported route.
During initialisation, the seed is generated inside both secure elements in the Dual-Card Set. The second card is the backup for the same wallet setup. If you use the backup card later, the app still needs the Kava EVM network or USDX token route to display the holding.
No. The card itself has no fingerprint or face sensor. Unlocking the app flow uses the phone’s fingerprint or face unlock through the Cryptnox app. The private keys for the Kava EVM USDX route are generated inside the card secure element and never leave it.
Yes. The free Cryptnox app connects to Web3 through WalletConnect and works with MetaMask. For USDX, that applies to the ERC-20 representation on Kava EVM. It does not add support for native Kava/Cosmos-SDK USDX, so check the selected network before signing.
EAL6+ refers to the chip platform used in the card: an EAL6+-certified chip. For USDX buyers, the practical security point is that the EVM private keys for the Kava EVM representation are generated inside the secure element and never leave it.
No, and on this network that is not a limitation. The Cryptnox wallet uses one address per chain. HD address rotation comes from Bitcoin’s UTXO model and the BIP32/BIP44/BIP49/BIP84 derivation scheme; on account-model networks each account is a single fixed address by design, so the question does not apply in the same way. Cryptnox’s single-address-per-chain behaviour matches how these networks work.
At the cryptography layer the card derives keys along BIP32 and SLIP-10 paths, one path per supported chain, though that is not exposed in the app as multi-address management.