If two wallets claim the bounty the one which merged a substantial majority of the work gets the bounty, not just based on release date, otherwise it wouldn’t be fair to projects with a rigid release schedule.
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 https://docs.rs/dnssec-prover 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.
Discussion
Bounty will only be paid out with the blessing to the project maintainers. (Check in with them before you work on it!)