Skip to content

fix(ttx): enforce recipient data registration on external withdrawal path#1923

Open
adecaro wants to merge 1 commit into
mainfrom
withdrawal-check-recipient-identity
Open

fix(ttx): enforce recipient data registration on external withdrawal path#1923
adecaro wants to merge 1 commit into
mainfrom
withdrawal-check-recipient-identity

Conversation

@adecaro

@adecaro adecaro commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Summary

  • RequestWithdrawalView.getRecipientIdentity accepted caller-supplied RecipientData for the external-wallet withdrawal path as-is, with no check that the identity/audit-info pair was ever registered against the local wallet.
  • Resolve the caller's local wallet and call w.RegisterRecipient(ctx, r.RecipientData) before using the data to drive the withdrawal handshake, so a mismatched identity/audit-info pair is rejected instead of silently accepted (AnonymousOwnerWallet.RegisterRecipient runs Deserializer.MatchIdentity before registering/binding).
  • Removed the now-redundant manual RegisterRecipient call in integration/token/fungible/views/withdraw.go, since the library now enforces it.
  • Updated docs/services/ttx.md to document the new enforcement point and its scope (full protection requires an AnonymousOwnerWallet-backed local wallet; LongTermOwnerWallet validation was addressed separately in LongTermOwnerWallet.RegisterRecipient was an unconditional no-op, bypassing recipient validation #1917).

Fixes #1922

Test plan

  • go build ./... and (cd integration && go build ./...) succeed
  • New unit tests in token/services/ttx/withdrawal_test.go cover: registration succeeds (external flag set, nil wallet returned), registration fails (error bubbles up, external flag not set), and the unchanged local-wallet fallback path (no RecipientData supplied)
  • go test ./token/services/ttx/... passes
  • make checks passes

@adecaro adecaro added this to the Q3/26 milestone Jul 15, 2026
@adecaro adecaro self-assigned this Jul 15, 2026
@adecaro adecaro requested review from AkramBitar, KElkhiyaoui and alexandrosfilios and removed request for AkramBitar July 15, 2026 14:09
@adecaro adecaro force-pushed the withdrawal-check-recipient-identity branch from 3c7daff to 9fe6d6e Compare July 15, 2026 14:09
…path

getRecipientIdentity accepted caller-supplied RecipientData as-is when
driving a withdrawal for an external wallet, with no check that the
identity/audit-info pair was ever registered against the local wallet.
Resolve the wallet and call RegisterRecipient before using the data, so
a mismatched pair is rejected instead of silently accepted. Remove the
now-redundant manual RegisterRecipient call in the integration caller.

Fixes #1922

Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
@adecaro adecaro force-pushed the withdrawal-check-recipient-identity branch from 9fe6d6e to 92d866c Compare July 15, 2026 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unregistered external RecipientData accepted during withdrawal

1 participant