Description
Since 2026-07-30, open offers whose maker fee tx pays the legacy Burning Man BTC fees address 38bZBj5peYS3Husdz7AH3gEUiUbYRD951t are being deactivated with "Fee receiver not a recognised address" (NACK_UNKNOWN_FEE_RECEIVER). The offers were created during the July fee routing transition, validated fine for days, and only started failing after a filter update received on 2026-07-30. Multiple users report the same on the forum: https://bisq.community/t/offer-deactivated-fee-receiver-not-a-recognised-address/13892
Version
v1.10.4
Related tickets
#7534 (same error string, Nov 2025), #7905 (filter based fee receiver routing)
Cause
A stock client only pays the maker fee to an address emitted by BtcFeeReceiverService.getAddress(), so these offers paid 38bZ... because the network data active at creation time designated it. Validation however is time-of-check: MempoolService.getAllBtcFeeReceivers() is rebuilt on every validation from the current filter receivers, the BM address list legacy address, DAO donation addresses and BM candidates that ever burned BSQ, and none of these contains 38bZ... any more, so TxValidator.checkFeeAddressBTC() rejects fee txs that were valid when created (the BLOCK_TOLERANCE leniency only covers offers created before block 600000, ~Oct 2019). TriggerPriceService then deactivates the maker's own offers, and desktop takers are blocked at the next step of the take offer screen (popup.warning.makerTxInvalid), so the offers are effectively untakeable. Makers who cancel forfeit the paid maker fee through no fault of their own.
Suggested fix
-
Immediate, data only: re-add the address to the filter's btc_fee_receiver_addresses. The weighted syntax minimum is 0.0001, so 38bZBj5peYS3Husdz7AH3gEUiUbYRD951t#0.0001 makes it recognised again while routing only ~0.01% of new fees to it. Note the parser rejects configs mixing weighted and plain entries, so if the current filter carries plain entries the whole list needs to be republished in weighted form (a plain 38bZ... entry would instead route 1/N of all new fees to it). Affected makers can then simply re-enable their offers (fee validation status is transient and resets on activation).
-
Structural: retired fee receivers should enter a validate-only state instead of dropping out of the recognised set entirely. Selection never emits them for new offers, but mempool validation keeps accepting fee txs made while the address was still active, e.g. by giving each receiver an active height range. A routing change then cannot invalidate already published offers, and the retired entry loses relevance on its own once no offer referencing it remains. Can submit a PR for this if preferred.
Description
Since 2026-07-30, open offers whose maker fee tx pays the legacy Burning Man BTC fees address 38bZBj5peYS3Husdz7AH3gEUiUbYRD951t are being deactivated with "Fee receiver not a recognised address" (NACK_UNKNOWN_FEE_RECEIVER). The offers were created during the July fee routing transition, validated fine for days, and only started failing after a filter update received on 2026-07-30. Multiple users report the same on the forum: https://bisq.community/t/offer-deactivated-fee-receiver-not-a-recognised-address/13892
Version
v1.10.4
Related tickets
#7534 (same error string, Nov 2025), #7905 (filter based fee receiver routing)
Cause
A stock client only pays the maker fee to an address emitted by BtcFeeReceiverService.getAddress(), so these offers paid 38bZ... because the network data active at creation time designated it. Validation however is time-of-check: MempoolService.getAllBtcFeeReceivers() is rebuilt on every validation from the current filter receivers, the BM address list legacy address, DAO donation addresses and BM candidates that ever burned BSQ, and none of these contains 38bZ... any more, so TxValidator.checkFeeAddressBTC() rejects fee txs that were valid when created (the BLOCK_TOLERANCE leniency only covers offers created before block 600000, ~Oct 2019). TriggerPriceService then deactivates the maker's own offers, and desktop takers are blocked at the next step of the take offer screen (popup.warning.makerTxInvalid), so the offers are effectively untakeable. Makers who cancel forfeit the paid maker fee through no fault of their own.
Suggested fix
Immediate, data only: re-add the address to the filter's btc_fee_receiver_addresses. The weighted syntax minimum is 0.0001, so 38bZBj5peYS3Husdz7AH3gEUiUbYRD951t#0.0001 makes it recognised again while routing only ~0.01% of new fees to it. Note the parser rejects configs mixing weighted and plain entries, so if the current filter carries plain entries the whole list needs to be republished in weighted form (a plain 38bZ... entry would instead route 1/N of all new fees to it). Affected makers can then simply re-enable their offers (fee validation status is transient and resets on activation).
Structural: retired fee receivers should enter a validate-only state instead of dropping out of the recognised set entirely. Selection never emits them for new offers, but mempool validation keeps accepting fee txs made while the address was still active, e.g. by giving each receiver an active height range. A routing change then cannot invalidate already published offers, and the retired entry loses relevance on its own once no offer referencing it remains. Can submit a PR for this if preferred.