Bug
createInvoice() rejects a token when balanceOf or allowance returns less than 32 bytes, but createInvoicesBatch() only checks whether the balanceOf call succeeds. A fallback-only contract is therefore accepted as a batch token even though it does not implement ERC-20 return data. The resulting invoice cannot be paid.
Reproduction
On main at e299e8a, a Foundry test using a fallback-only token shows:
createInvoice() reverts with InvalidToken;createInvoicesBatch() succeeds with the same token;- payment of the accepted batch-created invoice reverts and rolls back.
This inconsistency was also noted during the review of PR #102, but I could not find a follow-up issue or implementation PR for it.
Expected
Batch creation should reject malformed token contracts consistently with the single-invoice path. Tests should cover failed calls and missing return data.
If this is still worth fixing, please assign it to me. I would keep the change limited to consistent token validation and focused Foundry regression tests.
Bug
createInvoice()rejects a token whenbalanceOforallowancereturns less than 32 bytes, butcreateInvoicesBatch()only checks whether thebalanceOfcall succeeds. A fallback-only contract is therefore accepted as a batch token even though it does not implement ERC-20 return data. The resulting invoice cannot be paid.Reproduction
On
mainate299e8a, a Foundry test using a fallback-only token shows:createInvoice()reverts withInvalidToken;createInvoicesBatch()succeeds with the same token;This inconsistency was also noted during the review of PR #102, but I could not find a follow-up issue or implementation PR for it.
Expected
Batch creation should reject malformed token contracts consistently with the single-invoice path. Tests should cover failed calls and missing return data.
If this is still worth fixing, please assign it to me. I would keep the change limited to consistent token validation and focused Foundry regression tests.