Sparrow Silent Payments Not Supported? Check the Server

Sparrow’s “This server does not support silent payments” means its current server connection has not established the required scanning capability. A synced Bitcoin Core node or a working ordinary Electrum connection does not establish that capability. Check which endpoint Sparrow reaches before changing your wallet.

The clue comes from a first-hand Sparrow report. One reader asked how to enable Silent Payments on a node. Another already had a synced node and Frigate, yet saw the same warning. Their backend log identified a different problem: server.features returned a method-not-found error. Those cases need different answers.

Check the server route before the wallet

Sparrow’s official connection guide shows Settings → Server, with Public Server, Bitcoin Core and Private Electrum choices. Read your existing selection and endpoint; this check does not require changing servers or connecting to an unfamiliar provider.

Documentation screenshot from Sparrow’s connection guide, with its example user path redacted. It illustrates server types, not a Silent Payments connection or a HideFi wallet test. Sparrow is licensed under Apache 2.0.

For an Electrum setup, ask its operator whether the client-facing endpoint provides Silent Payments scanning. Frigate’s documented topology puts Frigate in front of a separate Electrum backend. Reaching that backend directly is a different route, even when both services use the same machine. Port numbers alone do not prove which service answered.

If your actual error is a missing Bitcoin Core authentication cookie, use the separate cookie-file path checks. That is an authentication problem, not evidence that Silent Payments support is available.

What a compatible server must advertise

HideFi checked the released Sparrow 2.5.6 source on November 13, 2026. Its capability check requires version 0 in the server’s advertised Silent Payments versions. Its connection code reads those features and raises the warning when support is unavailable.

The Frigate protocol documentation identifies the relevant response field as silent_payments: [0]. This is a protocol-field illustration, not a captured response from your node. Have the operator check the negotiated connection and capability response using their existing tools. A server name or a successful ordinary balance lookup is insufficient.

If the expected capability is present but Sparrow still reports the warning, keep the exact Sparrow version, endpoint route and redacted error together. The field alone does not diagnose a later scan failure or prove that history is complete.

Why the old Frigate workaround may not fit

The May 2026 discussion involved Frigate 1.5.2, Sparrow 2.5.0 and mempool electrs 3.3.0. The collaborator explained the backend’s missing server.features method and said a later Frigate version would provide its own response in that case. A participant’s custom-build workaround is historical evidence, not a recipe every current installation needs.

The released Frigate 1.6.1 implementation contains that fallback: it handles the backend’s method-not-found response and returns local features including version 0. Other backend errors are rethrown. An operator on an older build should compare their installation with the official release and deployment guidance before rebuilding or changing backend discovery settings. This source match does not guarantee an update resolves every installation.

Keep capability and scan readiness separate

Frigate’s setup guidance also requires its own index to catch up before serving Silent Payments queries. Core being synced does not establish that Frigate’s index is ready.

There is a privacy boundary too: Frigate’s scanning protocol accepts a scan private key. Do not paste it, wallet credentials or full logs into a support post, or switch to an unknown server just to remove the warning. The bundled scan CLI can prompt for that key; it is not needed for the capability comparison described here.

The useful outcome is a specific next action: arrange a supported, trusted scanning endpoint; investigate an older backend compatibility failure; or report a separate scan problem after capability is established. HideFi reviewed public documentation and tagged source only. No wallet, scan key, server configuration or transaction was used or changed.