Evidence hierarchy
Criteria definitions
- Workflow fit: whether the product completes the task stated by the page.
- Cost clarity: whether a reader can find and understand the current price or fee path.
- Safety and control: account protection, permissions, custody, backup, and recovery duties.
- Coverage: support for the reader’s exact region, asset, account, or data source.
- Usability: clear setup, error review, and exit steps.
- Evidence quality: direct, dated, and specific support for each material claim.
Weighting and scoring policy
Research process
- Define the reader task and region.
- Open the official agreement, fee or price page, help center, and security material.
- Record what the source says and its access date.
- Test only claims that can be checked without exposing private data or funds.
- Write the limits beside the capability.
- Run the final copy through the Token Metrics Blog & SEO editorial review before publication.
Freshness and update policy
Limitations and conflicts
Worked example
Frequently asked questions
Do you rank by affiliate payout?
No. Compensation must not change the evidence rule or product order.
Why are some numbers omitted?
Can a product be called safe?
How can a reader challenge a finding?
The recovery test comes before the feature score
A hardware wallet is evaluated as a custody process, not only as a device. The test begins with official setup and backup instructions for Ledger, Trezor, or Tangem. Reviewers record what must be protected, how backups are created, and what a user needs to recover after loss or damage. Vendor procedures differ, so one product’s recovery assumptions are never copied into another product’s score.
A repeatable test sequence
- Initialize a reset test device through the official workflow and record every backup warning.
- Receive a small amount to an address verified on the trusted device or card process.
- Send part of it back while checking the destination through an independent channel.
- Reset or remove access, then follow the documented recovery procedure with no funds beyond the test amount.
- Confirm the restored wallet derives the expected account and can complete a final small transaction.
A product fails the recovery criterion when the reviewer cannot explain which backup is authoritative, cannot repeat the official procedure, or must make an unsupported assumption. A successful app screen alone is not enough.
Limits on compatibility and security claims
Asset support is checked against the current vendor list for the exact device and companion software. A token name on a broad marketing page does not prove the required network or transaction path works. Security is also stated narrowly. A hardware wallet can reduce exposure of signing secrets, but it cannot prevent phishing, a wrong address, a compromised backup, or user approval of a malicious transaction.
How evidence changes a result
The record stores the device model, software version when visible, official source, access date, steps, and observed result. Material firmware, backup, or compatibility changes trigger a retest. If a procedure cannot be completed, the limitation remains visible rather than being replaced by a numeric guess. This makes recovery clarity and transaction verification more important than the length of a feature list.
Plain test note
The safe note has no secret words. It names the test coin and chain. It says how the address was checked. It marks each pass and fail. It also states what was not tried. A reader can then see the limit of the result. If the steps are hard to grasp, the method needs more work before it can guide a large move.
Sources checked
- https://support.ledger.com/
- https://www.ledger.com/academy/basic-basics/2-how-to-own-crypto/whats-a-secret-recovery-phrase
- https://trezor.io/learn
- https://trezor.io/learn/basics/what-is-a-hardware-wallet
- https://tangem.com/en/help-center/
Use this method in your next comparison
Build the custody process before funding
Practice the full transaction loop
Recovery questions to answer
- Can I explain what the backup restores?
- Can I recover without help from a stranger?
- Who could find or copy the backup?
- What happens if my phone or computer fails?
- How will a trusted person act in an emergency without exposing the backup now?
How corrections are handled
Evidence notes to keep
Prepared by Token Metrics Research Team
Evidence accessed: 2026-07-14. Product terms can change; verify dynamic terms before acting.
Editorial disclosure: This material is educational and does not give investment, tax, legal, or custody advice. Compensation from a link does not control the method or verdict.
Reproducible evaluation protocol
A reviewer records model, firmware, purchase channel, setup path, address-verification path, backup format, recovery rehearsal, supported asset path, companion software, and incident disclosures. Two reviewers independently score the evidence, resolve differences against official documentation, and archive dated URLs.
- Freeze scope: record product, plan/model, jurisdiction, interface, and test date.
- Archive evidence: save the official URL, access date, relevant passage, and observed screen for each input.
- Run the fixture: use the same scenario and expected result for every candidate.
- Score independently: two researchers assign factor values from the evidence, then resolve disagreements in writing.
- Calculate: multiply each 0–100 factor value by its declared weight and sum; round only the final result to the nearest whole number.
- Fail closed: do not publish a number when a required input is unknown or a must-have safety check fails.
Freshness and correction rule
For hardware wallet methodology, keep the method clear. Set the scope. Use one date. Check each fact. Save each source. Run the same test. Log each gap. Show the math. State each limit. Update changed facts. Stop if proof is missing.
Keep the final check simple for hardware wallet methodology. Check the need. Check the source. Check the date. Test the task. Save the result. Name the risk. Set a stop rule. Do not fill gaps with hope. Decide from the record.
Material evidence and source map
- Recovery evidence is scored from the vendor’s documented backup procedure, not a generic claim that the device is “cold.” Official source (accessed 2026-07-14).
- Asset support is verified for the exact network, token, device, and required companion app. Official source (accessed 2026-07-14).
- A card-based backup workflow is evaluated differently from a phrase-and-screen device because loss and recovery paths differ. Official source (accessed 2026-07-14).
Evidence note 1: hardware wallet methodology
Recovery evidence is scored from the vendor’s documented backup procedure, not a generic claim that the device is “cold.” For this page, that evidence sets a must-have check before the user pays or moves value. A reader should open the cited page, record the relevant product, plan, model, location, or interface, and save the date. Then the reader should test the narrow workflow described here. If the documented path and the observed path differ, the observed exception stays unresolved and the recommendation pauses. This rule prevents a broad brand claim from replacing a product-specific decision.
Evidence note 2: hardware wallet methodology
Asset support is verified for the exact network, token, device, and required companion app. For this page, that evidence defines a live trial that can disprove the recommendation. A reader should open the cited page, record the relevant product, plan, model, location, or interface, and save the date. Then the reader should test the narrow workflow described here. If the documented path and the observed path differ, the observed exception stays unresolved and the recommendation pauses. This rule prevents a broad brand claim from replacing a product-specific decision.
Evidence note 3: hardware wallet methodology
A card-based backup workflow is evaluated differently from a phrase-and-screen device because loss and recovery paths differ. For this page, that evidence shows which record or control the user must retain for an independent review. A reader should open the cited page, record the relevant product, plan, model, location, or interface, and save the date. Then the reader should test the narrow workflow described here. If the documented path and the observed path differ, the observed exception stays unresolved and the recommendation pauses. This rule prevents a broad brand claim from replacing a product-specific decision.
A falsifiable decision record for hardware wallet methodology
A reviewer records model, firmware, purchase channel, setup path, address-verification path, backup format, recovery rehearsal, supported asset path, companion software, and incident disclosures. Two reviewers independently score the evidence, resolve differences against official documentation, and archive dated URLs. Write down the expected result before the test. Keep the source URL, access date, chosen settings, observed output, and any error or manual correction. Define a stop rule as well. A missing must-have feature, unexplained total cost, failed recovery or withdrawal, incomplete record import, or unsupported location is a reason to stop. The page’s verdict changes when that evidence changes; familiarity with the brand is not a substitute.
Plain-language field check for hardware wallet methodology
Use this check for hardware wallet methodology. Start small. Open each source. Note its date. Save the key terms. Name your exact task. List each must-have. Mark each unknown. Test one normal case. Test one hard case. Try the exit path. Keep the result. Count the full cost. Note each warning. Do not guess. Do not share secrets. Stop when a core fact is missing. Ask support a clear question. Save its reply. Repeat the test after a major change. Choose only when the evidence fits your task. Keep your own copy of the record.
Continue within this topic
For hardware wallet methodology, use Best hardware wallets and Hardware-wallet comparison to compare this decision with the cluster methodology and alternatives.
