Allow bech32 encoding of MASP address in shielded receive middleware #4722
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Describe your changes
This fix is required by #4723.
Rather than encoding the MASP address to
bech32mto compare it with the ICS-20 receiver, we parse a transparent address from the ICS-20 receiver string (which can be eitherbech32/bech32m), and compare it against the MASP address.This PR also fixes a minor bug where the overflow receiver address wouldn't be added as a verifier, causing the Multitoken VP to reject txs in case of ack errors, which would result in timeouts (the latter which are a symptom of #4721).
Checklist before merging
breaking::labelsnamada-docsreponamada-indexerornamada-masp-indexer, a corresponding PR is opened in that repo