The wallet built into Searxly is real self-custody — standard BIP-39 keys, generated and encrypted on your Mac, signing every transaction locally. We hold nothing. We can't see your phrase, we can't move your funds, and there's no server that could.
Your wallet starts as a standard 12/24-word BIP-39 recovery phrase. From it, keys are derived with BIP-32 hierarchical derivation at the standard Ethereum path, so the same phrase restores your accounts in MetaMask or any standard wallet. The seed is then encrypted and locked away — it only ever decrypts in memory, for the instant it takes to sign.
m/44'/60'/0'/0/x derivation — portable everywherem/44'/60'/0'/0/x · one phrase, every accountm/44'/60'/0'/0/xWhenUnlockedThisDeviceOnly, non-syncableKeeping keys on-device is the foundation. On top of it sits a stack of controls aimed at the realistic attacks — a stolen prefs file, a malicious dApp, a look-alike address.
The PIN is verified by decrypting the seed, not against a fast hash an attacker could brute-force offline. Five wrong tries triggers an escalating cooldown (30s → up to 15m) with a live countdown.
Touch ID unlock is gated by the Secure Enclave with .biometryCurrentSet, so the key is invalidated if fingerprints change. On hardware without an Enclave, a PIN-only seed is refused in favor of a passphrase.
Before any connect or signature, the origin is checked against a local scam blocklist plus a punycode / homograph heuristic. A flagged site gets a loud red banner and a deliberate "connect anyway" override.
Pending transactions are dry-run against the chain first. If the real transaction would revert, you're warned "likely to fail — you'd still pay gas" before you sign, not after.
Approvals are decoded locally into what they actually do — "Send 1.0 SEARXLY to 0x…", or a bright warning on an unlimited token allowance — so you're never blind-signing opaque calldata.
A built-in allowance manager lists what you've approved (unlimited grants first) and revokes any of them in a click — the cleanup that drains so often exploit.
A recipient that mimics the first- and last-four characters of an address you've actually sent to — the classic poisoning trick — is flagged and needs an explicit acknowledgement.
The injected provider only answers on standard tabs once you've connected; every sign/send is bound to the requesting origin (taken from the frame, never page-supplied), and eth_sign is refused outright.
Optionally give every site its own fresh address from a hidden derived pool, so on-chain watchers can't link your activity across dApps — and switching accounts never changes what a connected site sees.
Self-custody isn't a setting — it's the absence of a capability. There is no server, no escrow, and no recovery backdoor on our side. The flip side is real responsibility: your recovery phrase is the only way back in, so back it up offline and never share it.
How keys are stored at rest→Your holding is your membership — proven by a signature, never parked on our servers.