I own two Ledger hardware wallets, but I rarely use either of them. Security was not the problem. The interaction was. A small screen, clipped addresses, and unclear signing prompts made each transaction feel harder to verify than it should.
OneKey contacted me a few months ago and offered to send me a OneKey Classic 1S (opens in a new tab) to review. I used it for a month, starting with a fresh wallet and ending with a contract deployment from Foundry.
This is not a security audit or a comparison of every hardware wallet. It is a record of what I set up, what worked, and where the workflow broke.
Review unit
OneKey sent me the Classic 1S so I could test it and write about my experience. The opinions in this post are mine.
The Classic 1S has a 1.54-inch monochrome display, four hardware buttons, USB-C, Bluetooth, a 110 mAh battery, and an EAL6+ secure element. OneKey lists support for more than 30,000 assets, but I focused on the parts I would actually use:
- creating and backing up a new wallet;
- pairing it with the OneKey app on mobile and desktop;
- verifying a receive address on the device;
- sending a small ETH transfer on Base; and
- deploying a contract to Sepolia with Foundry.
The box includes the wallet, a USB-C cable, recovery sheets, and a short start guide. The device itself is thin and feels closer to a thick bank card than the USB-stick shape I associate with hardware wallets.
The device, its retail box, and the green recovery-sheet and start-guide envelopes I found inside.
The layout is easy to understand without the manual. The tradeoff appears when a transaction spans many pages.
The setup runs entirely on the device before it connects to the OneKey app. It starts with a choice of nine interface languages, which was more than I expected from the monochrome device.
After choosing English, I created a fresh wallet for the review. The next screen offered 12, 18, or 24 recovery words. I used 24 for this test wallet.
Setup starts on the wallet itself. The interface offered nine language options.
I created a new wallet rather than importing one of my existing recovery phrases.
The device offered 12, 18, and 24-word recovery phrases. I used 12 for this test wallet.
The wallet first showed each recovery word on its own, then grouped six words on one screen for another check. It finished by asking me to select the correct word for each position. This took longer with only up and down buttons, but the extra friction made sense here. The wallet verified the backup instead of only asking me to confirm that I had written it down.
Keep the recovery phrase offline
Never photograph, upload, or type the recovery phrase for a wallet that will hold assets. The recovery screens below are included only to show the setup flow.
Each recovery word appeared individually with its position.
The wallet then grouped six words on one screen for a second visual check.
The final check asked me to select the word that belonged at a specific position.
Only after the word checks did the device mark the backup as complete.
The next screen asked for a four to nine-digit PIN. Once it was confirmed, the wallet showed its identifier, K5981, along with Bluetooth and battery status.
The PIN can be between four and nine digits.
The device confirms the PIN before continuing.
At this point the wallet itself was ready, before I had paired it with a phone.
My wallet appeared as K5981, with Bluetooth and battery indicators in the top-right corner.
I paired the wallet with the OneKey app (opens in a new tab) on my iPhone first. The app found K5981 over Bluetooth, matching the identifier on the device.
The next screen checked the firmware and offered a separate Check my OneKey action during onboarding.
I selected the Classic 1S, connected to K5981 over Bluetooth, and reached the firmware and authenticity checks.
The Genuine Check required confirmation on the wallet before contacting OneKey's secure server. According to OneKey's authenticity documentation (opens in a new tab), it verifies the device serial number. It is useful during onboarding, but it is not the same as independently auditing the hardware or firmware.
The authenticity check required confirmation on the trusted display, not only in the phone app.
Once the check passed, the app showed Your wallet is ready and created the account.
The mobile app completed pairing after the device check passed.
Bluetooth was consistently fast on my phone. My desktop experience was less predictable: connections took longer and occasionally dropped, so I stopped trying to keep the workflow wireless and used USB-C for Foundry. The cable removed the convenience, but it also removed the uncertainty.
The app also includes monochrome wallpapers and accepts a custom image. I did not expect to care about this on a hardware wallet, but I ended up using it.
The wallpaper picker includes built-in monochrome art and a custom-image option.
by far one of my favorites would be this space illustration.
The space wallpaper I kept on the device for the rest of the test.
The account list exposed Bitcoin, Lightning, Ethereum, Tron, Solana and many other ecosystem addresses on the same page.
A single hardware wallet account exposed addresses for the major networks shown here.
The part I cared about was the receive flow. Selecting Ethereum did not immediately expose a copy button. The app showed Confirm on device and waited for the Classic 1S.
The app paused the receive flow until I checked the Ethereum address on the wallet.
The full hexadecimal address wrapped across two lines on the wallet, with a second view for its QR code. This is the interaction I had been missing on my older wallets: enough space to inspect the complete address on a display outside my phone or laptop.
The complete Ethereum address was visible across two lines on the trusted display.
The same address could be switched to a full-screen QR code.
This does not make address poisoning or clipboard replacement disappear. I still have to compare what is on both screens. The improvement is that the wallet gives me enough information to make that comparison instead of reducing it to the first and last few characters.
For the first transaction, I sent 0.0001 ETH on Base to my ENS name: envoy1084.eth.
The desktop app resolved the name to 0xc0d...081fe6. Its summary showed the Base network, sending account, amount, resolved recipient, and estimated fee before asking for confirmation.
I started with 0.0005 ETH in the hardware wallet account.
The recipient field resolved envoy1084.eth before I moved to the transaction summary.
The final app summary showed Base, 0.0001 ETH, the resolved address, and the estimated fee.
After confirmation, the transfer appeared in recent activity.
The Classic 1S did showed Base Transaction and the resolved hexadecimal address, followed by separate pages for the amount, maximum fee, and total.
The details were available, but spread across several button presses. That was manageable for a transfer and slower for the contract deployment later.
The wallet identified Base and showed the resolved recipient address, not the ENS name.
The amount page showed the 0.0001 ETH transfer value.
A separate page exposed the maximum fee before signing.
The total combined the transfer amount with the maximum fee.
Only after those detail pages did the wallet ask for the final signature.
The more useful test was contract deployment. I do not want a production deployer key sitting as plaintext in a .env file, so I wanted to see whether the Classic 1S could fit into my existing Forge workflow.
I created a small Counter contract and connected the wallet through Foundry's Trezor-compatible signer path:
I connected the wallet over USB-C and got an insufficient funds error even though the selected Sepolia account had enough ETH.
Adding --legacy made the same deployment work, so I initially suspected OneKey's EIP-1559 support. The device was not the problem.
The failure was inside the Alloy Trezor signer used by Foundry. It selected the EIP-1559 path by checking for one concrete Rust transaction type. Foundry wrapped the transaction in a different type, so Alloy used the legacy signing path instead. The signature was attached to an EIP-1559 envelope and recovered to a different sender with no balance. That is why the RPC reported insufficient funds.
Alloy pull request #3958 (opens in a new tab) changed the dispatch logic to use the EIP-2718 transaction type instead of a concrete Rust downcast. Until that change reached the Foundry build I was using, there were two practical options:
- add
--legacyto the script command; or - install a Foundry nightly that included the Alloy fix.
I installed a Foundry nightly containing the Alloy fix and reran the original command without --legacy. Forge completed the deployment and returned the Counter address.
The Counter deployment used Forge's Trezor signer path with the Classic 1S connected over USB-C.
After moving to a nightly with the Alloy fix, the EIP-1559 deployment completed without --legacy.
The device first warned that chain ID 11155111 was an unknown EVM chain.
It then showed the zero address as the recipient, which is expected for contract creation, followed by the amount, total, and View Data (509 bytes). The data view displayed the deployment calldata as pages of hexadecimal bytes before the final prompt.
The device did not name Sepolia. It warned about an unknown EVM chain and showed chain ID 11155111.
Contract creation appeared as a transaction to the zero address.
The detail pages included the deployment total before exposing the calldata.
The wallet exposed all 509 bytes, but only as raw hexadecimal calldata.
The final prompt asked me to sign the EVM transaction after reviewing the preceding pages.
The confirmed Sepolia transaction is visible on Etherscan (opens in a new tab).
The final transaction created the Counter contract on Sepolia from the expected wallet address.
The address-verification flow was the feature I appreciated most. The display showed the full receive address, then exposed the resolved recipient, amount, and fee when sending funds.
A smaller detail appeared during PIN entry. The selected digit did not always start at the same number. In the two attempts below, one started at 5 and the other at 9, so the same button sequence does not map to a fixed PIN.
The PIN entry started on different digits in separate attempts, so the same button sequence does not reveal the same number.
When a connected app requested the PIN, the device also showed a shuffled number grid. The layout stayed on the trusted display instead of appearing as a normal keypad on the computer.
The shuffled grid kept the PIN layout on the wallet rather than exposing it on the connected computer.
The four-button interface is easy to understand, but slow to repeat. Setup and a basic transfer were fine. A deployment required an unknown-chain warning, transaction details, multiple data pages, and a final signature.
Bluetooth was reliable on my phone and inconsistent on desktop. USB-C solved the connection problem, but removed the convenience of using the wallet wirelessly.
The 110 mAh battery lasted around one to one and a half hours in my continuous-use test. Normal sessions will be longer because the wallet sleeps between actions, but I could not find a way to change the sleep timeout. I would treat it as enough for a mobile signing session, not as all-day power.
The Foundry failure was frustrating because the visible clues pointed in the wrong direction. It was not a OneKey firmware bug, but it showed how the device, signer library, transaction type, and CLI version all need to agree.
After a month, the Classic 1S is still on my desk rather than in the drawer with my older wallets. Phone pairing was quick, the receive flow showed full addresses, and it signed a real Forge deployment once the Alloy issue was fixed.
I would not choose its four-button screen for inspecting complex contract calls. Raw calldata is still raw calldata, desktop connectivity was less reliable than mobile, and the battery is best suited to short sessions.
The Foundry test mattered more to me than the asset count, That is why I kept using it after the review period.
