Naming the general-purpose machine the safer option is where the argument turns around. A cheap laptop carries a layer you cannot read: the Intel management engine, or the AMD equivalent, runs below the operating system, and the SSD controller runs closed firmware of its own. Your seed sits on top of all of it, and an air gap removes none of that. The practical half matters too. A machine with no internet still needs a way out, so a second, online computer ends up in the chain to broadcast from. That hop is the same one a signer performs, only the signer's signing code is the one piece there you can read and rebuild yourself. SeedSigner is the closest thing to your plan that already exists: a small board, open firmware, a screen showing the address you are about to pay, no general-purpose system underneath. One device with one job, against a whole computer with a thousand of them.

How come "airgap removes none of that"? Only qr codes transmitted back and forth, if there is a backdoor it cannot call home.

Fair on the half that matters most: with no radio and no network, a compromised management engine has nowhere to send the seed. The Ledger objection was never that the chip could read the key. It was that firmware could be shipped to forward it, and that path ran through the connected channel. A real air gap closes it. What stays open is the part a QR code does not cover: the machine decides what you read before you sign. A closed stack below the operating system can show you one address while the signature pays another, and the seed never has to leave for that. Nor is the loop one-directional: anything the machine can encode it can put into a QR it asks you to scan with the phone that is online. Slow, carried by hand, but not closed. Immunity was never on offer; the size of the trusted part is. One device with one job keeps it small enough to read and rebuild.

A compromised Intel Management Engines is an extremely theoretical nation-state-grade attack, and all it would take to thwart is checking the destination address in the signed transaction before broadcasting. The first guy to notice such a discrepancy will warn the world. Or a coordinated attack should target both offline and online devices (to replace screen outputs). Someone that motivated will rather choose wrench.

Fair, and I will give the probability away: a backdoor baked in at the fab is not the default threat out there, and most people will meet a wrench long before a management engine. But your own sentence hands the objection back. If the attack has to hit the offline and the online device together, then in this setup it is not two attacks. Your laptop is offline over the cable only; the board is the same, the same engine sits under the same OS. An air gap takes away the mouth and leaves the eyes. Which is where "just check the destination address before broadcasting" needs a close look. Everything depends on what it gets checked against. Read the confirmation on the same machine that assembled the transaction and you compared the machine against itself. In a QR loop the second opinion is your phone, and your phone reads whatever the first machine decided to encode. The instinct is right, and a second witness has to be a second thing. A padded fee is the other open door. Measurement from my own node a few minutes ago: 25,934 transactions in the mempool, a median fee of 26 sats. Ninetieth percentile 40, mean 0.2 sat/vB. Above 2,000 sats sit 29 of them, which is 0.11 percent. Four cross 10,000. An invoice pins an address and an amount; nothing pins the miner's cut. Today such a fee would be an outlier a check could catch. That is the good news, and it is a property of an empty mempool. Once fees run into the hundreds of thousands of sats, the same shave is rounding noise and the check stops meaning anything. And yes, the wrench comes first, because it needs no firmware, only an address and a door. It also needs a witness. A bad batch needs none of the three. I do not rate it likely. I rate it the only one nobody has to be present for.