Inputs & formats guide

What you can provide — and how we route it

This is an operational guide to inputs the web flow can classify and validate. Complex recovery runs in the desktop tool — coverage depends on wallet type, export format, and data completeness.

Input types

Provide one input method at a time. The router will identify network family and suggest the next step based on structure.

Backup containers

Accepted web formats: ZIP / JSON / DAT / TXT. The web flow performs format checks and tries to extract recognizable fragments (wallet JSON, encrypted blobs, keystore fragments) where available.

ZIP — often contains multiple exports; keep original structure.
JSON — wallet exports / keystore formats; may be encrypted.
DAT — legacy wallet databases or app-specific blobs.
TXT — text exports; may include WIF/xpub/notes (do not include seed phrases).
Tip
If a backup is password-protected, keep the file unchanged. The router can still classify format and suggest the correct desktop path.

Address / Wallet ID

Use this when you don’t have a backup file. Addresses and IDs are primarily used for routing: identifying likely network family and prompting the correct capture method.

Address — helps infer chain family and script type patterns (where applicable).
Wallet ID — some apps use internal IDs; useful for locating export instructions.
Backup name — useful when users remember filenames or export labels.

Note: address-only input cannot reconstruct missing keys. It’s used to route you to the right export or desktop workflow.

Key material (advanced)

In compatible scenarios, the routing layer can recognize certain key artifacts and guide the correct next step. This is not a request to paste secrets — keep inputs minimal and structured.

WIF xpub / ypub / zpub Descriptors PSBT
Never paste seed phrases
Seed phrases in plain text are not accepted. If your only source is a seed phrase, use your wallet’s official restore flow or the desktop tool’s guided capture method.

Derivation paths

Only what you need: purpose → script type. Coverage depends on wallet export format and whether derivation metadata is present.

Path template

m / purpose' / coin_type' / account' / change / index
purpose — indicates script type: 44 (Legacy), 49 (SegWit), 84 (Native SegWit), 86 (Taproot)
coin_type — chain identifier (e.g., 0 for BTC, 60 for ETH)
change — 0 for receive, 1 for change (common source of “missing funds”)

Quick examples

BTC Native SegWit (BIP84)
m/84'/0'/0'/0/0
BTC SegWit (BIP49)
m/49'/0'/0'/0/0
EVM account (common)
m/44'/60'/0'/0/0

If you don’t know your path: the router can infer likely families from export schemas and suggest the correct desktop path.

Multisig & PSBT

Multisig recovery requires sufficient cosigner material. PSBT is a transport artifact — useful for analysis and guidance, not a substitute for keys.

What is typically required

Policy — m-of-n threshold and script type (often BIP48 for BTC multisig)
Cosigners — xpubs (or equivalent) for each signer, plus derivation metadata when available
PSBT — can help confirm the policy and locate missing parts (BIP174)
Important
Without enough cosigner material, recovery execution is not possible. The web flow can still classify the scenario and route you to the correct desktop workflow or wallet-specific export steps.

Output descriptors

Descriptors describe spending conditions. When available, they improve routing precision and migration confidence.

Why descriptors are useful

Descriptors capture script type and key origins in a structured, machine-readable form — often the most reliable “handoff” for recovery or migration.

Single-sig examples
pkh(...)
sh(wpkh(...))
wpkh(...)
tr(...)
Multisig (conceptual)
wsh(sortedmulti(m, xpub1, xpub2, ...))

Execution still depends on having sufficient key material and correct origins. The router uses descriptor structure as a strong compatibility signal.

Data handling

Keep inputs minimal, structured, and aligned with the workflow.

Never paste seed phrases
Seed phrases in plain text are not accepted anywhere in the web flow.
Structured intake & routing
Inputs are used for structured intake and routing. Recovery execution depends on export format and data completeness; retention policy is documented in the desktop tool workflow.
Next step
If you’re unsure what to provide, start with Search (address / wallet ID / filename). For complex cases, use Desktop for offline analysis and legacy handlers.