Add PayerCheck to validate V2 receipt payer field#915
Merged
Conversation
Add validation to ensure V2 receipt's claimed `payer` field matches the on-chain recovered sender (from signer → payer escrow mapping). Without this check, an attacker could submit receipts with a mismatched payer field that would pass balance checks but be stored with the wrong payer, causing receipts to never be aggregated by tap-agent (which queries by the recovered sender). This prevents: - Database bloat from orphaned receipts - Potential DoS via flooding DB with invalid receipts Similar to TRST-H-1 fix for service_provider validation.
Contributor
Pull Request Test Coverage Report for Build 21482936739Details
💛 - Coveralls |
suchapalaver
approved these changes
Jan 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Adds a new
PayerCheckto validate that V2 receipts have apayerfield matching the on-chain recovered sender before storage. This closes a security gap similar to TRST-H-1.Problem
V2 receipts contain a
payerfield in the message that was not validated against the on-chain recovered sender. An attacker could:PayerA(legitimate on-chain mapping)receipt.message.payer = PayerB(arbitrary address)SenderBalanceCheckbecause signer →PayerAhas escrow balancepayer = PayerB(claimed, not validated)tap-agentqueriesWHERE payer = PayerA→ never finds the receiptSolution
Add
PayerCheckthat comparesreceipt.message.payeragainst the recovered sender (injected bysender_middlewareviaget_sender_for_signer()). Mismatched receipts are rejected before storage.