[ANCHOR-1254]: V30 backfill builds an owner row from two transactions, locking out legacy owners and enabling a co-tenant KYC claim

[amandagonsalves]

Description

V29__sep31_customer_id_owner.sql backfills sep31_customer_id_owner by picking, per customer id, the earliest historical reference (any caller type) and recording that caller's account and JSON memo field. V30__backfill_muxed_sep31_customer_id_owner.java then repairs the memo for muxed callers, since a muxed sub-account id lives in the StrKey account field, not the JSON memo field, and SQL alone can't decode it.

The bug: V30 selected its own "winning" reference independently — the earliest reference among muxed references only — instead of checking whether the same transaction V29 already chose as the owner happened to be muxed. For a customer id whose earliest reference was a bare, non-muxed caller (so V29 leaves creator_memo null) but which also has any later muxed reference, V30's independent query found that later reference, decoded its muxed id, and wrote it onto the row V29 built from the earlier, different transaction — producing an owner row combining one caller's account with a different caller's memo. That row matched neither the real owner nor the later caller, so the real owner's own requests failed the ownership check (SepNotAuthorizedException), and a co-tenant sub-account sharing the real owner's client name could pass the check for a customer id it didn't own.

Fix: V30 now runs the identical reference-selection query V29 uses (same refs union, same COALESCE(client_name, account) IS NOT NULL filter, same ORDER BY customer_id, started_at ASC NULLS LAST, id ASC tie-break) instead of a muxed-only variant, so it always lands on the exact same winning transaction per customer id that V29 already chose. It only decodes and sets a memo when that winning transaction's own account is muxed (startsWith("M")) — never from a different, independently-selected reference.

Changes

• V30__backfill_muxed_sep31_customer_id_owner.java: findWinningMuxedReferences (muxed-only WHERE clause) replaced with findWinningReferences, an unfiltered-by-muxedness query identical to V29's own winner-selection logic; the muxed check (winningAccount.startsWith("M")) now happens in Java, after selecting the same per-customer-id winner V29 selected, not before.
• V29__sep31_customer_id_owner.sql: unchanged.

Acceptance Criteria

• A customer id whose earliest reference is bare/non-muxed and which also has a later muxed reference (from any caller) backfills to (client_or_account, null) — the earliest transaction's own identity — not a hybrid of two different transactions.
• The real owner of that customer id passes verifyOrClaim after the migration; a co-tenant presenting a different, later muxed sub-account id does not.
• A customer id whose earliest reference is itself muxed still backfills with that transaction's own decoded muxed id (the existing correct case is unaffected).
• A customer id with only bare, non-muxed references is unaffected (memo stays null).

Context

HackerOne #3866121

Testing

• Manual: re-ran the report's reproduction scenario against a throwaway Postgres instance, running the verbatim V29 SQL followed by the fixed V30 query/decode/update, decoding with the real org.stellar.sdk.MuxedAccount class.
• Full suite: ./gradlew :core:test :platform:test — BUILD SUCCESSFUL.

Documentation

N/A

Known limitations

N/A

[Copilot]

Pull request overview

Aligns V30’s winner selection with V29 to prevent hybrid ownership records.

Changes:

• Selects the same earliest reference as V29.
• Decodes muxed IDs only when that winning reference is muxed.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.