How to design a robust 2-of-2 Bitcoin multisig signature flow with two ledgers (no Sparrow dependencies)

I am developing a Bitcoin application (“Bitcoin Monitor”). Its goal is not to replace wallets, but to adjust the standard PSBT signature flow in a robust and long-term resilient way.

My current settings are:

Bitcoin Multisig 2-of-2 (A + B)

P2WSH

Two Ledger devices (Ledger A and Ledger B)

PSBT signing via HWI

Watch-only wallet/UTXO scanning is handled by the application

I have validated this setup using Sparrow, but would like to remove Sparrow from my trust and dependency model.

The core concerns I’m trying to address are:

Even if Sparrow disappears, I don’t want to be locked into a third-party UI to spend my funds.

where I am today

My application can build PSBT from known UTXOs.

You can call hwisigntx to get a partial signature.

Ledger requires an “initial verification/review step” before signing, which we understand is normal behavior.

We want to ensure that Ledger A signs first and then uses Ledger B to finalize and broadcast the transaction.

What you are trying to achieve (target architecture)

Uses only Bitcoin standards (PSBT, descriptors, BIP32/48 derivation path).

Make your application a PSBT orchestrator rather than a wallet.

Let your Ledger device do all the signing and never expose your private key.

Make sure your setup is still usable even if Sparrow, Specter, or other UI disappears.

my question

1. What is the minimum PSBT information required for Ledger to:

recognizes input as belonging to the device

Avoid alarming warnings

Allows clean multi-step signatures (ledger A, then ledger B)

2. Is storing and using (receiving + modifying) descriptors considered a recommended long-term approach for this use case?

3. Is the following flow considered correct and robust for 2-of-2 P2WSH multisig?

Build PSBT

Signed in Ledger A (via HWI)

Signed in Ledger B (via HWI)

Finalization and Broadcast (Bitcoin Core)

4. Are there any pitfalls to avoid when designing this without Sparrow (e.g. derived paths, witness_utxo vs non_witness_utxo, Ledger-specific UX constraints)?

I’m clearly trying to avoid proprietary format and UI lock-in. We would love to hear feedback from people who have designed similar multisig, institutional, or long-term storage setups.

thanks in advance

victor