Support third-party delivered payments (bridge/solver `Transfer.from !== receipt.from`)

[starc007]

Check existing issues

• I checked there isn't already an issue for the bug I encountered.

Describe the bug

Problem

type="hash" verification in tempo.charge() checks that Transfer.from === receipt.from via assertTransferLogs. This fails when a third party (bridge solver, payment processor) delivers funds on behalf of the payer.

Code: src/tempo/server/Charge.ts — assertTransferLogs

if (!TempoAddress.isEqual(log.args.from, parameters.sender)) return false
// where sender = receipt.from

Proof

Verified against a real Relay bridge fill on Base (BaseScan):

receipt.from:  0x728f51950ff096dc03a48f5e83f45ac8bb75f500  (caller EOA)
Transfer.from: 0xf70da97812cb96acdf810712aa562db8dfa3dbef  (Relay Solver)
Match? false → verification fails

The solver holds the tokens and is the from in the ERC-20 Transfer event, but a different EOA submits the transaction. This pattern is standard across bridge protocols — the authorized caller and the token source are different addresses.

Use Case

Cross-chain MPP payments: an agent pays on chain A, a bridge solver delivers to the service on chain B. The service's mppx verification needs to accept the fill transaction as valid payment.

This applies to any bridge (Relay, Across, Stargate, etc.), payment processor, or custodial service that delivers funds on behalf of a payer.

Suggested Direction

A credential type that verifies the transfer landed on-chain (correct token, recipient, amount) without requiring Transfer.from === receipt.from. All other security layers (HMAC challenge binding, expiry, replay protection) remain unchanged.

Happy to discuss the approach and contribute a PR.

Package Version

0.5.3

[gakonst]

ACKing this is in scope - circling back, good suggestion

[danrobinson]

Totally agree with this as an issue, but it's challenging to fix—if Alice owes a payment to a server but Bob sends an payment of the same amount at the same time to the same server, what keeps Alice from pointing to Bob's payment and claiming it came from her?

Memos would work, but support for those is not universal (for example Relay probably won't support it). I think a one-time recipient address might be the best approach, but that's somewhat expensive for the server to manage (until we have virtual addresses).

[starc007]

agreed, cross-claiming is the real challenge here. memos would be ideal but bridges won't support that. one-time addresses with virtual addresses seems like the cleanest long-term path.

one hacky idea i was exploring - what if the server tweaks the last few digits of the amount per challenge? like 10.000000 becomes 10.012347. amount is HMAC-bound so it can't be tampered with, and each active challenge maps to a unique on-chain transfer. not clean (bridges with slippage could break exact matching), but it works for exact-output bridges like Relay as a stopgap.