BIP 353 is a huge leap forward in security and UX for common payments from hardware wallets. Yet, sadly, its stuck in a three-w ay chicken-and-egg problem between the software wallets that people use, the hardware wallet firmware, and recipients. No one wants to do the work to be a first-mover when the other two legs don't exist yet. So, to get off zero, lets try a bounty. I'm offering $1000 (payable only in Bitcoin to a BIP 353 HRN) each for the first hardware wallet and (on-chain, hardware wallet-supporting) software wallet to support sending to BIP 353 HRNs. For a hardware wallet, this should be easy, just detect the PSBT field for a DNSSEC proof, validate it, and display the HRN for verification instead of (or in addition to) the actual address. You don't have to use

dnssec_prover - Rust

The DNS provides a single, global, hierarchical namespace with (when DNSSEC is used) cryptographic guarantees on all of its data.

to do the validation, but I imagine it will be easy. The feature has to exist in the released default firmware for the hardware wallet. For a software wallet, there's only a few more steps, support detecting a BIP 353 HRN in the send-to UI, do the DNS lookup (again, dnssec-prover should make this easy, if you want), build the proof, and include it in the PSBT you provide to hardware wall ets. Also store the HRN (and maybe DNSSEC proof) so that the transaction history shows it. The default sending methods (GUI/CLI/whatever) have to support accepting HRNs and should handle them just like regular addresses. You don't have to support silent payments, but of course its good to as well. Support has to be in an official release. A hardware wallet that also provides a software wallet doesn't get to claim both bounties. Releases which satisfy the bounty must be made before December 31, 2025.